Data classification and views
Label which fields hold personal data, and give each team a view of your project containing only what they need.
Overview
Two controls answer the question every privacy review asks: which fields hold personal data, and who can see them.
Classification labels a field. Views decide what a team sees. They're independent, and you'll usually want both.
How it works
Classification
Classifying an attribute marks it as holding personal data. It doesn't change who can see the value, and it doesn't stop collection. It records what the field is.
That sounds minor until someone asks you to produce the list. A classified field is findable, reportable, and obvious to the next person who inherits your project.
| Effect on collection | None |
| Effect on visibility | None |
| What it's for | Knowing, and being able to prove you know |
📘 Good to know
Every attribute already carries a personal-data flag on its record. What isn't available yet is any way to set it, see it in the attribute list, or filter on it. Until that ships, keep the list of personal-data fields outside Intempt, and use Hidden plus role grants for the access half.
📘 Good to know
Classification and visibility are deliberately separate. A field can be classified and fully visible, because your team has a legitimate reason to see it. A field can be hidden without being personal data, because it's noisy. Conflating the two makes both less useful.
Views
A view is a subset of your project's data that a role sees instead of all of it. Everything still arrives and everything is still stored; the view decides what's in front of a given team.
| Use a view to | Example |
|---|---|
| Keep classified fields away from broad audiences | Analysts get every behavioral property and no contact details |
| Give a team only what its job needs | Support sees one customer at a time, not aggregate exports |
| Separate by product area | A team working on billing doesn't browse product analytics |
Views curate rather than restrict. A team with the right view has full analytical power over the data it should have, which is a better outcome than giving everyone access and asking them to be careful.
Getting started
Work out what you have
- Open Attributes and read down the list.
- Note anything that identifies a person, or could when combined with something else.
- Add a Description to each one, so the next person doesn't have to work it out again.
Direct identifiers are the obvious ones. Don't stop there: account identifiers, device identifiers, and free-text fields that users type into all belong in the same pass.
Keep that list where your team will find it. There's no in-product way to record it yet.
See Managing attributes.
Build a broad-access view
Start with the view most of your team will use, and leave classified fields out of it. This is the default that prevents accidental exposure, so it's worth getting right before you build any narrower ones.
Add narrow views by need
Create additional views where a specific role genuinely needs more, and grant them deliberately rather than by default. See Access management.
Review on a schedule
New fields arrive constantly. Set a quarterly pass: what's new, what's now classified that wasn't, and which views need updating. See the PII checklist.
Use cases
- Legal asks which fields in the project hold personal data. Work down the Attributes page and record the answer alongside your tracking plan.
- A new analyst joins and shouldn't see contact details. Put them on the broad-access view rather than granting project-wide access.
- Support needs customer emails to answer tickets. Give the support role a view that includes them, and only that role.
- A quarterly review finds three new attributes nobody assessed. Add them to your record and check who can currently read them.
- An auditor asks how you prevent broad access to personal data. Show the broad-access view's field list and the roles assigned to it.
- A contractor needs access for one project phase. Give them the narrowest view that works, and remove it when the phase ends.
- A field turns out to be personal data after all, because users started typing names into it. Set it to Hidden, then confirm which roles still reach it.
Where to go next
PII checklist
A ten-section review checklist for tracking plans: minimization, identity safety, naming, access control, retention, and incident response, mapped to the Intempt controls that enforce each one.
Masking and hashing
Three places to control a sensitive field in Intempt: block, mask or hash it as it arrives, mask it in the console, or hash it in your own code before you send it.