DPDP compliance moves from policy to operations
Privacy leader Tanin Chakraborty’s ETCISO commentary highlights the operational change created by India’s DPDP Rules: organisations need working consent, retention, rights and incident processes—not only a revised privacy notice.
The exact obligations and commencement dates must always be checked against the current official text. The implementation lesson is durable: privacy teams need evidence that choices and requests move correctly through real systems.
Redesign notices around purpose
A notice should help a person understand what data is collected, why it is needed and how to exercise rights. Start with the processing inventory and create a notice-to-system map.
| Notice statement | Operating evidence |
|---|---|
| Purpose of processing | Approved purpose linked to system and owner |
| Data collected | Field-level inventory and collection screen |
| Consent choice | Notice version, affirmative action and timestamp |
| Withdrawal | Accessible route and completion log |
| Retention | Trigger, period, exception and deletion evidence |
| Grievance route | Case record, decision and response trail |
Make withdrawal travel downstream
Consent is not controlled if withdrawal only changes a front-end flag. Test whether the instruction reaches analytics, marketing, customer platforms, data warehouses and processors. Where another lawful obligation requires retention, restrict the data and document the reason rather than silently ignoring the request.
Build incident response around facts
Privacy and security teams need one rehearsed path for identifying affected data, people, systems, processors and containment actions. Notification decisions depend on reliable facts, so logging and supplier cooperation are essential.
Evidence to prepare before an incident
- Current data-flow and processor records
- Named privacy, security, legal and business responders
- Contractual notification routes and contacts
- Templates that separate confirmed facts from assumptions
- Decision records, timestamps and approval authority
- Post-incident corrective-action tracking
Treat retention as a technical control
A retention schedule is only the design. Operation requires rules in source systems, archives, backups and vendor platforms. Sample records past their trigger date and confirm deletion, anonymisation or a documented exception.
Product, legal, records, security and engineering teams must agree on triggers. “Seven years” without identifying when the clock begins is not an executable rule.
Add age and guardian scenarios where relevant
Services used by children need a defined approach to age signals and verifiable guardian involvement. Avoid collecting excessive identity data merely to prove age. The design should balance reliability, proportionality, accessibility and fraud risk, with legal review of the current requirements.
A practical DPDP control-testing plan
- Sample consent records across channels and notice versions.
- Submit a withdrawal and trace it through connected systems.
- Run access, correction, erasure and grievance scenarios.
- Test processor notification and evidence delivery.
- Sample expired records against the retention schedule.
- Exercise a breach involving both internal systems and a vendor.
- Record gaps, owners, due dates and independent retesting.
ICyberWave perspective
DPDP readiness is strongest when legal requirements are translated into testable workflows with retained evidence. ICyberWave supports privacy mapping, gap assessment, consent and rights design, processor assurance, ISO 27701 alignment and internal audit. Read our data fiduciary guide and DPDP implementation spotlight for the next steps.