Navigating the DPDP Act: A Comprehensive Guide to Compliance and Controls
The Digital Personal Data Protection (DPDP) Act of India brings sweeping changes to how organizations collect, use, and store private data. Discover what the DPDP Act means for your business, essential compliance controls to implement, and how Adayptus can streamline your privacy journey.
The Digital Personal Data Protection Act is often treated as a legal exercise — a policy to draft, a notice to publish, a consent checkbox to add. That framing is why so many DPDP programmes stall. The obligations that are genuinely hard are engineering problems: knowing where personal data actually lives, deleting it on request, and proving you did.
A privacy notice can be written in a week. Answering "which of our 40 systems hold this person's data, including backups, logs, analytics and that vector index the AI team built" is a different order of difficulty — and it is what the Act's rights provisions ultimately require you to do reliably and repeatedly.
This guide sets out who the Act applies to, the obligations that carry real operational weight, the technical controls that actually deliver compliance, and a sequenced plan for organisations starting from a standing start.
- 01DPDP is an engineering problem, not a documentation exercise — data discovery and deletion are the hard parts.
- 02You are a Data Fiduciary if you determine the purpose of processing — and the obligation does not transfer to your vendors.
- 03The Act has extraterritorial reach: it applies to processing outside India where goods or services are offered to people in India.
- 04Breach notification obligations sit alongside CERT-In's six-hour window, not instead of it.
- 05Personal data in AI training sets and vector indexes is in scope, and erasure there is genuinely difficult — design for it early.
Who the Act Applies To
The Act governs the processing of digital personal data — information about an identifiable individual, whether collected digitally or digitised afterwards. Three roles matter in practice.
| Role | Who it is | Carries the obligation? |
|---|---|---|
| Data Fiduciary | The organisation deciding why and how data is processed | Yes — accountability rests here and cannot be outsourced |
| Data Processor | A vendor processing on the Fiduciary's instructions | Bound by contract; the Fiduciary remains answerable |
| Data Principal | The individual the data is about | Holds the rights you must be able to service |
Two points catch organisations out. First, accountability does not transfer — using a processor does not move the obligation to them, which is why vendor due diligence and contractual terms matter. Second, the Act reaches processing that happens outside India where it relates to offering goods or services to individuals in India, so an overseas SaaS provider serving Indian customers is not exempt by virtue of geography.
The Obligations That Carry Real Weight
Several requirements are straightforward once someone owns them. A handful are genuinely demanding.
- Notice and consent. Clear, itemised, in plain language, with a real ability to withdraw. Withdrawal is the hard half — it must actually stop the processing downstream, not just flip a flag.
- Purpose limitation. Data collected for one purpose cannot quietly be reused for another. This is where analytics and machine-learning initiatives most often drift out of compliance.
- Data minimisation and retention. Collect what you need, keep it only as long as the purpose requires, then delete it. Most organisations have no enforced retention at all.
- Rights of the Data Principal. Access, correction, erasure and grievance redressal — each requiring you to locate the individual's data across every system.
- Reasonable security safeguards. The Act requires them without prescribing a checklist, which in practice means aligning to a recognised framework and being able to evidence it.
- Breach notification. Notification to the Data Protection Board and to affected individuals, running in parallel with existing CERT-In obligations.
- Children's data. Verifiable parental consent and restrictions on tracking and targeted advertising.
The question that reveals your true readiness: if a Data Principal asked you today to erase everything you hold about them, could you do it — including backups, log files, analytics warehouses, support-ticket attachments, and any AI training set or vector index? Most organisations discover the answer is no, and that the gap is architectural rather than procedural.
Why Erasure Is the Hardest Requirement
Deleting a row from a production database is trivial. The difficulty is everywhere else the data has propagated: nightly backups, replica environments, data warehouses, log aggregation, CRM and support tools, third-party analytics, and increasingly embeddings inside a vector store.
Backups deserve particular attention. Selectively deleting an individual from an immutable backup is usually impossible, so the workable approach is a documented policy combining defined backup retention with a rule that restored data is re-processed against outstanding erasure requests. That position needs to be reasoned and written down before someone asks, not improvised afterwards.
AI systems create a newer version of the same problem. Personal data absorbed into a fine-tuned model or embedded in a vector index cannot be surgically removed the way a database record can. If your organisation is deploying AI features, this belongs in the design conversation — our guide to AI governance under ISO 42001 and NIST AI RMF covers how to structure that, and AI governance advisory is where we help operationalise it.
The Controls That Actually Deliver Compliance
| Obligation | Control that makes it real |
|---|---|
| Knowing what you hold | Data discovery and classification, plus a maintained record of processing activities |
| Purpose limitation | Purpose tagging at collection, enforced in access policy rather than documented in a spreadsheet |
| Minimisation and retention | Automated retention schedules with enforced deletion jobs |
| Rights fulfilment | A request workflow with system-by-system runbooks and identity verification |
| Security safeguards | Encryption, least privilege, logging and monitoring, aligned to ISO 27001 controls |
| Breach notification | Detection capable of noticing, plus a rehearsed decision and reporting path |
| Processor accountability | Vendor assessment, contractual terms and periodic review with evidence |
Note how much of this overlaps with an existing security programme. Organisations already running ISO 27001 or preparing for SOC 2 have a meaningful head start, because encryption, access control, logging and vendor management are shared foundations rather than parallel work.
How DPDP Interacts With CERT-In
These are separate obligations that can be triggered by the same event, and they are frequently conflated. CERT-In directions require specified cyber incidents to be reported within six hours of detection, regardless of whether personal data was involved. DPDP adds notification to the Data Protection Board and to affected Data Principals where personal data is breached.
An incident involving personal data can therefore trigger both, on different timelines, to different recipients. The practical implication is that your incident response plan needs a decision step that evaluates each obligation independently — and someone authorised to make that call outside business hours. Our walkthrough of CERT-In six-hour reporting sets out the operational detail.
A Sequenced Implementation Plan
- 01Map your data. What personal data you hold, where it lives, why, and who it flows to. Everything else depends on this.
- 02Establish lawful basis and notice for each processing purpose, in plain language.
- 03Build the rights workflow — intake, identity verification, per-system runbooks, response deadlines and an audit trail.
- 04Implement retention and deletion as automated jobs, including a documented position on backups.
- 05Make consent withdrawal effective downstream, not merely recorded.
- 06Assess processors and update contracts with data-protection terms and audit rights.
- 07Align security safeguards to a recognised framework so "reasonable" is evidenced rather than asserted.
- 08Rehearse breach notification against both DPDP and CERT-In timelines, including out-of-hours sign-off.
- 09Bring AI systems into scope — training data, retrieval corpora and context windows all count.
Step one is not optional preparation; it is the dependency for everything else. Organisations that skip straight to drafting policies produce documents that describe an environment nobody has actually verified.
How Adayptus Helps
- DPDP Assessment — data mapping, gap analysis against the Act, and a prioritised remediation plan.
- Regulatory Compliance — where DPDP sits alongside RBI, SEBI or sector obligations.
- ISO 27001 Implementation — to evidence "reasonable security safeguards" against a recognised standard.
- Third-Party Risk Management — processor assessment and contractual assurance.
- Incident Response & DFIR — breach handling aligned to both DPDP and CERT-In timelines.
- Virtual CISO — senior ownership across privacy and security without a full-time hire.
Related reading: our DPDP Rules compliance roadmap covers the operational detail of the Rules, and our SOC 2 Type II guide explains how the underlying controls overlap.
Frequently Asked Questions
Click any question to expand the answer.
QDoes the DPDP Act apply to companies outside India?
Yes, where the processing relates to offering goods or services to individuals in India. An overseas SaaS provider with Indian customers is within scope regardless of where its infrastructure sits. This extraterritorial reach is comparable in structure to GDPR, so organisations already operating a mature privacy programme for Europe usually have transferable foundations, though the specific obligations differ and should be mapped rather than assumed equivalent.
QWhat is the difference between a Data Fiduciary and a Data Processor?
A Data Fiduciary determines the purpose and means of processing and carries the accountability. A Data Processor processes on the Fiduciary's instructions and is bound primarily through contract. The critical point is that engaging a processor does not transfer your obligations to them — if your vendor mishandles personal data you collected, you remain answerable, which is why processor assessment and contractual terms are a compliance control rather than a procurement formality.
QHow do we handle erasure requests when data is in backups?
Selective deletion from immutable backups is usually impossible, so the workable approach is a documented policy: erase from live systems immediately, define a bounded backup retention period after which the data expires naturally, and commit that any restore is re-processed against outstanding erasure requests before the data returns to production use. Reason this position out and record it in advance — improvising it after a request arrives is what creates exposure.
QDoes DPDP replace our CERT-In reporting obligations?
No — they are separate obligations that a single event can trigger simultaneously. CERT-In directions require specified cyber incidents to be reported within six hours of detection whether or not personal data was involved, while DPDP adds notification to the Data Protection Board and affected individuals where personal data is breached. Your incident response plan should evaluate each obligation independently, with a named person authorised to make that assessment outside business hours.
QWhere should we start if we have done nothing yet?
Data mapping, without exception. Until you know what personal data you hold, where it lives, why you have it and who it flows to, every other activity is guesswork — policies will describe an environment nobody verified, and rights requests cannot be fulfilled reliably. Organisations that skip to drafting notices produce documents that look compliant and fail the first real erasure request.
QDoes DPDP apply to personal data used in AI systems?
Yes. Personal data flowing into a model's context window, a retrieval corpus, a vector index or a fine-tuning dataset is being processed and carries the same obligations, including purpose limitation and erasure. The practical difficulty is that data embedded in a model or index cannot be surgically removed the way a database record can, which makes this an architecture decision rather than a policy one — and far cheaper to address before deployment than after.
Adayptus GRC Advisory
Strategic Intelligence Division
Adayptus Consulting is a premier provider of enterprise cybersecurity solutions, specializing in Managed SOC, Penetration Testing, and GRC strategy. Our intelligence division regularly publishes research to help CISOs navigate the evolving threat landscape.
