Intempt Docs
GuidesPrivacy

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.

Overview

Run this before you ship new tracking, and again each quarter against tracking you already have. Every item maps to a control that exists in Intempt today, or to a decision only your team can make.

Sections 1 through 4 are design-time. Sections 5 through 10 are ongoing.

1. Minimize what you send

  • No personal data in event names. An event called signup_jane@acme.com becomes a permanent identifier in your schema.
  • Personal data lives in attributes, never in event names, and only where a business process needs it.
  • Identifiers are internal and non-identifying. Hash anything that reveals a person on its own, using HMAC-SHA256 with a server-held key rather than a bare hash.
  • Nobody on the team believes hashing makes the data anonymous. It's pseudonymization, and it's still personal data.
  • No credentials, government ID numbers, payment card details, or dates of birth. There's no safe way to send these.
  • Every attribute has a Description on the Attributes page. A field nobody can explain is one nobody can govern.

2. Control who sees sensitive fields

Two controls do this job together: a classification label that records what a field is, and visibility that decides who can read it.

  • Sensitive attributes have Status set to Hidden on the Attributes page. There is no separate classification control yet, so Hidden plus role grants is the whole mechanism.
  • A custom role exists for teams that shouldn't reach those attributes, and people are assigned to it rather than to Project admin.
  • You have a written list of which attributes are sensitive and which roles can read them.
  • That list is re-checked each quarter against the actual Attributes page.

See Managing attributes and Access management.

3. Keep identity safe

  • Users are identified by a stable internal ID, not an email address.
  • The same identifier is used everywhere. See Why a single profileId matters.
  • identify() runs only after authentication, so an anonymous session never gets attributed to the wrong person.
  • Account-level identifiers are non-identifying too. A company domain used as an account ID is a business identifier, not personal data, but treat a sole trader's name as personal.
  • You know what alias() does in your implementation and where it's called.

4. Name things consistently

  • Event and attribute keys follow one convention across the project, and everyone knows what it is.
  • Identifier fields are recognizable as identifiers from the name alone.
  • Enumerated values are categories, not people. role = admin, never role = jane_admin.
  • When an event's shape changes, the change is recorded somewhere a future reader will find it.
  • You know which regulations apply to you, and where your users are.
  • Consent is collected before identifiable data is sent, not after.
  • Each consent category has a lawful basis you could defend, and legitimate interest categories are separated from consent categories.
  • You can act on an erasure request. See Managing DSR.
  • Someone owns privacy questions when they arrive. "The team" is not an owner.

6. Retention and storage

  • You know how long Intempt keeps your data, and it's long enough for the analysis you actually run. See Data retention.
  • Unused attributes are deprecated rather than left in place.
  • Data exported to a warehouse or destination is governed there too. Leaving Intempt doesn't end your obligations.
  • You've read the retention section of the Intempt privacy policy and your team's expectations match it.

7. Access control

  • SSO is enforced if your organization has it. See Security & Trust Center.
  • MFA policy is set at the organization level.
  • People hold the narrowest role that lets them work, not Project admin by default.
  • Production and testing live in separate projects, and the test project has no real user identifiers in it.
  • Access is reviewed on a schedule, not when someone leaves.
  • On Enterprise, the audit log is checked periodically rather than only after an incident.

8. Security in transit

  • All SDK and API traffic uses HTTPS.
  • No secrets in client-side bundles. A private or admin API key in browser JavaScript is a public API key.
  • API keys are scoped to the narrowest level that works. See API Keys.
  • Keys are rotated when someone with access leaves.

9. Review before it ships

  • Every event and attribute has an owner, a description, and an example payload.
  • New tracking is verified on the Events Live tab before anyone builds a report on it. See Live data feed.
  • Tracking changes go through the same review as code changes.
  • Schema changes and new feature launches get a PII check, because that's when fields quietly change meaning.

10. Monitor and respond

  • Someone watches for attributes with unexpectedly high cardinality. A field with one distinct value per user is usually carrying an identifier.
  • You have a written response for finding PII where it shouldn't be: stop the source, hide the attribute, filter it out of reporting with a Created event, tell legal.
  • That response has been read by the people who'd run it, before they need it.
  • Erasure requests and tracking opt-out are both used when a user asks to be forgotten. Deleting data doesn't stop new data arriving.

Use cases

  1. A pre-launch review for new instrumentation. Walk sections 1 through 4 during design, before any tracking code is written.
  2. A quarterly hygiene pass. Sections 5 through 10 against tracking already in production.
  3. Onboarding an analyst. Sections 2 and 7 tell them what they can see and why some fields are hidden.
  4. Responding to a customer security questionnaire. Sections 7 and 8 map to most of what gets asked.
  5. Triaging a suspected PII leak. Go straight to section 10 and work the response in order.
  6. Handing tracking ownership to a new team. Section 9 is the contract they're inheriting.
  7. Preparing for an audit. Sections 5 and 6 cover lawful basis and retention, which is where auditors start.
  8. Deciding whether a requested field is worth adding. Section 1's risk table answers most of these in a minute.

Where to go next

Data privacy and PII best practices

A three-phase framework for deciding what data to collect, identifying sensitive fields, and keeping your project's privacy posture healthy as it grows.

Data classification and views

Label which fields hold personal data, and give each team a view of your project containing only what they need.

On this page

Overview1. Minimize what you send2. Control who sees sensitive fields3. Keep identity safe4. Name things consistently5. Line up with your legal obligations6. Retention and storage7. Access control8. Security in transit9. Review before it ships10. Monitor and respondUse casesWhere to go next