Readiness assessment

Guide · Featured · Start here

DPDP 2027 Compliance Roadmap: What Organisations Must Do

A practical, source-led guide to building an operationally ready programme for the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025.

For boards and executive teams, Data Protection Officers, legal and privacy, CISOs, CTOs, product, data, HR, procurement and internal audit. Last reviewed: 10 August 2026.

This is an implementation guide, not legal advice. Validate the applicable commencement notification, Government directions, Data Protection Board guidance, sectoral obligations and your factual use case with counsel. The Rules were notified in November 2025 with phased commencement. Use May 2027 as the broad operational-readiness target, but do not wait until then to build and test controls.

At a glance

A credible DPDP programme for 2027 produces five things: a complete inventory of personal data and its flows; valid consent or documented legitimate-use grounds with purpose-specific notices; tested workflows for rights, grievance, withdrawal, retention and breach response; security and vendor controls across the whole processing chain; and inspectable evidence. Accountability sits with the Data Fiduciary, the entity that decides the purpose and means of processing, even when a processor does the work.

Executive summary

DPDP is not a policy-update project. It is an operating-model programme for every organisation that processes digital personal data in India, or processes such data outside India in connection with offering goods or services to people in India. Its practical question is simple: can you explain, control, secure, correct, erase and evidence every important use of personal data?

A credible 2027 programme produces five outcomes.

Complete data inventory

A full map of digital personal data, purposes, systems, recipients, processors, transfers and retention.

Valid grounds and notices

Purpose-specific notices and working consent operations, or a documented legitimate-use analysis where the Act permits it.

Tested workflows

Working processes for rights, grievance redressal, withdrawal, retention and erasure, and breach response.

Controls across the chain

Security and vendor controls that hold across the full processing chain, not only inside your own perimeter.

Inspectable evidence

Records that executives, auditors, customers and the Data Protection Board can inspect on demand.

The core legal responsibility rests with the Data Fiduciary: the person that decides the purpose and means of processing. A Data Processor may carry out processing, but that does not remove the Data Fiduciary's accountability for compliance.

1. Start with scope, roles and accountability

What the Act covers. Sections 2 and 3 define the terms and application. The Act covers digital personal data processed within India where it is collected digitally, or collected non-digitally and then digitised. It also reaches certain processing outside India when connected with offering goods or services to Data Principals in India. It does not apply to personal data made publicly available by the Data Principal, or by another person under a legal obligation to make it public, nor to data processed by an individual for purely personal or domestic purposes.

What to do

  • Determine which legal entities, products, websites, apps, operations and subsidiaries are in scope.
  • Identify whether you are the Data Fiduciary, a Data Processor, or both, for each data flow. A SaaS provider can be a processor for enterprise-customer data and a fiduciary for its own marketing, support and employee data.
  • Name an executive sponsor and a programme lead, and build a steering group across Legal and Privacy, Security, Engineering, Product, Data, Procurement, HR, Marketing, Customer Support and Internal Audit.
  • Keep a decision log recording applicability calls, role allocation, purpose and basis decisions, exemptions, retention exceptions, vendor issues and residual risk accepted by leadership.

2. Build the personal-data inventory before changing notices

The duties in Sections 4 to 8 cannot be met reliably if you do not know what you process, why, where it goes and when it must stop. A website privacy policy is not a data inventory.

Create a processing inventory for every meaningful data flow: customer, prospect, employee, applicant, contractor, supplier-contact, user-generated, support, analytics, telemetry and incident data. For each activity, record the Data Principal group and source; the personal-data categories and business context; the purpose and process owner; the consent or specific legitimate-use basis; the collection channel and notice version; the systems, repositories, logs, warehouses and backups; internal recipients, processors and sub-processors; cross-border destinations; the retention event, duration, deletion method and legal-hold exceptions; and the security classification and key controls.

Map unstructured repositories too: shared drives, chat, email, call recordings, support tickets, documents, code repositories and AI tools. Reconcile the result against application inventories, cloud accounts, procurement and vendor lists, and data-discovery scans.

Control checklist

  • A processing inventory exists and has accountable owners.
  • It covers production, test, support, analytics, logs, backups and shadow or SaaS tools.
  • Each activity has a documented purpose and a permitted ground.
  • It is reviewed on a defined cadence and whenever products, vendors or architecture change.

3. Establish a permitted ground: consent or legitimate use

Under Section 4, personal data may be processed only for a lawful purpose and only with the Data Principal's consent or for certain legitimate uses. Section 5 requires notice, Section 6 sets the standard for consent, and Section 7 lists the specific legitimate uses.

Generate this notice now

Turn Sections 5 and 6 into a plain-language consent notice you can copy or download, then adapt it to your processing.

Open the consent generator

For a full operating model, see the DPDP Consent Management guide, and for the detailed legal test see the Valid Consent Under Section 6 guide.

Do not import a broad GDPR-style legitimate-interests concept. DPDP instead provides a defined list of legitimate uses, such as voluntary provision of data for a specified purpose, State functions, compliance with law, court or tribunal orders, medical emergencies, disasters, public-health and safety situations, employment-related purposes, and safeguarding employers from loss or liability. Each use needs documented facts and a narrow purpose.

Notice is the first operational control. Before seeking consent, provide a clear, standalone notice. Under the Rules, notices must be comprehensible and itemised. They should state the personal data and purpose, how consent may be withdrawn, the grievance-redressal route, and how to complain to the Board, in English or a language listed in the Eighth Schedule that the Data Principal can access. Avoid a single all-purpose policy; design notices for actual journeys such as signup, employee onboarding, app permissions, lead forms, loyalty programmes, support and partner channels.

Consent is a system, not a checkbox. It must be free, specific, informed, unconditional, unambiguous and signified by clear affirmative action, and it must be as easy to withdraw as to give. Build a consent ledger that stores the notice version, purpose, channel, timestamp, identity reference, affirmative action and withdrawal status, and connect it to CRM, marketing, analytics, product databases, support platforms and processors so that withdrawal changes downstream behaviour.

Control checklist

  • Every use has a lawful purpose and a documented consent or legitimate-use basis.
  • Notices are purpose- and channel-specific, not a generic privacy policy.
  • No pre-ticked boxes, bundled non-essential purposes, dark patterns or consent-by-silence.
  • Withdrawal is accessible and triggers downstream suppression, deletion or other action.
  • Legacy data has been assessed; where needed, re-notice or re-consent campaigns are planned.

4. Meet the Data Fiduciary's general obligations

Section 8 is the operational centre of the Act. It requires a Data Fiduciary to ensure completeness, accuracy and consistency where data is likely to be used for a decision affecting a Data Principal or disclosed to another fiduciary; to implement reasonable security safeguards; to notify breaches; to erase data when consent is withdrawn or the purpose is no longer served, unless retention is required by law; to publish business contact information; and to run effective grievance redressal. It also makes the fiduciary accountable for processing carried out by a processor on its behalf.

Convert it into operating controls

  • Define data-quality controls for decisioning, eligibility, profiles, employee processes, fraud systems and material disclosures.
  • Apply reasonable security safeguards to data under your control and to processor-operated processing, through due diligence, contracts and monitoring.
  • Publish a privacy contact point and a grievance path.
  • Build a data-lifecycle schedule and automate deletion where feasible.
  • Place processor requirements in enforceable contracts, not just a generic vendor questionnaire.

5. Build rights, grievance and nomination workflows

Sections 11 to 15 grant Data Principals the right to a summary of their personal data and processing, the identities of fiduciaries and processors with whom data was shared, correction, completion, updating and erasure, grievance redressal, and the right to nominate another person to exercise rights in case of death or incapacity. Data Principals also have duties, including not impersonating another person or suppressing material information. The Rules require Data Fiduciaries to respond to rights requests within 90 days. This is a service-management and data-architecture challenge, not only a legal one.

Minimum workflow

  • Receive and categorise the request, then verify identity proportionately.
  • Locate data across systems and processors.
  • Assess legal retention, litigation-hold, security and third-party constraints.
  • Correct, update, provide information, erase or explain the outcome.
  • Propagate changes to processors and recipients where required.
  • Respond within the applicable period and retain auditable closure evidence.

6. Protect children and persons with disabilities

A child is an individual under 18. Before processing a child's personal data, a Data Fiduciary must obtain verifiable consent of the parent or lawful guardian, subject to notified exemptions, and must not undertake tracking, behavioural monitoring, or targeted advertising directed at children unless a notified exemption applies. Related guardian-verification requirements apply for certain persons with disabilities. This reaches well beyond edtech and gaming: consumer apps, retail, social products, healthcare, family accounts, advertising, workplace benefits and device ecosystems can all encounter children's data.

What to do

  • Determine whether children can access or use each product or journey.
  • Implement age, guardian and consent controls where required.
  • Audit ad-tech, analytics SDKs, tracking pixels, profiling and recommendation systems.
  • Keep evidence of exemptions relied upon and reviews performed.

7. Secure data, retain required logs and prepare for breaches

The Act requires reasonable security safeguards to prevent personal-data breaches. The Rules describe measures including encryption, obfuscation, masking or virtual tokens; access controls; logging and monitoring; backups; and a minimum one-year retention for certain logs, traffic data and processing-related information. Controls must be risk based and appropriate to your systems and data.

A personal-data breach includes unauthorised processing, accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access that compromises confidentiality, integrity or availability. Affected Data Principals must be informed without delay, and the detailed intimation to the Board is due within 72 hours of becoming aware, unless the Board permits otherwise.

Control checklist

  • Encryption, identity and access management, privileged access, secure configuration, vulnerability management, monitoring and backups are implemented and tested.
  • A breach decision tree, incident roles and approved notification templates exist.
  • Processor incident SLAs enable timely assessment and reporting.
  • Two realistic tabletops have been run, including a vendor-originated incident.
  • DPDP breach reporting is coordinated with CERT-In, sectoral regulator, contractual and insurance obligations.

8. Control retention, erasure, processors and transfers

Data must be erased when consent is withdrawn or the specified purpose is no longer being served, unless retention is necessary for compliance with law. The Rules add inactivity-based erasure requirements for certain classes in the Third Schedule, with an advance notice of at least 48 hours. Reconcile this with statutory recordkeeping, fraud, tax, employment, clinical, safety, litigation-hold and security-log requirements.

Processors. The fiduciary remains accountable for processor activity. Maintain a processor and sub-processor register and require written instructions, confidentiality, security, sub-processing controls, prompt breach escalation, rights support, retention and deletion, cooperation and audit, and end-of-contract data return or destruction.

Cross-border transfer (Section 16). Transfers are permitted except to countries or territories restricted by the Central Government, or subject to future Government restrictions for specified data. Maintain a transfer register and monitor notifications. Do not assume that foreign-hosting arrangements are automatically acceptable indefinitely.

9. Assess Significant Data Fiduciary exposure

The Central Government may notify an organisation or class as a Significant Data Fiduciary, considering the volume and sensitivity of personal data, risk to rights, and potential effects on electoral democracy, the security of the State and public order. An SDF has additional duties: appoint a DPO based in India who reports to the board or governing body, appoint an independent data auditor, run periodic DPIAs and audits, and perform prescribed due diligence for algorithmic software. Large consumer platforms, high-volume processors, organisations using consequential automated decisioning, and entities in sensitive ecosystems should build SDF-ready foundations now.

10. Know exemptions, enforcement and penalty exposure

Section 17 contains exemptions for specified processing, including some State, legal, judicial, research, archival and statistical activities. Exemptions are purpose- and condition-specific: record the exact legal basis and do not treat them as a blanket privacy waiver.

The Data Protection Board of India can inquire into breaches, non-compliance and complaints, direct urgent remedial or mitigation measures, impose financial penalties and accept voluntary undertakings. Appeals go to the Appellate Tribunal (TDSAT). Under the Schedule, failure to maintain reasonable security safeguards can attract a penalty up to Rs 250 crore; breach-notification failures and certain children's-data contraventions can each attract up to Rs 200 crore; and other Data Fiduciary contraventions can attract up to Rs 50 crore.

11. A practical 2027 implementation plan

First 30 days: establish facts and owners

  • Confirm applicability, entity roles and high-risk products.
  • Stand up the steering group, RACI, risk register and evidence repository.
  • Launch data-flow mapping and processor discovery.
  • Freeze or review high-risk new data uses until their purpose, notice and safeguards are clear.

Days 31 to 90: design and remediate priority controls

  • Fix notices, consent journeys and withdrawal routing.
  • Publish contact and grievance routes and build the rights-request workflow.
  • Update processor contracts and critical-vendor incident escalation.
  • Implement the retention schedule, deletion design and breach playbook.
  • Assess children's data and Significant Data Fiduciary indicators.

Days 91 to 180: integrate and test

  • Connect consent, rights and deletion workflows to downstream systems and processors.
  • Run data-quality, access-control, backup and recovery, and deletion tests.
  • Conduct breach tabletop exercises, including a vendor-originated incident.
  • Develop executive metrics and complete an internal assurance review.

Ongoing: monitor and prove

  • Review the processing inventory and vendors on a quarterly cadence.
  • Monitor Government and Board notifications and sectoral rules.
  • Measure requests, consent withdrawals, deletion performance, vendor gaps, incidents and control coverage.
  • Refresh training, run periodic tests and report residual risk to the Board.

Minimum audit-ready evidence pack

  • DPDP applicability assessment, entity and role map, and governance records.
  • Processing inventory and data-flow diagrams.
  • Purpose, consent and legitimate-use register plus notice versions.
  • Consent and withdrawal evidence.
  • Rights and grievance procedure, request register and test results.
  • Retention schedule, exception register and deletion evidence.
  • Security policies, access reviews, monitoring and logging evidence, and backup-recovery tests.
  • Incident plan, notification templates, tabletop reports and breach register.
  • Processor register, due diligence, contracts and offboarding evidence.
  • Cross-border transfer register.
  • Children's-data assessment and Significant Data Fiduciary assessment.
  • DPIAs and audits where applicable, training records, metrics and executive reporting.

Official source anchors

Review discipline. This guide carries a Last reviewed date. It is updated after any Gazette notification, MeitY or Board direction, court decision or sectoral rule that changes application, timelines, transfers, exemptions or enforcement.

Turn this roadmap into action

Start by checking where you stand, then get matched with an implementation partner who can own the delivery.