10 November 2026
Mono Team
DPDP for Engineering Teams: Consent, Rights Requests and Retention in Code
Data protection
What the DPDP Act asks engineering to prove, and the five components that prove it: a consent service, identity matching, a request router, deletion jobs and an audit log.
Implementing the DPDP Act in software comes down to five components: a consent service, identity matching, a request router, deletion jobs and an audit log. This guide covers what each one stores and does, and the order to build them.
The legal memo tells you what must be true. This is how to make it true in your systems, and how to prove it.
What the Act asks engineering to prove
Every duty ends in a question someone can ask you: the Data Protection Board, a customer's security team, or the person the data is about. Engineering's job is to answer each one from a record.
| The question | Where it comes from | What you need to show |
|---|---|---|
| Did this person consent, and to what? | Where it comes from: Section 6(10): the Data Fiduciary must prove notice and consent | What you need to show: The consent record, with the notice version shown at the time |
| They withdrew. Did you stop? | Where it comes from: Section 6(6): stop processing, and get your processors to stop | What you need to show: The withdrawal, and when each system and vendor acted on it |
| What do you hold on me? | Where it comes from: Section 11: a summary of the personal data and how it is processed | What you need to show: A report drawn from every system that holds the person's data |
| Why do you still have this? | Where it comes from: Section 8(7): erase when the purpose is over | What you need to show: The retention period for that system, and its deletion log |
| What happened in the breach? | Where it comes from: Section 8(6) and Rule 7: a detailed report to the Board within 72 hours | What you need to show: Access logs and an incident timeline |
These duties start on 13 May 2027. You can't create records for the past, so the logging has to be running before that date.
Reference architecture: five components
We add five components alongside the systems you already run. None of them replaces your app, CRM or data warehouse. The diagram is on our DPDP implementation page.
- Consent service. Holds the purpose list, every version of every notice, and the consent ledger.
- Identity matching. Knows that the app user, the CRM contact and the warehouse row are one person.
- Request router. Takes a rights request or a withdrawal and sends it to every system that holds that person's data.
- Deletion jobs. Remove data when its retention period ends, or on request.
- Audit log. Records each step, so the evidence is in one place.
The purpose list comes first
Consent under the Act is for a specified purpose. So the first thing to write is a short list of purposes, each with a stable ID: order delivery, marketing email, credit assessment.
Everything else points at these IDs. The notice text names them. Each consent record carries one. Each downstream system is tagged with the purposes it serves, which is how a withdrawal later finds the right systems.
The consent ledger
The ledger is append-only. A withdrawal is a new row, not an edit to the old one, so the history stays intact. Each row holds:
| Field | What it holds |
|---|---|
| Person | What it holds: Your internal ID for the person, from identity matching |
| Purpose ID | What it holds: One purpose per row |
| Action | What it holds: Granted, denied or withdrawn |
| Notice version | What it holds: The version of the notice the person was shown |
| Time | What it holds: When it happened |
| Channel | What it holds: Where it was captured: web, app, call centre, or a paper form entered later |
| Proof | What it holds: What the person did: the screen, the control and its state |
| Source | What it holds: Your own system, or a registered Consent Manager if you connect to one |
Store the notice text itself, not a link to the live page. The page will change, and you need to show what the person saw on the day.
Propagating withdrawal to CRM, analytics and processors
Withdrawal is where designs most often fall short: the app records it, and the CRM keeps sending emails. The Act asks you to stop processing and to get your processors to stop (Section 6(6)). Withdrawing has to be about as easy as giving consent (Section 6(4)).
Treat a withdrawal as an event that other systems subscribe to:
- The consent service writes the withdrawal to the ledger and publishes an event with the person and the purpose ID.
- Each system that serves that purpose acts on it. The CRM stops the campaign, analytics drops the person from the audience, the warehouse flags the rows.
- Each vendor gets the same instruction through its API, or by file or ticket where it has no API.
- Every system reports back, and the audit log records which one acted and when.
The report back is the part that matters. If three systems confirmed and one did not, you have a known gap to chase. Without it, you don't know whether you stopped.
Retention and deletion jobs
The Act asks you to erase personal data when consent is withdrawn or the purpose is over, unless a law requires you to keep it (Section 8(7)). The Rules add a floor: personal data, its traffic data and processing logs are kept for at least one year (Rule 8(3)). So each system needs a minimum and a maximum.
Write one retention entry per system: what data it holds, for which purpose, the minimum period, the maximum period, and any other law that requires a longer hold. Then:
- Run deletion as scheduled jobs. One per system, driven by the retention entries, not a one-off script.
- Log what was deleted. The system, the count, the rule that triggered it and the time. Not the data itself.
- Cover the copies. Warehouse tables, exports and analytics audiences are in scope too.
- Handle backups on paper. Document how long they are kept, and make sure deleted data is not restored into live systems.
- Record delete or anonymise. Decide which one each system does. Whether anonymising counts as erasing is a question for your lawyers.
Logging for audits without over-collecting
Rule 6 asks for logs that can detect unauthorised access to personal data, kept for one year. But logs hold personal data too. A log that copies whole request bodies is a second database of personal data, usually with weaker controls than the first.
- Log the event, who did it, the record ID and the time. Not the content of the record.
- Keep consent and request evidence in the audit log, and security logs in your security tooling. Give both a retention period.
- Limit who can read the logs, and log that access as well.
- Test it: can you answer the five questions at the top of this guide from the logs alone?
Build vs buy a CMP
A consent management platform (CMP) gives you the banner, the preference centre and a ledger. It does not connect itself to your CRM, warehouse and vendors. Propagating withdrawals, running deletion jobs and handling rights requests are integration work either way.
- Buying fits when consent is mostly collected on websites, there are many third-party tags, and the engineering team is small.
- Building fits when consent sits inside product flows such as onboarding or a loan journey, and you want consent in your own data model.
- Either way, keep the purpose IDs and a full export of the ledger under your control.
A CMP is not the same as a registered Consent Manager. Our Consent Manager decision guide explains the difference.
Implementation checklist
In the order we build it:
- 1. Map the data. List every system and vendor that holds personal data, with an owner for each.
- 2. Write the purpose list. Give each purpose an ID.
- 3. Version the notices. Store the text of each version.
- 4. Stand up the consent ledger. Capture new consents into it.
- 5. Match identities. Link the same person across systems.
- 6. Publish withdrawal events. Connect each system and vendor, with a report back.
- 7. Build rights-request intake. One entry point, an identity check, routing and deadline tracking.
- 8. Write retention entries. Run deletion jobs from them.
- 9. Set up access logs and a breach runbook. One runbook for CERT-In and the Board.
- 10. Run a drill. One access request, one withdrawal, one deletion and one mock breach, each answered from records.
Step 1 is what a DPDP gap assessment produces. For the law behind each step, read the DPDP Act explained.
This guide covers the engineering side and is not legal advice. Our partner law firm gives the written legal opinion on how the Act applies to you.
Sources: Digital Personal Data Protection Act, 2023, Sections 6, 8 and 11. Digital Personal Data Protection Rules, 2025, Rules 6, 7 and 8. Last reviewed 10 November 2026.
Implementing the DPDP Act in software comes down to five components: a consent service, identity matching, a request router, deletion jobs and an audit log. This guide covers what each one stores and does, and the order to build them.
The legal memo tells you what must be true. This is how to make it true in your systems, and how to prove it.
What the Act asks engineering to prove
Every duty ends in a question someone can ask you: the Data Protection Board, a customer's security team, or the person the data is about. Engineering's job is to answer each one from a record.
| The question | Where it comes from | What you need to show |
|---|---|---|
| Did this person consent, and to what? | Where it comes from: Section 6(10): the Data Fiduciary must prove notice and consent | What you need to show: The consent record, with the notice version shown at the time |
| They withdrew. Did you stop? | Where it comes from: Section 6(6): stop processing, and get your processors to stop | What you need to show: The withdrawal, and when each system and vendor acted on it |
| What do you hold on me? | Where it comes from: Section 11: a summary of the personal data and how it is processed | What you need to show: A report drawn from every system that holds the person's data |
| Why do you still have this? | Where it comes from: Section 8(7): erase when the purpose is over | What you need to show: The retention period for that system, and its deletion log |
| What happened in the breach? | Where it comes from: Section 8(6) and Rule 7: a detailed report to the Board within 72 hours | What you need to show: Access logs and an incident timeline |
These duties start on 13 May 2027. You can't create records for the past, so the logging has to be running before that date.
Reference architecture: five components
We add five components alongside the systems you already run. None of them replaces your app, CRM or data warehouse. The diagram is on our DPDP implementation page.
- Consent service. Holds the purpose list, every version of every notice, and the consent ledger.
- Identity matching. Knows that the app user, the CRM contact and the warehouse row are one person.
- Request router. Takes a rights request or a withdrawal and sends it to every system that holds that person's data.
- Deletion jobs. Remove data when its retention period ends, or on request.
- Audit log. Records each step, so the evidence is in one place.
The purpose list comes first
Consent under the Act is for a specified purpose. So the first thing to write is a short list of purposes, each with a stable ID: order delivery, marketing email, credit assessment.
Everything else points at these IDs. The notice text names them. Each consent record carries one. Each downstream system is tagged with the purposes it serves, which is how a withdrawal later finds the right systems.
The consent ledger
The ledger is append-only. A withdrawal is a new row, not an edit to the old one, so the history stays intact. Each row holds:
| Field | What it holds |
|---|---|
| Person | What it holds: Your internal ID for the person, from identity matching |
| Purpose ID | What it holds: One purpose per row |
| Action | What it holds: Granted, denied or withdrawn |
| Notice version | What it holds: The version of the notice the person was shown |
| Time | What it holds: When it happened |
| Channel | What it holds: Where it was captured: web, app, call centre, or a paper form entered later |
| Proof | What it holds: What the person did: the screen, the control and its state |
| Source | What it holds: Your own system, or a registered Consent Manager if you connect to one |
Store the notice text itself, not a link to the live page. The page will change, and you need to show what the person saw on the day.
Propagating withdrawal to CRM, analytics and processors
Withdrawal is where designs most often fall short: the app records it, and the CRM keeps sending emails. The Act asks you to stop processing and to get your processors to stop (Section 6(6)). Withdrawing has to be about as easy as giving consent (Section 6(4)).
Treat a withdrawal as an event that other systems subscribe to:
- The consent service writes the withdrawal to the ledger and publishes an event with the person and the purpose ID.
- Each system that serves that purpose acts on it. The CRM stops the campaign, analytics drops the person from the audience, the warehouse flags the rows.
- Each vendor gets the same instruction through its API, or by file or ticket where it has no API.
- Every system reports back, and the audit log records which one acted and when.
The report back is the part that matters. If three systems confirmed and one did not, you have a known gap to chase. Without it, you don't know whether you stopped.
Retention and deletion jobs
The Act asks you to erase personal data when consent is withdrawn or the purpose is over, unless a law requires you to keep it (Section 8(7)). The Rules add a floor: personal data, its traffic data and processing logs are kept for at least one year (Rule 8(3)). So each system needs a minimum and a maximum.
Write one retention entry per system: what data it holds, for which purpose, the minimum period, the maximum period, and any other law that requires a longer hold. Then:
- Run deletion as scheduled jobs. One per system, driven by the retention entries, not a one-off script.
- Log what was deleted. The system, the count, the rule that triggered it and the time. Not the data itself.
- Cover the copies. Warehouse tables, exports and analytics audiences are in scope too.
- Handle backups on paper. Document how long they are kept, and make sure deleted data is not restored into live systems.
- Record delete or anonymise. Decide which one each system does. Whether anonymising counts as erasing is a question for your lawyers.
Logging for audits without over-collecting
Rule 6 asks for logs that can detect unauthorised access to personal data, kept for one year. But logs hold personal data too. A log that copies whole request bodies is a second database of personal data, usually with weaker controls than the first.
- Log the event, who did it, the record ID and the time. Not the content of the record.
- Keep consent and request evidence in the audit log, and security logs in your security tooling. Give both a retention period.
- Limit who can read the logs, and log that access as well.
- Test it: can you answer the five questions at the top of this guide from the logs alone?
Build vs buy a CMP
A consent management platform (CMP) gives you the banner, the preference centre and a ledger. It does not connect itself to your CRM, warehouse and vendors. Propagating withdrawals, running deletion jobs and handling rights requests are integration work either way.
- Buying fits when consent is mostly collected on websites, there are many third-party tags, and the engineering team is small.
- Building fits when consent sits inside product flows such as onboarding or a loan journey, and you want consent in your own data model.
- Either way, keep the purpose IDs and a full export of the ledger under your control.
A CMP is not the same as a registered Consent Manager. Our Consent Manager decision guide explains the difference.
Implementation checklist
In the order we build it:
- 1. Map the data. List every system and vendor that holds personal data, with an owner for each.
- 2. Write the purpose list. Give each purpose an ID.
- 3. Version the notices. Store the text of each version.
- 4. Stand up the consent ledger. Capture new consents into it.
- 5. Match identities. Link the same person across systems.
- 6. Publish withdrawal events. Connect each system and vendor, with a report back.
- 7. Build rights-request intake. One entry point, an identity check, routing and deadline tracking.
- 8. Write retention entries. Run deletion jobs from them.
- 9. Set up access logs and a breach runbook. One runbook for CERT-In and the Board.
- 10. Run a drill. One access request, one withdrawal, one deletion and one mock breach, each answered from records.
Step 1 is what a DPDP gap assessment produces. For the law behind each step, read the DPDP Act explained.
This guide covers the engineering side and is not legal advice. Our partner law firm gives the written legal opinion on how the Act applies to you.
Sources: Digital Personal Data Protection Act, 2023, Sections 6, 8 and 11. Digital Personal Data Protection Rules, 2025, Rules 6, 7 and 8. Last reviewed 10 November 2026.
FAQ
Questions and answers
In an append-only ledger with one row per person, purpose and action: granted, denied or withdrawn. Each row carries the notice version shown, the time, the channel and proof of what the person did.
Publish each withdrawal as an event. The systems you run subscribe to it. Vendors get it through their API, or by file or ticket where there is no API. Each one reports back, and you log which one acted and when.
Consent and withdrawal records, each step of a rights request, deletion logs and access logs. Rule 6 asks for logs that can detect unauthorised access, kept for one year. Log events and record IDs, not the personal data itself.
Yes. You need consent records you can prove, not a particular product. Some companies buy a platform; many build consent capture and logging into their own apps.