The Digital Personal Data Protection Rules were notified on 13 November 2025. For most enterprises, the countdown that matters is now running: consent-manager provisions take effect on 13 November 2026, and the substantive compliance obligations follow on 13 May 2027.
Most CISOs we work with are already through the easy 30% — a refreshed privacy policy, a consent banner, a draft DPO charter. That work is visible, it reassures the board, and it is finished in a few weeks. The problem is that it is the least demanding part of the programme. The hard 70% is operational, it is largely invisible to the board, and it consumes the entire runway.
Data discovery is bigger than it looks
The first hard question is deceptively simple: what personal data do you hold, where does it live, and who in the processor chain touches it? Most enterprises underestimate this by an order of magnitude.
Structured databases are the easy case. The audit pain compounds in the unstructured estate — file shares, email archives, backups, log stores, development environments, and the copied production data sitting in test systems. Personal data leaks into all of them, and none of them appear in a tidy data-flow diagram. Discovery is not a one-time scan; it is an operating capability you have to build and keep running.
This is also where data protection and cyber-resilience architecture earns its place — because you cannot protect, minimise, or erase data you have not first located across the full estate, including its backup and archive copies.
Consent is an operating model, not a button
The consent banner is the visible 5%. Behind it sits the real work: capturing consent in a form that is auditable, honouring withdrawal across every downstream system, and integrating with the interoperable consent-manager platforms that come into force on 13 November 2026.
Consent managers are required to retain records of consent, notice, and data-sharing activity for at least seven years, and they cannot read the content of the data they broker. Building systems that can accept, honour, and log consent requests from these third parties is an integration programme — and integration programmes take most of the runway they are given.
Processor agreements become a programme
Every vendor that touches personal data needs DPDPA-aligned terms: defined processing purposes, breach-notification clocks, audit rights, and sub-processor transparency. For an enterprise with 200-plus processors, that is not a contract review — it is a programme with its own tracking, escalation, and legal-review load. Starting it late is the single most common way this deadline is missed.
Breach reporting runs on parallel clocks
The reporting clock starts when you become aware of a breach — and a single incident rarely triggers only one obligation. The same event can carry parallel timelines under RBI, SEBI, IRDAI, CERT-In, and now DPDPA, each with its own definition of “aware” and its own deadline. The only way to know your organisation can meet them all is to run the tabletop before the incident, not during it.
Where cryptography and key management fit
Minimisation, purpose limitation, and erasure are easier to demonstrate when the underlying data is encrypted and the keys are governed. For regulated workloads, FIPS-grade key management and HSM-backed encryption turn several DPDPA obligations from policy claims into technical controls you can evidence in an audit — which is exactly what a regulator will ask for.
The honest summary
Architecture supports DPDPA compliance; it does not replace the operational work. The privacy policy is not the programme. Discovery across the unstructured estate, a consent operating model, processor-agreement remediation, and rehearsed breach reporting are — and each one takes months, not weeks.
If your DPDPA programme is further along on documentation than on tested capability, that gap is worth closing now, while there is still runway to close it in.