DPDP compliance checklist: What to audit before November 2026

If you are responsible for compliance at an Indian enterprise or a SaaS company with Indian users, 13 November 2026 is the next hard date on your calendar. That is when Phase 2 of the Digital Personal Data Protection Act (DPDPA) goes live, opening the Consent Manager registration framework and activating the penalty structure that makes non-compliance a balance-sheet issue.

Phase 3 and full enforcement arrive on 13 May 2027. That is the date most legal teams have been planning toward.

But November 2026 is where the build-and-test window ends and the infrastructure window begins. If a Consent Manager is part of your compliance architecture, the framework to register one goes live on that date, and that is also the point at which the Data Protection Board of India has the operational scaffolding to begin active supervision.

This guide is written for the compliance practitioner who evaluates tools, builds internal cases for budget, and owns the audit readiness program. It covers what November 2026 actually requires, what the full checklist looks like before that date, how DPDPA differs from GDPR in the specific ways that matter for your gap assessment, and what the consent manager decision actually involves.

The three DPDPA phases: What November 2026 actually means

The November 2026 deadline is not the enforcement date. It is the infrastructure date. The Consent Manager framework becomes operational, giving enterprises that need to integrate with registered Consent Managers a live ecosystem to work with.

May 2027 is when the full penalty structure applies. But teams that arrive at May 2027 without completed gap assessments, consent architecture, and breach response processes will be remediating under deadline pressure.

DPDPA vs GDPR: The differences that change your gap assessment

If your organization has already implemented GDPR compliance, you are approximately 60 to 70 percent of the way to DPDPA compliance. The remaining 30 to 40 percent contains the obligations that differ most from GDPR and that require the most significant changes to existing processes. This section covers only the differences that change what you need to audit.

The DPDPA penalty schedule: What makes November 2026 matter financially

The DPDPA penalty structure is materially different from GDPR in one important way: it is fixed per instance, not revenue-based. GDPR fines cap at four percent of global annual turnover. DPDPA penalties are fixed amounts per violation category, imposed by the DPBI based on the nature, gravity, duration, and impact of the violation.

Penalties stack. A single breach event can trigger the security safeguard penalty (INR 250 crore) and the notification penalty (INR 200 crore) simultaneously. A startup processing student data faces the same INR 200 crore maximum for children's data failures as a large enterprise. There is no materiality threshold: a breach involving one record triggers the same notification obligation as one involving a million records.

The DPDPA compliance checklist: What to audit before November 2026

The checklist below covers the eight domains that should be audited before November 13, 2026. The November deadline is the preparation checkpoint; the May 2027 enforcement date is when everything below must be fully operational.

1. Data inventory and mapping

• Identify all personal data your organization collects, processes, stores, or shares
• Document the purpose of processing for each data category
• Map data flows: where data enters the system, where it is stored, how it is processed, where it exits to third parties
• Flag high-risk processing activities: children's data, health data, financial data, large-scale processing
• Build or update your Record of Processing Activities (ROPA) with purpose, legal basis, retention period, and processor details

The DPDPA is consent-centric. If your ROPA still lists 'legitimate interest' as the legal basis for analytics, marketing, or product improvement, those entries need to be reclassified under consent or restructured. There is no legitimate interest basis under DPDPA.

2. Consent flows and notice compliance

• Audit all consent collection points: web forms, mobile app onboarding flows, call centre scripts, API integrations
• Verify consent is free, specific, informed, unconditional, and given through clear affirmative action (no pre-ticked boxes, no bundled consent)
• Verify that privacy notices state what data is collected, the purpose, and how data principals can exercise rights and withdraw consent
• Verify that notices are available in English plus any of the 22 Scheduled languages of the Indian Constitution, deliverable in the language chosen by the data principal
• Verify that consent withdrawal is as easy as giving consent, with no penalty or friction for withdrawal
• Verify that new purposes require new, separate consent; bundled consent for multiple purposes is invalid
• Build or verify a consent record: what notice was shown, when it was accepted, for what purpose, and every subsequent change (withdrawal, modification, renewal)

3. Children's data controls

• Identify all data flows and processing activities that involve users under 18
• Implement age verification processes to identify users under 18 with reasonable technical effort
• Implement verifiable parental consent processes for users under 18 before collecting or processing their personal data
• Prohibit targeted advertising directed at users under 18
• Prohibit profiling of users under 18 that could cause harm
• Verify that no tracking of children's activity is performed beyond what is necessary for the declared processing purpose

The INR 200 crore penalty for children's data failures applies to any organization, regardless of size. A startup with 1,000 student users faces the same maximum exposure as a platform with 10 million. Age verification must be implemented before you process, not after you have already collected the data.

4. Security safeguards

Rule 6 of the DPDP Rules 2025 specifies a minimum set of seven technical and organisational security controls. Audit each one:

• Encryption of personal data in storage (at rest)
• Encryption of personal data in transit
• Access controls restricting access to personal data to authorised personnel only, with documented role-based access policies
• Data masking or anonymisation where appropriate to the processing context
• Monitoring: logs of access and processing activities covering all systems that store or process personal data
• Log retention: access and activity logs retained for at least one year
• Incident response: documented processes for identifying, containing, assessing, and reporting personal data breaches

These seven controls align closely with the SOC 2 CC6 and CC7 criteria and ISO 27001 Annex A technical controls. If your organization has a current SOC 2 or ISO 27001 program, map your existing controls against Rule 6 to identify gaps. See the security controls framework mapping guide for a cross-framework reference.

5. Breach detection and notification

• Build a breach detection capability: alerting on unauthorized access, configuration changes, and anomalous data access patterns
• Document a breach response playbook covering identification, containment, assessment, legal review, and notification
• Define the notification trigger: any breach of personal data, regardless of severity or number of records affected
• Define the notification timeline: initial notification to the DPBI without delay; notification to all affected data principals within 72 hours
• Build notification templates in plain language covering: nature of the breach, data exposed, protective measures data principals can take, and contact details for queries
• For BFSI organizations: verify that DPDPA breach notification timelines align with RBI's existing reporting requirements

Under GDPR, you may notify supervisory authorities without notifying individuals when risk is low. Under DPDPA, there is no risk threshold. Every personal data breach requires notification to all affected data principals within 72 hours. This is a process, staffing, and tooling change for teams that have built their breach response around GDPR assumptions.

See what auditors actually look for in breach evidence. 

6. Data principal rights processes

Data principals under DPDPA have the right to access, correction, erasure, and grievance redress. Each right requires a documented fulfillment process with a 30-day response timeline.

• Right to access: process for responding to requests for information about what personal data is held and the processing purposes
• Right to correction and update: process for correcting inaccurate or incomplete personal data within 30 days
• Right to erasure: process for deleting personal data when the processing purpose is fulfilled, consent is withdrawn, or the individual has not engaged within the retention period
• Right to grievance redress: documented grievance mechanism with a designated contact and 30-day response window
• Right to nominate: process allowing data principals to nominate another individual to exercise their rights in the event of death or incapacity
• Verify that service denial is not used as a consequence for exercising data principal rights

7. Vendor agreements and data processing agreements

• Audit all vendor contracts involving personal data processing and identify those missing DPDPA-compliant Data Processing Agreement (DPA) provisions
• Verify that each DPA requires the processor to implement the same security safeguards required of the Data Fiduciary under Rule 6
• Verify that each DPA specifies the processor's obligation to notify the Data Fiduciary of a breach without unreasonable delay
• Verify that each DPA requires the processor to return or delete all personal data at the end of the contractual engagement
• Build a sub-processor inventory listing every fourth party that your processors share data with
• Prioritize remediation of vendor agreements by data volume and sensitivity

8. Consent Manager: The November 2026 decision

A Consent Manager under DPDPA is a specific regulated entity, not a software category. Under Rule 4, a Consent Manager must be:

• Incorporated in India
• Have a minimum net worth of INR 2 crore
• Register with the Data Protection Board
• Act in a fiduciary capacity on behalf of data principals, independently of Data Fiduciaries
• Provide a single interface for data principals to give, review, manage, and withdraw consent across fiduciaries
• Not sub-contract its obligations
• Ensure no conflict of interest between directors or key personnel and the Data Fiduciaries whose consent it manages

For most enterprises, the question is not whether to become a Consent Manager (that is a business model decision for specialized intermediaries) but whether to integrate with one. That decision turns on the complexity of your consent architecture and the volume of data principals you serve.

If your organization uses a consent management platform (CMP) today for GDPR, that platform is not automatically a DPDPA-registered Consent Manager. The two are different things. Your CMP handles your own consent flows. A registered Consent Manager is a third-party intermediary through which data principals manage consent across fiduciaries.

The November 2026 audit is the moment to decide: does my consent architecture require Consent Manager integration? That decision drives a procurement conversation, a budget request, and an integration project. All three take time. The November deadline gives you the framework. The May 2027 enforcement date requires the implementation.

Building the internal business case for DPDPA tooling

For compliance practitioners, the hardest part of DPDPA preparation is often not the technical audit. It is making the internal case for budget that was not allocated in the original compliance program. Most compliance budgets were scoped for SOC 2 and ISO 27001 tooling. DPDPA adds obligations that require additional line items: consent management infrastructure, multilingual notice delivery, and in some cases a registered Consent Manager integration.

The business case has three components.

The penalty exposure calculation. INR 250 crore for a security breach that leads to data exposure. INR 200 crore for a notification failure. INR 200 crore for a children's data failure. These are per-instance figures that stack. For a mid-market SaaS company with INR 50 crore annual revenue, a single combined breach and notification failure represents four times annual revenue in maximum exposure. That is a board-level number, not a compliance team number.

The commercial risk argument. Enterprise customers with Indian operations are beginning to add DPDPA compliance warranties to vendor contracts. Sales cycles for regulated-sector deals are starting to include DPDPA questionnaires alongside SOC 2 and ISO 27001 requests. Non-compliance is a vendor risk flag that procurement teams are increasingly flagging. The compliance program that enables DPDPA attestation becomes a sales enablement asset and a legal requirement simultaneously.

The efficiency argument. DPDPA's consent, breach notification, and data principal rights obligations require process infrastructure that, if built on automated evidence collection and continuous monitoring, reduces the ongoing operational burden. Teams that build this infrastructure during the pre-May 2027 window will manage DPDPA obligations in days per cycle. Teams that manage it manually will manage it in weeks.

How Scrut supports DPDPA compliance readiness

Scrut's GRC platform is built for the operational reality of multi-framework compliance programs. For organizations managing DPDPA alongside SOC 2, ISO 27001, or HIPAA, the control overlap is real: Rule 6 security safeguards map directly to SOC 2 CC6 and CC7, ISO 27001 Annex A physical and technical controls, and HIPAA security rule requirements. A single encryption and access control implementation satisfies all four when controls are mapped across frameworks from the start. See the security controls cross-framework mapping table for the specific control-to-requirement mapping.

For the DPDPA-specific obligations, Scrut supports data mapping, vendor agreement tracking, breach response workflow documentation, and evidence collection for data principal rights fulfillment. The evidence library built for DPDPA compliance is the same evidence library used for SOC 2 and ISO 27001 audits, accumulated continuously, available for assessment on demand.

See how Scrut helps compliance teams prepare for DPDPA, SOC 2, ISO 27001, and other frameworks from a single control library. Request a demo.