Privacy overview

How privacy responsibilities split between you and Intempt, and where each control lives: consent, data subject requests, opt-out, access control, and retention.

Overview

Intempt processes personal data on your instructions. You decide what to collect and why. Intempt gives you the controls to honor what your users ask for afterwards.

That split is a legal one, not a courtesy. Under GDPR you are the data controller and Intempt is the data processor. Under CCPA you are the business and Intempt is the service provider. The obligations land on you; the tooling comes from us.

This page maps the privacy surface so you know which control answers which question.

How it works

Privacy in Intempt has four layers. Most teams need all four, and they're independent of each other.

Layer	Question it answers	Where it lives
Collection	What should we send in the first place?	Your tracking plan, the Events page, SDK config
Consent	Has this person agreed to it?	Privacy Center, the `consent()` SDK method, a user's Privacy tab
Access	Who on my team can see it?	Org and project roles, custom roles, audit log
Rights	This person asked to be forgotten. Now what?	Privacy Center, Data subject requests

The Privacy Center

Consent categories, the preference center, and data subject requests all live in the Privacy Center, on three tabs:

Tab	What it does
Consents	Define consent categories and legitimate interest categories, and see them per user
Preference center	Configure the page your customers use to manage their own subscriptions
Data subject requests	Submit and track erasure, accessibility, and export requests

Two kinds of "opt out"

These are easy to confuse and they do different things.

	What it stops	Where you set it
Consent	A category of processing, like marketing email	`consent()`, or a user's Privacy tab
Tracking opt-out	All event collection for that user	`optOut()` in the SDK

Revoking a consent category doesn't stop event collection. Calling optOut() does. A user asking to stop hearing from you needs the first; a user asking not to be tracked needs the second.

📘 Good to know

Erasure and opt-out are also different. Deleting a user's data removes what Intempt holds today; it does not prevent new data arriving tomorrow. If someone asks to be forgotten and to stay forgotten, run the erasure request and opt them out.

Getting started

Decide what you collect before you collect it. See Data privacy and PII best practices for the framework, and the PII checklist when you're reviewing a tracking plan.
Set up consent categories. See Managing consents.
Wire opt-out into your app. See Protecting user data.
Confirm who can see what. See Access management.
Know the DSR workflow before you need it. See Managing DSR.

Use cases

A user emails support asking to be deleted. Submit an erasure request in the Privacy Center, then opt them out so new events stop arriving.
A user asks to stop receiving marketing email but wants to keep using the product. Revoke the marketing consent category on their Privacy tab; leave tracking alone.
Your legal team asks which fields in the project count as personal data. Review the Attributes page and mark anything sensitive as Hidden.
A new analyst joins and shouldn't see customer email addresses. Give them a project role that excludes those objects rather than a blanket Project admin role.
You're preparing for a security review and need to show who accessed what. Export the audit log for the relevant window.
You're about to launch tracking on a new surface and want to be sure no PII creeps in. Walk the PII checklist before the release, not after.
A customer's procurement team asks how long Intempt keeps their data. Point them at the retention section of the privacy policy.
Someone in the EU wants to exercise their rights directly with Intempt rather than through you. They can reach our Article 27 EU Representative at privacy@intempt.com.