Most teams encountering the DPDP Act for the first time want the same thing: a clear, complete picture of what compliance actually requires. The Act and the 2025 Rules together create a set of obligations that, taken as a whole, define a recognisable programme — and seeing that whole picture is the best way to plan.
The requirements are interdependent. You cannot write accurate notices without knowing what data you hold; you cannot run breach reporting without logging; you cannot honour erasure without the ability to delete. That is why a structured overview beats a random checklist.
This guide gives that overview, grouping the requirements into the logical building blocks of a programme — from data mapping through security, rights and recordkeeping — so you can scope the work realistically.
Know your data: mapping and inventory
The foundation of every requirement is knowing what personal data you hold, where it lives, why you process it and who you share it with. Without this map, every downstream obligation is guesswork.
A data inventory should cover primary systems and the shadow stores teams forget — spreadsheets, logs, backups and processor systems. It should record the purpose and lawful basis for each category of data.
This is unglamorous work, but it is the single highest-value investment you can make, because notices, retention, security and rights handling all depend on it.
A good data map is also living documentation that pays dividends well beyond compliance. It informs security architecture, supports incident response, and helps product teams understand what data actually exists before they build on top of it.
Establish a lawful basis for every activity
Each processing activity needs an identifiable basis: either consent that meets the Act's standard, or a defined legitimate use. Mapping activities to bases surfaces the ones that currently rely on nothing defensible.
Where consent is the basis, you must be able to show it was validly obtained and can be withdrawn. Where a legitimate use applies, you must stay strictly within its purpose.
This basis-mapping is where many organisations discover gaps — processing that has simply never had a clear justification — and closing those gaps is core compliance work.
The activities that most often lack a clear basis are the incidental ones — analytics, enrichment, internal experimentation — precisely because no one set out to make a decision about them. Surfacing and regularising these is where basis-mapping delivers the most value.
Notice, consent and rights
The requirements here are to give clear, itemised notices, capture valid and withdrawable consent, and provide the means for data principals to exercise their rights — access, correction, erasure and nomination — and to raise grievances.
These are operational requirements, not policies on a shelf. You need working flows that capture consent cleanly, respond to rights requests within the prescribed time, and resolve grievances. Building these workflows reliably is a central part of dpdp compliance.
Records matter throughout: being able to show what was consented to, and how each request was handled, is what demonstrates compliance to the Board.
Treat these as engineering requirements, not legal aspirations. A rights request that cannot be fulfilled because the data is scattered across systems is a failed obligation, however good the intent, so the supporting workflows must be genuinely built and tested.
Security safeguards
The Act requires reasonable security safeguards, and the Rules point to concrete measures: encryption or masking, access control with multi-factor authentication, and the retention of logs for at least a year to support investigation.
Because the largest penalties attach to security failures, this requirement deserves disproportionate attention. It applies to data held by your processors as well as your own systems.
Security is also where compliance and good engineering align: the measures the Rules expect are simply sound practice for protecting any sensitive system.
Because security underpins the Act's largest penalties, it deserves a disproportionate share of attention and budget. The good news is that the measures expected are also simply sound engineering, so the investment improves your resilience as well as your compliance.
Breach detection and reporting
You must be able to detect breaches, contain them, and report them — an immediate notice to the Board and affected individuals on becoming aware, followed by a fuller report generally within 72 hours.
This requires more than a policy. It needs monitoring and logging that surface incidents, an incident-response plan that can be executed under pressure, and pre-prepared notification templates.
Rehearsing the process before you need it is what turns the 72-hour duty from a source of panic into a manageable, repeatable procedure.
Detection is the part organisations most often neglect. Many breaches are discovered late or by third parties, which makes the 72-hour clock almost impossible to meet, so investing in monitoring is as important as investing in the response plan itself.
Retention, erasure and accuracy
The requirements here are to keep data accurate and up to date, retain it no longer than necessary, and erase it when its purpose is served or consent is withdrawn, unless law requires retention.
Meeting them needs defined retention schedules and the technical ability to delete data across all the places it lives. Indefinite retention is both a compliance failure and an unnecessary risk.
Accuracy obligations bite hardest where data drives decisions about people, so processes for correction and updating matter most in those contexts.
Retention and accuracy are easy to underrate, yet they shape both risk and cost. Defined schedules, automated deletion and clean correction processes keep your data footprint small, your decisions sound, and your exposure in any breach contained.
Free resource
The Ultimate Guide to the DPDP Act
A practical, plain-English handbook to the DPDP Act & 2025 Rules — scope, roles, consent, safeguards and a readiness path.
Processors, children and SDF duties
You must contract properly with every processor and oversee them, since you remain accountable. If you process children's data, you must obtain verifiable parental consent and avoid harmful tracking. If you are designated a Significant Data Fiduciary, you must add a DPO, DPIAs and independent audits.
These requirements scale with your situation. A small business with no children's data and few processors faces a lighter version; a large platform handling sensitive data at scale faces the full set.
Knowing which of these apply to you early shapes how heavy your programme needs to be and how much lead time you should budget.
Scoping these situational requirements early prevents nasty surprises. Discovering late in a project that you process children's data, or that you are likely to be designated significant, can force expensive rework that timely planning would have avoided.
Governance, records and monitoring
Underpinning everything is governance: a named owner, documented policies, evidence that controls operate, and ongoing monitoring rather than a one-off project. The Act effectively rewards organisations that can demonstrate, not just assert, compliance.
Keeping records — of notices, consents, rights requests, breaches and decisions — is what turns a programme into something defensible. If the Board asks, evidence is what answers.
Treating compliance as a continuous, owned function, with a regular review cadence, is what keeps you compliant as your business and the regulatory guidance evolve.
The organisations that fare best treat compliance as a product with an owner, a backlog and a release cadence, rather than a document signed once and forgotten. That mindset is what keeps a programme accurate as the business and the guidance evolve.
Free consultation
Need help getting DPDP-ready?
Talk to our compliance team — we’ll map your gaps against the Act and the 2025 Rules.