DPDP duties for security and retention
Each DPDP Act duty about security safeguards, breach reports, erasure and retention, with what PIEDAP Consent does and what remains yours.
Each duty about security safeguards, breaches, erasure and retention under India's DPDP Act, 2023 and DPDP Rules, 2025, with what the product does and what remains yours.
Confirm the citations
Where the product cites a section or rule in its own messages, this page uses the same citation. This is not legal advice. Confirm each citation with your counsel.
How to read the tables#
- Duty is a short version of the section or rule beside it. Read the text itself before you rely on it.
- You are the Data Fiduciary. The product processes consent records for you.
- The operator is whoever runs your deployment.
- Rules 6, 7 and 8 apply from 13 May 2027. DPDP dates lists every date.
Security safeguards#
| Duty | Section or rule | What the product does | What remains yours |
|---|---|---|---|
| Use encryption, obfuscation or masking. | Rule 6(1)(a) | Identifiers are stored as HMAC-SHA256 hashes. The optional readable copy, and stored secrets, are encrypted with AES-256-GCM. A consent record holds the IP address only as a salted hash. | Encryption in transit and of the database at rest. These belong to the operator. |
| Control access. | Rule 6(1)(b) | The console needs a PIEDAP IAM session and is scoped to one project. A live publishable key answers only the websites and apps listed for it. Secret keys are refused from browsers and need a scope per key for calls on a person as a whole. | Deciding who in your organisation gets access to the project, and turning roles on so each person has only what their work needs. |
| Keep logs and monitor access. | Rule 6(1)(c) | An audit log of console changes, reads of personal data in the console, and calls on a person with a secret key. It is append-only in the database, and each entry is sealed to the one before it with a key kept outside the database. Verify the log recomputes the chain. A console change waits for its entry. The log can be downloaded and read by your SIEM. Consent evidence is tamper-evident. | Reviewing the logs and keeping the SIEM copy. |
| Keep backups so processing can continue. | Rule 6(1)(d) | scripts/backup.sh takes a dump with its SHA-256 and row counts. scripts/restore-check.sh restores it into a throwaway database and checks the counts, the latest evidence anchors and the audit log chains against recovery targets. |
Running both on a schedule, keeping copies away from the host and setting the targets. These belong to the operator. |
| Hold a valid contract with each Data Processor. | Section 8(2) | None in the product. | Your contract with the operator. |
- Backups: Back up and restore
- The audit log chain: Verify the audit log
- Facts for the contract: Data processing
- The full description: Security model
Breach#
| Duty | Section or rule | What the product does | What remains yours |
|---|---|---|---|
| Tell the Board without delay. Then send the detailed report within 72 hours of becoming aware, or a longer period the Board allows. | Section 8(6); Rule 7(2) | The Breach register records each incident with the Rule 7(2) details. It counts down the 72 hours from awareness, or to the extension the Board allowed. A breach.report_due webhook is sent 12 hours before the deadline. The register generates the Board report. |
Detecting the breach. Recording it as soon as you are aware. Sending the report to the Board. |
| Tell each affected person without delay. | Section 8(6); Rule 7(1) | The register generates the plain-language notice. Send to your systems passes it, with its SHA-256, in the breach.people_notice webhook, and records when and how people were told. |
Sending the notice through the person's account or registered contact. The product holds no contact details and sends no email or SMS. |
Record a breach shows the register.
Erasure and retention#
| Duty | Section or rule | What the product does | What remains yours |
|---|---|---|---|
| Erase on withdrawal, or once the purpose is no longer served, unless a law requires retention. Make your Data Processors erase. | Section 8(7) | Erasing a person withdraws any consent still in force, then removes the identifying details from each record. You receive consent.withdrawn for each consent that was still in force, and subject.erased for each record. Both carry the subject fingerprint as it was before the erasure. For each partner registered as a Data Processor, subject.erased lists an erase task with a due date and how long it may keep processing logs, and the Processors page tracks what was reported. |
Erasing the person's data in your own systems when the webhook arrives. Passing each erase task to the processor. Deciding when a purpose is no longer served. |
| At the end of the contract, have your processor delete the data it holds for you. | Section 8(7) | An owner can close the project: export first, then the whole project is deleted after PROJECT_DELETION_DAYS (30 by default), cancellable until then. A legal hold postpones it. project.closing and project.deleted tell your systems. See Close a project. |
Exporting what you keep. Asking the operator how long backups hold the data. |
| For the Third Schedule classes, erase after three years without contact. Tell the person at least 48 hours before. | Section 8(8); Rule 8(1), (2) | Erase after inactivity in Project settings. You report use with recordActivity; consent changes and rights requests count too. A subject.erasure_notice webhook goes out 72 hours before the period ends. Erasure follows at the end of the period, and never less than 48 hours after the notice. A subject.erased_inactive webhook then asks you to erase the rest. |
Reporting activity. Sending the 48-hour notice to the person. Erasing your own data, except what the Rules let you keep. Knowing whether you are in a Third Schedule class. |
| Keep the personal data, traffic data and logs of a processing for at least one year. | Rules 6(1)(e), 8(3) | Keep evidence for cannot be set below one year. The retention job never deletes a record less than a calendar year after its last processing or its last event. | The same one-year rule for logs in your own systems. |
| Keep the evidence a complaint, an inquiry or an appeal needs. | Section 29, in practice | A legal hold on a person, a record or the project keeps records, their events and their processing logs past retention, and postpones the project's deletion. Identifiers are still erased on request. See Legal holds. | Placing the hold, and releasing it when the case ends. |
Inactivity erasure#
- If no endpoint subscribes to
subject.erasure_notice, nothing is erased. - For records under the Act, the inactivity clock starts no earlier than 13 November 2025. That is the date the Rules were published.
- As the product reads the Third Schedule, its three years cannot start before the Rules commenced, and the Rules commence in stages. The product takes the earliest date, so erasure is never later than required.
- The Third Schedule lists e-commerce entities and social media intermediaries with at least 2 crore registered users in India. It also lists online gaming intermediaries with at least 50 lakh.
Inactivity erasure explains the setting.
Details kept for a year after erasure#
A record under the Act can be erased less than a year after its last processing. The product then holds some details back until the year is up.
| Detail | When it is removed |
|---|---|
| Linked identifiers | At once |
| Encrypted identifier | When the year is up |
| Subject fingerprint | When the year is up |
| IP address hash | When the year is up |
| Browser and page | When the year is up |
metadata |
When the year is up |
In that year the console, receipts and webhooks leave the kept details out. Two paths still return metadata: reading the record with a secret key, and a property export.
Evidence is deleted only if the operator turns it on
A record past its retention period is deleted only when the deployment runs with retention enforcement on. Ask the operator whether it is. Configuration lists the setting.