Are IT Rules 2011 (SPDI Rules) still in force after DPDP?

The IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules 2011 — commonly called the SPDI Rules — remain on the statute books until formally repealed. However, DPDP Act 2023 Section 44 explicitly supersedes provisions of the IT Act 2000 that are inconsistent with DPDP. For matters covered by DPDP (consent, breach notification, data principal rights, penalties for personal data mishandling), DPDP takes precedence. The 2011 Rules continue to govern residual scenarios not yet covered by DPDP rules (e.g., some non-personal data scenarios, specific IT Act Section 43A civil liability framework).

Do I need fresh consent under DPDP if I already had consent under IT Rules 2011?

Yes, in most cases. DPDP's consent requirements are more specific and granular than the 2011 Rules. DPDP requires: (1) consent that is freely given, specific, informed, unconditional, and unambiguous; (2) a separate notice listing each purpose; (3) purpose-specific granularity (consent for purpose A does not authorise purpose B); (4) an easy withdrawal mechanism linked to the service. If your 2011-era consent was a bundled privacy policy acceptance or a broad T&C click-through, it is unlikely to satisfy DPDP's specificity requirement. A consent re-architecture and re-consent campaign is the safer path for most organisations.

Is sensitive personal data still a special category under DPDP?

Not in the same way as under the 2011 Rules. The SPDI Rules created an explicit list of sensitive personal data (financial information, health records, biometric data, passwords, sexual orientation, physical/mental health condition) that attracted additional obligations including written consent, collection limitation, and transfer restrictions. DPDP 2023 does not maintain a tiered SPDI category — it applies a broadly uniform framework to all personal data. However, certain categories (children's data, data processed by SDFs) attract additional obligations, and the Government can notify additional categories for special treatment. For practical compliance purposes, treat your former SPDI categories as high-priority items requiring careful consent and security attention under DPDP.

What was the penalty cap under SPDI Rules vs DPDP?

Under the IT Act Section 43A (the civil liability basis for the 2011 Rules), compensation was paid to affected individuals and was not subject to a statutory cap — courts assessed actual damages. Criminal penalties under IT Act Section 72A could reach three years imprisonment and a fine up to ₹5 lakh per offence. Under DPDP 2023, the Data Protection Board can impose penalties up to ₹200 crore per violation (with higher amounts for specific violations like failure to implement security safeguards). This represents a structural shift: from individual-compensation civil liability to regulatory penalties assessed by an administrative body, with significantly higher maximum amounts.

What specifically changes for fintech and healthcare under DPDP vs IT Rules 2011?

Fintech: payment data was already subject to RBI localisation requirements independent of SPDI Rules. Under DPDP, consent for financial data processing must now be granular and purpose-specific — the broad consent in bank account opening forms must be re-evaluated. Breach notification obligations now run to the Data Protection Board (not just RBI/CERT-In), adding a parallel channel. Healthcare: health records were SPDI under 2011 Rules; under DPDP they retain high sensitivity but lose their separate legal category. The consent mechanism must be updated to DPDP standards. ABDM-integrated platforms also have DPDP obligations layered on top of the National Health Data Management Policy. Both sectors must update privacy notices, re-consent flows, and breach notification runbooks.

DPDP Act 2023 vs IT (SPDI) Rules 2011 — Migration Guide

Same data, new law

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 DPDP DPDP 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 audit DPDP 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 →

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

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

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

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

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

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

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

What survives from the IT Rules 2011 framework

Migration checklist — from IT Rules 2011 to DPDP

What existing SPDI documentation translates and what does not

Sector-specific migration notes — fintech and healthcare

Related DPDP compliance resources

Migrate from IT Rules 2011 to DPDP

Explore more products

AI VAPT Scanner

API Security Testing

Cloud Security Audit

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

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

What survives from the IT Rules 2011 framework

Migration checklist — from IT Rules 2011 to DPDP

What existing SPDI documentation translates and what does not

Sector-specific migration notes — fintech and healthcare

Related DPDP compliance resources

Migrate from IT Rules 2011 to DPDP

Explore more products

AI VAPT Scanner

API Security Testing

Cloud Security Audit