Skip to content
Same data, new law

DPDP Act 2023 vs IT Rules 2011 (SPDI) — What Changed

DPDP Act 2023 supersedes IT SPDI Rules 2011 for all personal data processing. Your 2011-era privacy policy, consent banners, and breach procedures need a systematic overhaul — not a cosmetic update.

Section 44 of DPDP explicitly overrides inconsistent IT Act provisions. The SPDI Rules are effectively displaced for personal data.

DPDP supersedesIT SPDI Rules
Fresh consentlikely required
₹200 Crmax penalty (DPDP)
Freemigration audit
Migrate from IT Rules 2011 to DPDPDPDP compliance for Indian startups
SPDI-to-DPDP gap analysisRe-consent flow designBreach notification template update

Side-by-side comparison — SPDI Rules 2011 vs DPDP Act 2023

The table below summarises the principal differences across the dimensions that matter most for compliance programs. Use this as the starting point for your migration gap analysis.

  • Scope: SPDI Rules applied only to body corporates handling SPDI in India; DPDP applies to any data fiduciary processing personal data of Indian data principals, including overseas entities
  • Consent: SPDI required written consent for collection of sensitive data; DPDP requires specific, informed, purpose-linked consent for all personal data processing
  • Sensitive data category: SPDI had an explicit list (financial, health, biometric, password, sexual orientation); DPDP removes the tiered category — all personal data is subject to the same framework, with children's data and SDF-processed data attracting additional obligations
  • Breach notification: SPDI Rules had no explicit breach notification requirement — notifications were driven by CERT-In directives; DPDP requires notification to the Data Protection Board (timeline in draft rules: without undue delay, interpreted as 72 hours)
  • Data principal rights: SPDI Rules gave limited rights — correction of inaccurate data and withdrawal of consent; DPDP adds rights to access information, correction and erasure, grievance redressal, and nomination
  • Enforcement body: SPDI Rules relied on IT Act civil courts and CERT-In for enforcement; DPDP creates the Data Protection Board as the dedicated enforcement authority
  • Penalty framework: SPDI Rules used IT Act Section 43A (civil compensation, uncapped, harm-based) and Section 72A (criminal, ₹5 lakh cap); DPDP uses administrative penalties up to ₹200 crore assessed by the Board without proof of individual harm
  • Applicability to processors: SPDI Rules had limited processor-specific obligations; DPDP Section 8 creates comprehensive fiduciary-processor contractual obligations including sub-processor governance

What survives from the IT Rules 2011 framework

Not everything from the 2011 compliance framework is displaced. Several elements remain relevant — either because they address scenarios DPDP does not cover, or because they represent evidentiary and operational documentation that the DPDP audit process will examine.

  • IT Act Section 43A civil liability: the right of affected individuals to claim compensation for negligent data handling under Section 43A of the IT Act survives alongside DPDP — both can apply to the same incident
  • CERT-In Directions 2022: the 6-hour cybersecurity incident reporting obligation (Form C to CERT-In) is an IT Act power that runs in parallel with DPDP's Board notification; both must be satisfied for the same breach
  • Non-personal data scenarios: SPDI Rules and IT Act provisions continue to govern some scenarios involving non-personal data or mixed datasets not yet regulated under DPDP
  • Existing security audit documentation: security assessments, IS audits, and ISMS documentation maintained under SPDI Rules translate into the Schedule I technical safeguards evidence base under DPDP — do not discard these records
  • Privacy notice history: records of when privacy notices were published, what they said, and who consented under the old framework are relevant for understanding the re-consent scope and the historical liability window

Migration checklist — from IT Rules 2011 to DPDP

The migration is not a one-time task — it is a phased program spanning consent architecture, notice rewrite, breach procedures, and data principal rights workflows. Prioritise by risk: highest-volume, highest-sensitivity processing activities first.

  • Phase 1 — Processing activity audit: document every personal data processing activity, its legal basis under DPDP, the data categories, retention periods, and processor relationships. This is the foundation for everything else.
  • Phase 2 — Consent re-architecture: design the new purpose-specific consent framework. Identify which existing processing activities relied on bundled SPDI consent. Build the new consent notice structure for each purpose.
  • Phase 3 — Re-consent campaign: for existing data principals whose data is held under 2011-era consent that does not meet DPDP standards, plan and execute a re-consent flow. Document outcomes — those who do not re-consent should have their data erased or processing restricted.
  • Phase 4 — Privacy notice rewrite: update the public-facing privacy notice to meet DPDP Section 5 requirements — plain language, purpose-specific, with withdrawal instructions and data principal rights explained.
  • Phase 5 — Breach notification update: replace your SPDI-era breach process (CERT-In only) with a dual-track process: CERT-In (6 hours) + Data Protection Board (without undue delay / 72 hours). Update templates, runbooks, and escalation trees.
  • Phase 6 — Data principal rights workflow: build mechanisms for data principals to access their data summary, correct inaccuracies, request erasure, and nominate a representative — none of these existed in the SPDI framework.
  • Phase 7 — Processor contract review: audit all data processing agreements. DPDP Section 8 requirements are more specific than SPDI Rules — update DPAs to include purpose documentation, sub-processor governance, and audit rights.
  • Phase 8 — DPB submission readiness: prepare your Data Protection Board registration and compliance documentation as the Board's operational processes are announced.

What existing SPDI documentation translates and what does not

Migration is more efficient when you correctly identify which existing compliance assets can be updated vs which must be rebuilt from scratch. Incorrect reuse of SPDI-era documents as DPDP compliance evidence is a common audit risk.

  • TRANSLATES — Security audit reports: ISO 27001, SOC 2, and IT security audit reports from the SPDI era map directly onto Schedule I technical safeguards evidence under DPDP. Update the scope statement to reference DPDP obligations.
  • TRANSLATES — Data inventory and classification: if you built a data inventory under SPDI Rules to identify where SPDI was held, the same inventory is the starting point for your DPDP processing activity register — expand it to all personal data, not just the former SPDI categories.
  • TRANSLATES (PARTIALLY) — Processor contracts: DPAs that included data protection clauses under SPDI Rules need additional provisions (sub-processor governance, DPDP-specific breach notification timelines, data principal rights assistance) but the base contractual structure is reusable.
  • DOES NOT TRANSLATE — Bundled consent records: consent collected via a single T&C acceptance that covered all processing purposes does not satisfy DPDP's purpose-specific consent requirement. These must be rebuilt.
  • DOES NOT TRANSLATE — Privacy notice: SPDI privacy policies that referenced sensitive personal data categories, the Section 43A liability standard, and 2011-era rights disclosures require a complete rewrite — editing the existing document risks embedding legally incorrect framing.
  • DOES NOT TRANSLATE — Breach notification templates: SPDI-era templates designed for CERT-In reporting need a parallel stream added for the Data Protection Board, with different content requirements, different recipient, and different timeline.

Sector-specific migration notes — fintech and healthcare

Two sectors face the most complex migration given the intersection of DPDP with their pre-existing regulatory frameworks. Both sectors were already subject to sector-specific data obligations that now layer with DPDP.

  • Fintech — consent: bank and NBFC account opening processes relied on broad consent in account-opening forms. DPDP requires purpose-specific consent for each processing activity (credit scoring, marketing, data sharing with partners, fraud analytics). Each purpose needs a separate consent mechanism.
  • Fintech — RBI localisation and DPDP cross-border: RBI's 2018 payment data localisation rule continues to apply. DPDP's cross-border framework (Section 16) is an additional layer, not a replacement. Map your data flows to both frameworks. See /dpdp-cross-border-data-transfer.
  • Fintech — breach dual-reporting: breaches affecting financial data now require notifications to CERT-In (6 hours), RBI (as per applicable RBI cyber incident reporting directions), and the Data Protection Board (DPDP). Three parallel notification obligations exist for the same incident.
  • Healthcare — SPDI sunset for health records: health records were a defined SPDI category with specific obligations including written consent and collection limitation. Under DPDP, health records are personal data subject to the standard framework — the explicit SPDI protections are gone, but the general DPDP consent requirements are if anything stricter.
  • Healthcare — ABDM integration: platforms integrated with ABDM (Ayushman Bharat Digital Mission) must comply with both the National Health Data Management Policy (NHDMP) and DPDP. The NHDMP has its own consent artefacts (Health Data Consent Manager); ensure your DPDP consent flow does not conflict.
  • Both sectors — training: staff trained on SPDI Rules need updated training specifically addressing the DPDP framework, the new rights of data principals, and the breach notification protocol. Document training completion dates for audit purposes.

Related DPDP compliance resources

The SPDI-to-DPDP migration touches multiple compliance workstreams simultaneously. These pages provide deeper coverage of specific topics referenced in the migration checklist above.

  • Consent management and integration: /dpdp-consent-manager-integration — technical architecture for DPDP-compliant consent flows including purpose-specific consent, withdrawal mechanics, and consent receipt management
  • Data principal rights workflow: /dpdp-data-principal-rights-workflow — implementing access, correction, erasure, and nomination rights that did not exist under SPDI
  • Breach notification checklist: /dpdp-breach-notification-checklist — the 72-hour Board notification playbook and the dual-clock CERT-In + DPB response sequence
  • Technical safeguards: /dpdp-schedule-i-technical-safeguards — the Schedule I security requirements and how to map your existing ISO 27001 / SOC 2 controls to DPDP obligations
  • Cross-border transfers: /dpdp-cross-border-data-transfer — Section 16 negative-list framework and sectoral localisation overrides
  • DPDP vs GDPR: /dpdp-vs-gdpr-comparison — for organisations managing EU data alongside Indian data under both regimes

Migrate from IT Rules 2011 to DPDP

Get a gap analysis mapping your current SPDI compliance posture to DPDP requirements, with a prioritised migration checklist — free first engagement.

Book a free migration auditDPDP compliance for Indian startups

Explore more products

Bachao.AI covers your entire security surface — from code to cloud to compliance.

AI VAPT Scanner

Automated penetration testing for web apps and APIs. Results in under 2 hours.

Learn more →

API Security Testing

OWASP API Top 10 coverage for REST and GraphQL endpoints.

Learn more →

Cloud Security Audit

AWS, Azure & GCP misconfiguration detection with DPDP mapping.

Learn more →
Find your vulnerabilitiesStart free scan →