Plenty of guides tell you what the DPDP Act requires; fewer tell you how to actually get there. Compliance is a sequence of dependent steps, and doing them in the right order saves significant rework — you cannot write accurate notices, for instance, before you know what data you hold.
The good news is that the eighteen-month transition gives most organisations enough time to do this properly, provided they start deliberately rather than waiting for the deadline to loom.
This guide lays out a practical, sequenced path from a standing start to a defensible position, with each step building on the last. Treat it as a project plan rather than a reading list.
None of these steps is individually difficult, but the order and the dependencies matter, which is why a sequenced plan beats a scramble. Work through them deliberately, keep evidence as you go, and the eighteen-month window is comfortably enough to arrive at a position you can defend rather than merely hope holds up.
Step 1: Map your data
Begin by building an inventory of the personal data you hold: what you collect, where it lives, why you process it, and who you share it with. Include the easily forgotten stores — spreadsheets, logs, backups and processor systems.
This map is the foundation for everything else. It tells you the scope of your obligations and surfaces data you did not realise you held or no longer need.
Assign an owner to keep it current, because a one-off snapshot is stale within months as new systems and datasets appear.
It helps to involve the people who actually run the systems in this first step. Engineers and operations staff know where the forgotten databases, backups and log stores live, and their input is what turns a tidy theoretical map into an accurate one.
Step 2: Assign a lawful basis to each activity
With the map in hand, tie each processing activity to a basis: consent or a defined legitimate use. This step exposes activities that currently rely on nothing defensible — the gaps you most need to close.
Where consent applies, plan how you will capture and evidence it; where a legitimate use applies, confirm the processing genuinely fits the defined purpose.
Defaulting to consent wherever the fit is uncertain keeps you safe, since a stretched legitimate use is far riskier than an extra consent ask.
Documenting the basis for each activity, however briefly, pays off later. When the Board or a customer asks why you process a particular dataset, a one-line recorded rationale is the difference between a confident answer and an uncomfortable scramble.
Step 3: Rewrite notices and consent flows
Redesign your notices to be clear, itemised and in plain language, and rebuild consent capture so it is granular, deliberate and easy to withdraw. Remove bundling, pre-ticked boxes and dark patterns.
Make sure notices cover the essentials — data, purpose, withdrawal, rights and how to complain — and are available in the languages your users actually read.
Capture clean, timestamped consent records, because being able to show what was agreed and when is what demonstrates compliance later.
Test the new flows with real users before you ship them. If people cannot tell what they agreed to or cannot find how to withdraw, the flow has failed in spirit even if it ticks the legal boxes, and usability problems tend to surface as complaints.
Step 4: Build rights and grievance workflows
Stand up the operational machinery to honour data principal rights — access, correction, erasure, nomination — and to receive and resolve grievances within the prescribed time.
This means a clear intake channel, sensible identity verification, the technical ability to find and delete data across systems, and a tracker that ensures nothing misses its deadline.
A responsive grievance channel is also your best protection against complaints escalating to the Board, so it is worth resourcing properly.
Centralising rights handling into a single intake and tracker is far more reliable than scattering it across teams. One queue, one owner and one set of service levels make it much harder for a request to quietly miss its deadline.
Step 5: Implement security safeguards
Implement the reasonable security safeguards the Rules expect: encryption or masking of personal data, access control with multi-factor authentication, and logging retained for at least a year.
This is usually the longest and most resource-intensive step, and the most important, because security failures carry the Act's largest penalties.
Extend the same expectations to your processors through contracts, since you remain accountable for data they hold on your behalf.
Budget realistically for this step, because it is usually the longest. Remediation — implementing controls, writing policies and wiring up tooling — tends to expand once you start, so giving it generous time in the plan protects the deadline.
Step 6: Prepare for breaches
Build and test a breach-response plan that can meet the two-tier, 72-hour notification duty. Define detection, triage, decision-making and notification, with pre-drafted templates and named owners.
Rehearse it. A plan that has never been exercised tends to fall apart under the pressure of a real incident, exactly when the clock is running.
Tie the plan to your logging and monitoring, since you cannot report what you cannot detect.
Run at least one tabletop exercise of the breach plan. Walking a realistic scenario through detection, decision and notification reveals the gaps — unclear ownership, missing contacts, slow approvals — that only appear under pressure.
Free resource
DPDP Compliance Checklist
A practical, step-by-step DPDP readiness checklist you can work through, section by section.
Step 7: Contract with processors and handle special cases
Put valid data processing agreements in place with every processor, and review their security and breach-handling capabilities. Map the sub-processor chain so you know where your data actually goes.
If you process children's data, build age assurance and verifiable parental consent, and remove tracking and targeted advertising aimed at minors.
If you may be designated a Significant Data Fiduciary, begin lining up a DPO, a DPIA methodology and an independent auditor, since these take the longest to stand up.
Treat processor onboarding as a recurring control, not a one-time task. New vendors arrive constantly, so making a data processing agreement and a security review part of procurement keeps the chain of accountability intact as you grow.
Step 8: Govern, record and monitor
Finally, wrap the programme in governance: a named owner, documented policies, evidence that controls operate, and a regular review cadence. Keep records of notices, consents, rights requests and breaches.
Monitoring matters because compliance is not a one-off. New products and data flows appear constantly, and a programme that reviews itself stays accurate while one that is built once drifts out of date.
Work backwards from the deadline, reserve the closing months for audit and steady-state operation, and you convert a distant requirement into a series of manageable milestones — the essence of practical dpdp compliance.
Finally, give the whole programme a named owner with leadership backing. Compliance that belongs to everyone belongs to no one, and a single accountable owner with a roadmap tied to the deadline is the strongest predictor of actually getting there.
Free consultation
Need help getting DPDP-ready?
Talk to our compliance team — we’ll map your gaps against the Act and the 2025 Rules.