A DPDP gap assessment identifies what is missing. Implementation changes how your organisation collects, processes, shares, retains, secures and governs personal data across systems, teams and third parties. DPDPActIndia helps you understand and scope those implementation requirements and identify appropriate specialist support where required.
DPDP implementation is the operational work of turning the Digital Personal Data Protection Act, 2023 and its Rules into controls that actually run inside an organisation. A gap assessment identifies what is missing. Implementation changes what happens next: how personal data is discovered and mapped, how notice and consent are captured and honoured, how access, correction and erasure requests are fulfilled, how long data is kept and how it is deleted, how processors and vendors are governed, and how each control produces evidence.
It spans data, applications, customer and employee journeys, processors, security and governance, not just policies. The test is not whether a document exists, but whether the organisation can perform the control repeatedly and prove that it operated. DPDPActIndia helps organisations understand and scope that work and connect with suitable specialist delivery where required.
Most organisations reach a familiar point: the legal review is done, the gap assessment is written, privacy policies are drafted, initial training is delivered. On paper, the programme looks underway. Then the real work begins, and it does not live in a document.
Necessary. Not sufficient.
Implementation is not a single project. It is nine connected workstreams, each with its own controls, owners and evidence. Most organisations need several at once.
Discovery, inventory, mapping, processing activities, classification.
Purposes, notices, consent capture, withdrawal, evidence.
Access, correction, erasure, grievance, nomination.
Minimisation, accuracy, retention, deletion.
Processors, vendors, contracts, subprocessors, offboarding.
Safeguards, logging, incidents, breach response.
Discovery, CMP, rights automation, deletion, workflows, APIs.
Ownership, DPO/privacy, policies, RACI, testing.
Logs, registers, approvals, dashboards, audit trails.
Most implementation projects start from one dominant problem. Find the statement that sounds like your organisation.
We do not reliably know where personal data exists.
Systems, applications, databases, processing activities, flows, processors.
Our consent and notices are fragmented across channels.
Purposes, notices, capture, evidence, withdrawal, propagation.
Consent management guide →We cannot reliably fulfil access, correction or erasure requests.
Request intake, identity checks, fulfilment, timelines, records.
We do not know what to retain, what to delete or how to operationalise deletion.
Retention rules, triggers, deletion across systems, proof of erasure.
We have too many vendors and limited visibility into how they handle personal data.
Register, contracts, subprocessors, security, offboarding.
Our privacy and cybersecurity incident processes are disconnected.
Safeguards, logging, detection, breach workflow, notification.
We know manual processes will not scale.
Consent management, discovery, rights automation, deletion, workflows.
Many organisations have several of these at once. The assessment below helps you see which workstream is dominant.
Scope it →We completed an assessment and now need to implement the remediation roadmap across data, consent, rights, retention, vendors, security and evidence.
A gap report is the starting line, not the finish. Implementation turns its findings into changed processes, systems, contracts and evidence, in a defined sequence.
Seven stages take an organisation from what exists today to controls that operate and can be proven. DPDPActIndia helps you scope the stages that apply and identify who should deliver them.
Systems, applications, data stores, processors, vendors, customer journeys, existing controls.
What exists?
Personal data, processing, purposes, flows, recipients, retention, ownership.
Why is it processed and where does it go?
Notices, consent, rights workflows, retention rules, processor controls, incident processes, governance, evidence.
What should happen?
Applications, processes, SOPs, contracts, permissions, access, vendor arrangements, responsibilities.
What changes operationally?
Websites, apps, CRM, HRIS, ERP, ticketing, CMP, discovery tools, vendor APIs, internal workflows.
How will technology enforce it?
Registers, logs, approvals, deletion records, request evidence, vendor reviews, dashboards.
Can it be demonstrated?
Testing, monitoring, reassessment, remediation, regulatory updates, governance review.
Will it continue to work?
Implementation produces working artefacts your teams operate from. These are the kinds of outputs a real programme creates. Each is illustrative, not a client deliverable.
| Gap assessment | DPDP implementation | Operational evidence |
|---|---|---|
| Identifies missing consent controls | Designs and changes the consent process | Consent logs |
| Identifies unmapped data | Maps systems and flows | Processing inventory |
| Identifies vendor risk | Remediates vendor controls | Vendor register |
| Identifies weak retention | Builds retention and deletion logic | Deletion records |
| Identifies a rights gap | Creates the rights workflow | Request register |
| Finds incident gaps | Implements the response workflow | Incident evidence |
| Produces a roadmap | Executes remediation | Control evidence |
The Act is horizontal. Implementation is not. The same obligation lands differently depending on the systems, data and sector regulators involved.
KYC, financial data, digital lending, apps, LSPs, bureau and Account Aggregator, payments, overlapping RBI regulation.
DPDP + RBI Digital Lending ImplementationPatient records, HIS/EMR, diagnostics, hospitals, TPAs, insurers, access and retention of sensitive records.
Healthcare DPDP context →Employee data, global systems, parent-company relationships, cross-border operations, vendors, HR technology.
DPDP Implementation for GCCs →Policyholders, agents, underwriting, medical information, TPAs, claims processing.
InsurTech context →Customer data, product telemetry, subprocessors, cloud, analytics, global systems.
SaaS DPDP context →Consumer journeys, personalisation, marketing, payments, logistics, vendors.
E-commerce DPDP context →Sector-specific implementation depth is published progressively. Fintech is live now; others link to industry context while implementation guides are built.
Two organisations with the same obligations can need very different programmes. These bands are illustrative, not an official classification, and carry no pricing.
Typically fewer systems, limited processors, fewer channels, lower automation need.
Potential approachSeveral systems, multiple processors, cross-functional teams, greater data volume.
Potential approachLarge application estate, many processors, multiple entities, complex integrations, high scale.
Potential approachNot necessarily. New technology should be considered where existing systems and processes cannot reliably support the required control at the relevant scale. Process comes first; technology enforces it.
Whatever tools an organisation uses, DPDP controls sit in the same place: a privacy control layer between the channels that collect data and the systems and processors that hold it, all producing evidence.
Real controls change applications, access, contracts and operations. That means implementation is shared across functions, each owning a distinct part of the work.
Requirements, control design, coordination, evidence strategy.
Regulatory interpretation, contract remediation, retention and legal-hold requirements.
Safeguards, access, logging, incident and breach response.
Application changes, APIs, deletion workflows, permissions, system integrations.
Consent and notice in journeys, preference experiences, data minimisation by design.
Running the controls day to day, request handling, SOP adherence.
Processor onboarding, contract clauses, vendor offboarding.
Employee and customer data, consent for communications, retention of records.
Ownership, funding, prioritisation, accountability for the programme.
Responsible, Accountable, Consulted, Informed. Ownership differs by organisation; this shows the shape of a typical split, not a prescription.
| Workstream | Privacy | Legal | Security | Product | Engineering | Operations |
|---|---|---|---|---|---|---|
| Discovery | A | I | C | C | R | C |
| Consent | C | C | I | A | R | I |
| Rights | A | C | I | C | R | R |
| Retention | A | C | I | I | R | C |
| Processors | C | A | C | I | I | R |
| Incidents | C | C | A | I | R | R |
| Testing | A | I | C | C | R | R |
Illustrative only. Actual ownership differs by organisation. R responsible, A accountable, C consulted, I informed.
Most organisations can locate themselves on a simple ladder from no visibility to continuous monitoring. Knowing the rung clarifies what implementation still has to do.
Limited visibility into systems, data and processors.
Gaps identified through a gap assessment.
Data, purposes, systems and processors documented.
Target controls defined.
Processes and systems remediated.
Control operation produces records.
Controls continuously reviewed and improved.
DPDPActIndia Implementation Maturity Model. An educational framework, not an official regulatory rating.
Most failures are not legal. They are operational: the control was described but never made real, or made real once and never maintained.
Policies are updated but operating teams behave exactly as before.
Consent is captured but downstream systems ignore it.
Beautiful data maps are built once and quietly go out of date.
Vendors are listed but contracts, access and security stay unchanged.
A retention schedule exists but nobody can actually delete the data.
Requests depend entirely on manual coordination and memory.
Software is purchased before the requirement is defined.
Engineering, product and security never participate, so nothing changes in systems.
The organisation later cannot prove a control ever operated.
Everything is done for launch, then nothing is monitored.
Some organisations can remediate a narrow gap internally. Others cross into a genuine programme. These signals usually mean external implementation support is worth considering.
| Signal | Lower complexity | Higher complexity |
|---|---|---|
| Systems | Fewer | Many |
| Processors / vendors | Fewer | Many |
| Journeys | Limited | Multiple / fragmented |
| Integrations | Low | Extensive |
| Remediation | Targeted | Cross-functional |
| Governance | Simple | Multi-entity / complex |
DPDPActIndia helps organisations understand and scope implementation requirements. Where specialist execution is required, relevant implementation capability may be introduced based on the organisation's industry, systems, regulatory environment and project scope. Different projects need different combinations of privacy, industry, security, engineering, technology, integration and legal expertise.
Tell us where your organisation stands and which implementation problems need solving. The goal is to determine whether the requirement is targeted remediation, privacy technology, processor and vendor remediation, industry implementation, or a broader DPDP transformation programme. Nothing here is a commitment.
Select all that apply.
Thank you. Based on what you shared, here is what typically happens next:
This is not a guarantee of engagement. Your responses are held in your browser on this device. If you would like to continue right away, you can explore the implementation partner pathway or check your readiness.
It is the operational work of turning the DPDP Act and Rules into controls that run: discovering and mapping data, operationalising notice and consent, building rights, retention and deletion, governing processors, securing data and producing evidence, across systems, teams and vendors.
A gap assessment identifies what is missing. Implementation changes what actually happens, so the control operates repeatedly and can be proven. One produces a report; the other changes systems, processes, contracts and evidence.
Findings are prioritised, target controls are designed, owners are assigned, and processes, systems and vendors are remediated, then tested, evidenced, operated and monitored.
Usually the highest-risk, highest-exposure gaps: knowing where personal data is, fixing notice and consent on live journeys, and being able to fulfil rights and delete data. The right order depends on your assessment findings.
Not necessarily. New technology is warranted where existing systems and processes cannot reliably support a control at your scale. Define the requirement first, then decide whether to configure existing tools or adopt new ones.
Consider one when consent must be captured, honoured and evidenced across multiple channels and systems, at a volume that manual processes cannot sustain, and when actions like withdrawal must propagate automatically.
Identifying systems and data stores, the personal data they hold, the purposes and lawful basis, data flows and recipients, retention and ownership, so the map can drive real controls rather than sit on a shelf.
Build a register, remediate contracts and security terms, track subprocessors, control access, and define offboarding and deletion, so that vendor handling of personal data is governed rather than assumed.
Define retention rules and triggers, then build the ability to actually delete across systems and processors, and record proof of erasure. A schedule with no deletion capability is a common failure.
A working path to receive, verify, fulfil and record access, correction, erasure, grievance and nomination requests within defined timelines, rather than ad hoc email coordination.
It cannot sit with Legal alone. Privacy or the DPO coordinates, but engineering, security, product, operations, procurement and leadership each own parts of the delivery.
It depends on scope. A focused remediation can be weeks; a broad programme across many systems, processors and integrations can run several months. There is no universal fixed timeline.
No. This is decision-support and implementation navigation, not a legal guarantee. Implementation helps operationalise and evidence applicable requirements, but compliance cannot responsibly be guaranteed by completing a project.
No. The model is partner-driven. DPDPActIndia helps you understand and scope the requirement and, where specialist execution is needed, introduces relevant implementation capability matched to your industry, systems and scope.
Use the implementation assessment above. It captures your status, needs, complexity, trigger and timeline so the opportunity can be routed appropriately.
Every legal statement on this page is anchored to enacted primary sources, not vendor interpretation.
The Digital Personal Data Protection Act, 2023 is the primary statute. Core obligations commence 13 May 2027.
Enacted Act, MeitY →The Digital Personal Data Protection Rules, notified 13 November 2025, operationalise notice, consent managers, security, breach reporting, retention and Board procedure.
Read our Rules overview →The Ministry of Electronics and Information Technology is the administering ministry and the source of official notifications and the Data Protection Board framework.
meity.gov.in →Sector-specific directions, for example from the RBI, SEBI or IRDAI, are covered on the relevant industry pages rather than repeated here.
DPDPActIndia is an independent information and implementation-navigation resource and is not a government website.
DPDPActIndia helps organisations understand and scope implementation requirements. Where specialist execution is required, relevant implementation capability may be introduced based on the organisation's industry, systems, regulatory environment and project scope. Implementation support may involve third-party specialist providers, and commercial relationships may apply.
We do not publish client counts, testimonials or partner badges we cannot evidence. Competence is shown through implementation architecture, artefacts and frameworks rather than unverifiable claims.
Get a structured read on your DPDP gaps across consent, rights, retention, security and governance before you scope implementation.
Check your DPDP readinessTell us your current status, systems and the workstreams that need implementing. We will read the scope and point you to appropriate delivery capability.
Assess your implementation needsThis page provides general implementation information and does not constitute legal advice. Actual DPDP obligations and implementation requirements depend on an organisation's role, processing activities, systems, contractual arrangements and other applicable laws or regulations.