Data processing

The personal data the product handles for you, the reason for each item, how long it stays and how it leaves. Use it for your record of processing and your contract with the operator of the deployment.

Roles#

Party	Role under the DPDP Act	Role under GDPR-style laws
You, the organisation whose site or app asks for consent	Data Fiduciary	Controller
The operator of the deployment	Data Processor, acting on your instructions	Processor
The person who answers the notice	Data Principal	Data subject
Partners you name on a purpose	Your own processors or other fiduciaries. The product never sends them data	The same

You decide which purposes exist, what the notice says, which identifiers are recorded and how long evidence is kept.
The operator runs the software, holds the keys and makes the backups.
If you run the deployment yourself, you are both. There is then no processor for the consent records.

What is processed and why#

Data	Where it comes from	How it is stored	Why
Identifier of the person: a random browser id, or your choice of email, phone, user id, device id, session id or your own token	The browser runtime or your server	A keyed hash only. A readable, encrypted copy is kept only if the project turns on Store a reversible subject identifier	To attach a decision to a person and to find it again for a rights request
Further identifiers linked to a record	The runtime or your server	Type and keyed hash	So one consent can be found and cleared by any of them
Subject fingerprint	Computed from the identifier	A keyed hash under a key your project holds	So you can match receipts and webhooks to your own identifier
Decisions per purpose and per partner, what the person did, form version	The runtime or your server	In clear, sealed	Evidence of consent
Country and subdivision	Request headers, or a lookup of the IP address in a local database at the time of the request	Two-letter and short codes	To choose the law that applies; evidence
IP address	The request	A salted hash only. The address itself is not stored with the record	Provenance of the record
Browser string and page address	The request	Cut to 500 characters	Provenance of the record
Language	The runtime	In clear	Evidence of the language shown
Extra `metadata`	Your integration	In clear, up to 8 KB	Whatever you send. Do not put personal data in it
Parent or guardian verification	Your server	Relationship, method, time, and a keyed hash of the reference	Evidence of verifiable consent for a child or a person with a guardian
How consent was taken in a branch, by phone or on paper	Your server	Channel, method, your evidence reference and a document SHA-256 in clear, sealed. Staff and site references as keyed hashes under your project's fingerprint key	Evidence of how consent was obtained
Basis and notice of consent given earlier	Your server or an import	The basis you stated, and the notice reference or SHA-256, in clear, sealed	Evidence of what you stated about earlier consent
People in a notice campaign	A file you add in the console	Each identifier as a keyed hash only. Your reference, encrypted. Language, basis, answer, a salted hash of the answering IP address and the browser string. Delivery as your sender reported it	Evidence that a notice was sent and answered
Hashes of erased people	Each erasure	The keyed hashes an erased record was known by, with the date	So an import or a notice campaign does not add the person back
Processor tasks	Withdrawals, expiries and erasures	Partner, action, purposes and dates, with no identifier. Reports with your note, reference and an evidence file's name, size and SHA-256	Accountability for passing on withdrawals and erasures
Email address for double opt-in	Your server	A keyed hash. The confirmation token is stored hashed	To confirm control of the mailbox
Rights request	The hosted form, your server or your team	The identifier as a keyed hash; the contact the person gave, encrypted; the note and the handling timeline in clear	To track and answer the request
Cookie and storage names, third-party hosts, page path	The runtime on a sample of page views, and site scans	In clear, without values	The cookie list and the DPDP Act check
Banner views	The runtime	Daily counts per form, version and country. No identifiers	Consent rate reporting
Webhook deliveries	The product	The event body and your endpoint's answer	Delivery, retries and troubleshooting
Actions by your team	The console	Audit log: user id, email, time, IP address, browser, action and result, including reads of records, requests and lookups	Accountability
Audit log copy on standard output	Every audit entry	The same fields as the audit log, one JSON line each. The operator decides where it is kept	Security monitoring
Calls on a person made with a secret key	Your server	Audit log: key name, time, IP address, and the first 12 characters of the identifier's keyed hash	Accountability
Request log	Every request to the API	One line on standard output: time, method, address requested, status and the client's IP address. Identifiers, keys, search text and notice link tokens in the address are masked. The operator decides where it is kept	Operation and troubleshooting
Breach register	Your team	Free text you enter	Tracking incidents and reports

Your team's accounts and sessions belong to the PIEDAP IAM service, not to this product. The console reads the session to know who is acting.

IP addresses in the audit log are kept in clear on purpose, for security monitoring. They are the addresses of your team and your servers, not of the people whose consent is recorded.

What is not collected#

Cookie values, form inputs and page content. The runtime sends none of them.
Precise location. Only country and, where needed, subdivision.
A contact list for sending messages. The product sends no email or SMS. A notice campaign keeps its people's identifiers only as hashes.
Scanned forms, signatures and call recordings. Only your reference to them and the SHA-256 of a scan are kept.

The one contact it stores is the reply address a person gives with a rights request.

Where a readable identifier can appear#

The product is built to hold identifiers only as hashes. A readable identifier can exist in four places. A person search in Records sends the identifier in the request body, which is not logged.

Place	When	Who controls it
The encrypted copy	Store a reversible subject identifier is on. Webhooks then include the identifier as `subject.reference`, and the delivery log holds it for 30 days	You
The webhook delivery log	A rights request is filed on the hosted form. The identifier the person typed and the reply address go out in `subject_request.received`. They sit in the log until it is cleared, after 30 days	You
`metadata`	Your integration puts one there	You
A notice campaign's reference	You give each person a reference, such as a CRM id. It is stored encrypted, and appears in the links your sender reads and in `campaign.withdrawn`	You

Retention#

Data	How long
Consent records and their events	While the consent is in force, then for the project's Keep evidence for period: 1, 3, 7 or 10 years, 7 by default. Deletion happens only when the operator has turned on retention enforcement. Otherwise records stay
Identifying details on an erased record	Removed at once. For a record under India's DPDP Act erased less than a year after its last processing, removed when the year is up. Linked identifiers and email confirmations are removed at once in both cases
Test records written with test keys	30 days after their last change
Email confirmation tokens	Valid for 48 hours. The entry is deleted with its record
Webhook deliveries and settled outbox events, failed events included	30 days
Processor tasks and their reports	As long as their record
Hashes of erased people	For the life of the project. Those of test records, 30 days after the erasure
Notice campaigns, their people and answers	Until the project is closed. An erasure removes the person's identifiers, reference and fingerprint, and the address hash and browser of their answer, from every campaign. The answer stays as proof
Encrypted copies of notice links	7 days after the batch is issued
Idempotency records	24 hours
Consent portal links	Valid for 7 days
Banner view counts and daily statistics	Kept with the form
Discovered cookies and hosts	Kept with the property
Rights requests	Until the project is closed
Audit log	Not deleted by the product. The database refuses deletions; the operator archives and removes old rows as the table's owner. See Download the audit log
Breach register	Until the project is closed
Daily anchors	Until the project is closed
Request log and the audit copy on standard output	Set by the operator, outside the product

The retention job follows these rules:

It never deletes a record less than a calendar year after its last processing or its last event. An export or erasure made after the consent ended counts as an event.
It counts the retention period from the record's expiry date.
It only touches records whose consent has ended: expired, withdrawn or refused.
It writes each deletion to the audit log, with the number of records.

Three things with no retention job

Rights requests, the audit log and the breach register have no retention job. The first two go only when the project is closed. If your policy sets a limit for them, ask the operator to remove old rows from the database. A rights request keeps the contact the person gave, encrypted, for as long as its row stays.

Deletion#

How data leaves	What happens
A person asks for erasure	From the request, from Records, or from your server with `POST /sdk/v1/subjects/erase`. A consent still in force is withdrawn first. The identifying details are removed. The sealed decision history stays, tied only to a keyed hash
A person is inactive	With Erase after inactivity on, the same erasure runs after the period, following a notice by webhook
Evidence reaches the end of retention	The record and its events are deleted. Only a hash of each event stays, so the daily anchors still verify
You stop using the service	An owner exports, then closes the project. Its data is deleted after `PROJECT_DELETION_DAYS`, 30 by default, unless a legal hold is in force. The audit log stays. See Close a project
Backups	Outside the product. Backups keep deleted data until they expire. Ask the operator for the backup retention period

What erasure keeps: How consent is proven
Inactivity erasure and the Act: DPDP duties for security and retention

Outside services#

The software needs no outside service to record consent. These are the calls it can make.

Call	When	What is sent
Your webhook endpoints	When a subscribed event happens	The event. For consent events: the identifier type and fingerprint, and the identifier only if the project stores a readable copy
The translation service chosen in Project settings: Sarvam by default, or Azure AI Translator, Google Cloud Translation, or another service with an OpenAI-compatible API	When someone uses Translate in the console	The form or purpose wording. No personal data about visitors
IAB Europe Global Vendor List (`vendor-list.consensu.org`)	When the API starts and then about weekly	Nothing. It is a download. A different address can be configured
The sites you ask it to scan	When a scan runs, by hand or on a schedule	Ordinary page requests from a headless browser
The PIEDAP IAM service	When a console request carries an API token	The token, to be checked

Location is worked out from a database inside the API or from headers set by the operator's CDN. No outside geolocation service is called.
A translation service is a sub-processor only for your notice wording, and only if you use it. The default Sarvam key belongs to the operator. A project can add its own key or choose another service.
Whoever hosts the deployment, such as a cloud provider, is the operator's sub-processor. That is outside the software; ask the operator for the list.

Where data is stored#

What	Where
Everything the product stores	One PostgreSQL database
Console sessions and rate-limit counters	Redis
The request log	Standard output, where the operator collects it
In the visitor's browser	Only the consent cookies and local storage on your own site

The country the data sits in is where the deployment runs. Settings shows it under Where your data is kept, as the operator states it. Ask the operator for the backup location and any transfer outside India, and record both in your contract. A Significant Data Fiduciary has a further duty, listed in Other DPDP duties.

People's rights#

Right	How the product serves it
Access and portability	Records are found by identifier, hashed at lookup. They are exported as signed receipts with a summary of purposes, data used and partners
Withdrawal	In the preference centre, the consent portal, the hosted request form, from your server, or by your team
Erasure	As described under Deletion
Correction, grievance and the rest	Tracked as requests with a deadline. Your team does the work. A nomination is stored against the person

In the console: Handle a request
From your server: Withdraw and erase

Example record of processing#

Copy this entry and adjust it.

Field	Entry
Processing activity	Collecting, storing and proving consent and privacy choices
Purpose	Meeting notice and consent duties; proving consent; answering rights requests
Categories of people	Visitors and users of your sites and apps; where recorded, children and their parents or guardians
Categories of data	Pseudonymous identifier (keyed hash); consent decisions; country; hashed IP address; browser string; page address; language. Optional: encrypted readable identifier; contact given with a rights request. In the request log: client IP address
Recipients	The operator of the deployment as processor; your own webhook endpoints; the translation service you chose, for notice wording only
Transfers	Set by the hosting region of the deployment and by the location of your webhook endpoints and translation service
Retention	Evidence for the period set in Keep evidence for, counted from the consent's expiry date. Never less than one year after its last processing. Test records 30 days. Webhook delivery log 30 days. Evidence is deleted only where the operator has turned retention enforcement on
Security measures	The measures in Security model