You’ve read the Digital Personal Data Protection Act. You’ve sat through the briefings. You may have even completed a gap assessment, and then someone across the table asked: “So, now what?” That question is where most DPDP compliance journeys quietly lose momentum.
Earlier this summer, that’s exactly the question three privacy practitioners set out to answer, in ten steps.
Phase 1: Foundation and Scoping
Before a single policy is written or process updated, three foundational decisions need to get made correctly. Get them wrong, and everything built on top will need to be rebuilt.
Step 1: Determine applicability, scope, and governance
The first question most organizations ask is “what do we need to do?” But the more important question is “who are we under this Act?”
Niti Paul pointed out a distinction that trips up organizations across sectors: the difference between data protection and data privacy. An organization can have robust ISO certifications and strong security controls and still be out of step with DPDP’s requirements. Encrypting data and archiving it properly is data protection. Fulfilling data subject rights, reporting personal data breaches within required timelines, and embedding privacy into business processes, that’s data privacy. These aren’t the same thing.
Scoping, in practice, means standing up a steering committee that includes function leaders from HR, IT, procurement, and legal (not just the privacy office) and mapping where personal data lives across the full business lifecycle. Privacy by design belongs at the conceptualization stage, not as a retrofit.
On the question of significant data fiduciary (SDF) status: if your organization processes high volumes of personal data or handles sensitive categories, the consensus is to start preparing now rather than waiting for formal notification. Begin your data protection impact assessments, appoint a DPO, and build an auditable trail. The cost of being unprepared when the notification arrives is far higher than the cost of early action.
“DPDP readiness is really a business continuity issue dressed up as a compliance project.”
Kedar Bhasme, Privacy Principal, TrustArc
When scope is wrong, the consequences aren’t primarily about fines. They’re about rebuilding under pressure, receiving a rights request you can’t respond to properly, or discovering mid-breach that you can’t report cleanly.
Step 2: Data discovery and mapping
Every organization agrees that data mapping is foundational. Most organizations get it wrong in the same way: they treat it as a documentation exercise rather than a decision-making exercise.
Sanyogeeta Gaekwad sees organizations regularly invest months in automated discovery tools that tell them how much data they hold, without ever answering the operative question: what do I need to do with it?
The better approach is purpose-first, not systems-first. Rather than scanning 1,400 applications for PII, start by identifying the 50 to 60 genuine purposes for which you collect data; recruitment, payroll, KYC, marketing, grievance handling. Once those purposes are mapped, the systems attach themselves. And you can make the 10 to 15 decisions your compliance program actually requires.
The goal isn’t a perfect data map. It’s a map that’s accurate enough to make decisions today, while being honest about what’s still unknown. A 70% accurate inventory built over 8 weeks is more valuable than an 18-month mapping project that never produces a decision. Shortcuts taken at this stage, however, are a consistent source of findings in assessments months later.
For organizations with limited time, the minimum viable inventory is this: know your crown jewel applications, know the purpose for which each one collects data, and start there.
Step 3: Gap assessment and prioritization
The most common mistake Kedar sees organizations make after receiving a gap report: launching 40 workstreams to address 40 findings simultaneously, with the result that none of them get fixed properly.
A gap assessment is a mirror, not a scorecard. Its job is to show where your program is likely to fail while you still have time to fix it. The real skill is triage. For each finding, ask two questions: how long will it take to fix, and what happens if you don’t? The issues that take the longest to address and carry the most risk (consent withdrawal mechanisms, data principal rights workflows, governance structures) get immediate attention. Quick fixes and lower-risk gaps can wait their turn.
Finding a serious gap in month one is good news. Finding it in month 16 is a crisis.
Phase 2: Core Operationalization
This is where privacy stops being a framework and becomes an operational program. It’s also where well-designed programs quietly fall apart.
Step 4: Consent management
Consent under DPDP is a five-stage lifecycle: notice, obtaining consent, recording consent, honoring consent, and withdrawal.
Sanyogeeta breaks it down this way: collecting consent is a UX problem. Withdrawal is an architecture problem. Organizations tend to solve the first and underestimate the second.
Consent under the Act must be free, unambiguous, and based on a clear affirmative action. It cannot be bundled, and critically, it must be as easy to withdraw as it was to give. If it took one click to say yes and it takes an email, a phone call, and three working days to say no, that’s not compliant consent.
The more challenging gap is downstream propagation. An e-commerce site that correctly captures and honors consent within its CRM may still be sharing data with third-party telecalling vendors. When a user withdraws consent, is that withdrawal cascading to every data processor that received the data? If not, the consent architecture is incomplete regardless of what the UI does.
Kedar raised two additional challenges that organizations with AI roadmaps need to think through now. First, children’s data: verifiable parental consent remains an unsolved problem. How do you verify that the person clicking “I’m a parent” actually is one, without creating a larger privacy problem in the process? Any vendor claiming to have solved this perfectly deserves skepticism. Second, purpose limitation in AI: data collected to deliver a service may not be reused to train a model. Models don’t care about the purpose for which data was collected. DPDP is built around purpose limitation. Most organizations discover this collision after they’ve trained the model, not before.
Step 5: Data principal rights
Publishing a privacy mailbox is not a data principal rights program. It’s a starting point.
Data principal rights under DPDP are statutory. They carry penalties. They have timelines. And an unmanned mailbox is a liability.
Niti Paul outlined what operationalizing rights actually requires: continuous monitoring of the rights mailbox, internal guidelines for response timelines (many organizations default to the GDPR’s 30-day framework while awaiting DPDP-specific guidance), and cross-functional coordination so that, for instance, a data erasure request from a former candidate triggers the right retention review across the right teams.
Two things are worth keeping in mind. First, rights are not absolute. A request to erase an employee’s data may not be fulfillable if other legal obligations require retention, and that needs to be communicated to the data principal, not just documented internally. Second, as awareness of the Act grows, organizations should expect a significant increase in access and erasure requests. The time to build the process is now, not when the first wave arrives.
Steps 6 and 7: Retention and incident response
On retention: data kept indefinitely because no one ever set a deletion schedule is one of the three findings Kedar sees in almost every assessment. The fix requires a retention schedule, a retention owner, and a mechanism that actually runs.
On breach management: DPDP introduces a 72-hour notification requirement to the Data Protection Board for personal data breaches, not just security incidents. These are not the same category. When a breach occurs, the DPO must be notified fast enough to meet the reporting obligation, and affected data principals must receive a clear, structured report on what happened, how it was caused, and what steps the organization took.
Organizations that handle breaches well, in Kedar’s observation, are not necessarily the ones with the most sophisticated security tools. They are the ones that prepared before a breach happened; running tabletop exercises, testing playbooks, and bringing legal, privacy, security, communications, and business leadership together before a real incident puts everyone under pressure. A breach response plan is proven by whether people know exactly what to do when the pressure is on.
Phase 3: Governance, Technology, and Maturity
Building the program is one challenge. Keeping it alive two years from now, after the original implementation team has moved on is another.
Step 8: Third-party and vendor governance
Under DPDPA, accountability does not travel with data the way it does under GDPR. The data fiduciary retains accountability for the processing done by data processors. You can outsource the processing. You cannot outsource the responsibility.
The practical implication: a signed DPA is the beginning of vendor due diligence, not the end. It tells you what a vendor has agreed to. It does not tell you what they’re actually doing.
Sanyogeeta’s diagnostic questions for vendors go well beyond contract language. Can the vendor demonstrate its ability to delete a single data principal’s record on request? Does the deletion happen in near-real-time or is it a manual process with a five-day turnaround? How does the vendor handle sub-processors? How will it notify you within the 72-hour breach window if the breach originates on their side?
These are the contractual gaps most DPAs currently miss. Governance of third parties needs to be active, not just documented.
Step 9: Governance, accountability, and evidence
Being compliant and being audit-ready are not the same thing.
Compliance means implementing the controls. Audit readiness means being able to produce evidence of those controls today without spending three working days searching through emails and shared drives.
Niti Paul’s framing: privacy governance is inherently risk-based. The DPO’s role is not to say yes or no to a given processing activity. It’s to analyze the risk attached to that activity, document the reasoning, and give the business the information it needs to make a decision. Every such decision should be documented, including the purpose of processing, the legal basis, and the recommendations given.
The operational metrics Kedar uses to assess whether a program is actually working: what percentage of data principal rights requests were completed on time? How many new systems went through a privacy-by-design review before launch? How quickly can the organization move from identifying a breach to making the decisions required for notification? These numbers tell you whether the program is becoming more resilient or quietly starting to drift.
Step 10: Continuous monitoring and privacy culture
Policies sitting in a shared drive do not build a privacy culture. Neither does annual training completion.
Sanyogeeta’s concept of “humanizing privacy” gets at the core challenge: the accounts payable clerk who has never read your privacy policy, and probably never will, is still handling personal data every day. The gap between a privacy program on paper and one that people actually live by is a human problem, not a documentation problem.
What separates organizations that sustain their programs from those that drift: distributed ownership. When privacy compliance is owned only by the privacy office, it depends entirely on that team’s capacity and continuity. When privacy stewards and champions are embedded in HR, finance, IT, and other functions with designated responsibilities, training, and accountability, the program continues even when personnel change.
Communication matters too. FAQs and do’s and don’ts need to be written for the last person in the organization, not for the DPO. Bite-sized videos, posters, and plain-language guidance reach employees that policy libraries never will. An unaware employee is statistically more likely to cause a personal data breach than a malicious one.
The GDPR question
Before closing, the panel addressed a common assumption: that organizations with mature GDPR programs can simply layer DPDP on top.
The GDPR foundation is genuinely useful. But the DPDP Act is not a straight lift-and-shift. Several features have no direct GDPR equivalent:
- Consent withdrawal must be as easy as consent was given; a requirement more explicit than GDPR’s equivalent.
- Consent managers are a new concept introduced specifically by the Indian framework.
- Right to nominate allows data principals to designate someone to exercise rights on their behalf, unprecedented in other jurisdictions.
- Penalties on data principals for excessive or vexatious rights requests also appear nowhere else in global privacy law.
- No minimum threshold for notifying affected individuals of a personal data breach.
- Cross-border data transfer uses a different framework from GDPR’s adequacy-based approach.
GDPR compliance gets you most of the way there, but DPDP still requires deliberate, conscious adaptation, not the assumption that existing controls automatically transfer.
Key takeaways
The law is the starting point. Operationalizing it is where the real work happens, and where the trust is built.
Start with your data. If you don’t know what personal data you hold, where it lives, and how it moves, every decision that follows is built on assumptions.
Build a program that works in the real world. Consent must be more than a checkbox. Rights must be more than an email address. Governance must be more than a policy on a shared drive.
Don’t treat go-live as the finish line. It’s the beginning. Privacy is an ongoing operational capability that has to evolve as your business, your technology, and your regulatory obligations evolve. When you build that mindset into your organization, compliance becomes a byproduct of good practice.
Ready to move from gap report to a working program?
Talk to a Privacy Expert
