Why GDPR readiness does not equal DPDPA readiness

At a glance

What this is: This is an analysis of why GDPR maturity does not automatically translate into DPDPA readiness, with consent governance, notice workflows, vendor accountability, and children’s data handling emerging as the key operational differences.

Why it matters: It matters because privacy teams, IAM-adjacent governance owners, and security stakeholders must align data handling, identity-linked consent flows, and incident response to a jurisdiction that changes the operational control model rather than just the terminology.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read OneTrust's analysis of why GDPR readiness does not guarantee DPDPA readiness

Context

GDPR and India’s DPDPA are often treated as near equivalents because both frameworks use familiar privacy terms such as consent, controllers or fiduciaries, processors, rights requests, and breach notifications. The operational reality is different: DPDPA shifts privacy governance toward consent as the dominant control for many processing activities, which changes how organizations design notices, collect permissions, propagate withdrawals, and prove compliance.

For privacy teams, the core challenge is not terminology but operating model. Mature GDPR programmes may already have data inventories, rights workflows, and vendor oversight, but DPDPA requires those controls to be reassembled around more explicit consent management, localized breach handling, and broader fiduciary accountability. That makes this a governance redesign problem, not a simple regional policy update. Identity-linked consent orchestration becomes especially relevant where customer, employee, or partner systems must prove who consented, when, and for what purpose.

Key questions

Q: How should organisations prepare for DPDPA if they already comply with GDPR?

A: They should treat DPDPA as a separate operating model, not a compliance overlay. Start by remapping lawful bases, redesigning consent capture and withdrawal, localising notice language, and checking whether vendor, breach, and children’s data workflows still work under India-specific rules. GDPR maturity helps, but it does not remove the need for a fresh control review.

Q: Why does DPDPA place so much emphasis on consent governance?

A: Because many processing activities depend on consent or narrow legitimate uses, consent becomes the operational gate for collection, use, and downstream sharing. That makes the quality of notice, capture, withdrawal, and evidence more important than in programmes that rely on broader GDPR lawful bases. The practical issue is not policy wording, but whether systems enforce the decision consistently.

Q: What do privacy teams get wrong when they reuse GDPR workflows for DPDPA?

A: They often assume lawful basis, breach, and vendor processes can be reused without adjustment. That breaks down when consent must be more explicit, children’s data rules are stricter, and India-specific notification or accountability steps are required. Reuse is fine only if the underlying system behaviour is revalidated for DPDPA.

Q: Who is accountable when DPDPA compliance fails across vendors and processors?

A: The data fiduciary remains the primary accountability point, even when processors and service providers are involved. That means vendor oversight, contract language, audit rights, and escalation paths must be designed around fiduciary responsibility rather than assuming processor obligations carry the same weight as under GDPR. Accountability needs to be operational, not just contractual.

Technical breakdown

How DPDPA consent governance differs from GDPR lawful bases

GDPR permits several lawful bases for processing personal data, including legitimate interests and contractual necessity, while DPDPA narrows many activities toward consent or defined legitimate uses. That change affects the control plane for privacy operations because organisations must tie each processing purpose to a valid consent record or a narrow statutory basis. In practice, this makes consent status part of the operational system design, not just a legal checkbox. It also increases the importance of evidence, propagation, and revocation across downstream applications, analytics, and vendor workflows.

Practical implication: map every processing activity to its lawful basis and verify that consent state propagates into the systems that actually act on the data.

Why consent notices and withdrawal workflows become harder to govern

Under DPDPA, consent must be free, specific, informed, unconditional, unambiguous, and supported by clear affirmative action. Withdrawal must also be as easy as giving consent, which means the workflow does not end at capture. Organisations need notices that connect to actual processing purposes, and systems that can enforce withdrawal across product, marketing, support, and vendor-integrated environments. Where consent managers are used, internal orchestration must remain consistent even when consent signals move through external intermediaries.

Practical implication: test consent capture, withdrawal, and notice delivery as a single workflow across all channels, not as separate compliance tasks.

Children’s data and breach response introduce regional control gaps

DPDPA treats children as under 18 and adds restrictions around tracking, behavioural monitoring, and targeted advertising. That creates a different control boundary from many GDPR programmes, which often use other age thresholds or product-specific logic. Breach response also differs because DPDPA expects notification to both the Data Protection Board and affected data principals regardless of risk thresholds. The result is a regional control model that touches age verification, consent gating, escalation paths, evidence preservation, and communications coordination.

Practical implication: build India-specific playbooks for children’s data handling and breach notification instead of reusing GDPR incident templates unchanged.

Threat narrative

Attacker objective: The objective is not malicious intrusion but governance failure through regulatory misalignment, where organisations expose themselves to avoidable compliance breakdowns and operational blind spots.

1. Entry occurs when organisations assume GDPR-compliant privacy operations can be reused unchanged for DPDPA without redesigning consent, notice, and withdrawal workflows.
2. Escalation follows when that assumption spreads into vendor governance, children’s data handling, and breach response, creating gaps between policy and system enforcement.
3. Impact appears as invalid consent records, delayed withdrawals, incomplete notices, and India-specific notification failures that undermine fiduciary accountability.

NHI Mgmt Group analysis

DPDPA is a consent-operating-model shift, not a GDPR translation exercise. The article correctly frames the problem as structural rather than linguistic. GDPR-mature organisations often assume shared terminology implies shared control design, but DPDPA puts much more weight on explicit consent capture, revocation, and evidence. For privacy, security, and identity programmes, that means the control boundary moves from policy wording to operational enforcement. Practitioners should treat DPDPA readiness as a workflow redesign project, not a document update.

Consent governance now behaves like an identity control, because the system must know who granted what, when, and for which purpose. That is where privacy and identity governance intersect most clearly. When consent is the dominant operational basis, the organisation needs reliable linkage between a person, a data purpose, and a downstream processing decision. This is not classic IAM, but it does rely on identity-grade traceability and lifecycle discipline. Practitioners should align consent records with authoritative identity and audit data.

Consent propagation gap: the failure mode is assuming a captured consent automatically governs every downstream system. DPDPA exposes how easily privacy programmes can lose control once consent state leaves the front-end channel. If marketing, support, analytics, and third-party processors do not consume the same consent state, the organisation cannot prove compliance consistently. This is the kind of governance debt that only appears when a jurisdiction tightens operational expectations. Practitioners should verify that consent state is machine-enforced across all processing layers.

Children’s data under DPDPA forces organisations to re-evaluate global privacy templates and local operational ownership. Age thresholds, tracking limits, and targeted advertising restrictions create region-specific control logic that cannot be handled safely through a single global rule set. The operational burden falls across product, legal, engineering, and vendor management, with clear accountability for local exceptions. This is a strong example of why regional privacy operating models matter. Practitioners should localise controls where the law changes the processing boundary.

Breach response under DPDPA makes jurisdiction-aware incident workflows part of privacy governance, not just security response. When notification obligations differ from GDPR, security teams cannot rely on a global playbook that only addresses one regime. The organisation must know which events trigger India-specific reporting, what evidence must be preserved, and which teams own the external message. That places privacy operations directly inside incident governance. Practitioners should test India-specific escalation, notification, and recordkeeping before an incident forces the issue.

What this signals

Consent propagation becomes the control test: DPDPA readiness will expose whether organisations can carry a permission decision from capture to enforcement. Privacy teams should expect more scrutiny of whether consent state is machine-readable, revocable, and consistently applied across systems rather than merely documented in policy.

The strongest programmes will separate global privacy principles from local enforcement logic. That matters for India, but the same pattern is emerging across privacy and AI governance more broadly, where regional obligations force teams to manage different lawful-processing rules without fragmenting accountability.

Where identity governance intersects with privacy, the practical question is traceability. Teams need to know whether the organisation can prove who consented, for what purpose, and whether downstream systems honoured the revocation. That is a governance capability, not a legal memo.

For practitioners

• Rebuild lawful-basis mappings for India Catalogue every processing activity that relies on legitimate interests, contractual necessity, or broad GDPR assumptions, then map it to DPDPA consent or defined legitimate use. This is the fastest way to find where the operating model diverges.
• Test consent propagation end to end Validate that consent capture, withdrawal, and purpose restrictions are enforced across websites, mobile apps, customer systems, and vendor-integrated workflows. A front-end banner is not enough if downstream processors still act on stale permissions.
• Localise breach and grievance workflows Create India-specific escalation paths for notification to the Data Protection Board, affected individuals, and internal stakeholders. Align those paths with evidence preservation, multilingual communications, and vendor notification responsibilities.
• Separate global privacy policy from regional control design Keep one governance standard, but allow regional control logic for children’s data, notice language, consent timing, and retention enforcement. Global policy consistency matters less than accurate local execution when the law changes the workflow boundary.

Key takeaways

• DPDPA is operationally different from GDPR because consent becomes the central control for far more processing decisions.
• Mature GDPR programmes still need redesign work around lawful basis mapping, notice delivery, withdrawal enforcement, and India-specific breach handling.
• The practical test is whether consent and accountability are enforced across systems, vendors, and incident workflows, not just described in policy.

Key terms

• Consent Governance: Consent governance is the set of policies, systems, and evidence needed to collect, record, propagate, and withdraw permission for data processing. It becomes operationally meaningful only when the organisation can prove that downstream systems honour the decision consistently across channels and vendors.
• Data Fiduciary: A data fiduciary is the organisation primarily responsible for deciding why and how personal data is processed under DPDPA. In practice, the fiduciary owns accountability even when processors and external platforms perform the work, which makes oversight and evidence retention essential.
• Lawful Basis Mapping: Lawful basis mapping is the process of linking each personal data processing activity to the legal reason that permits it. For privacy teams, it exposes where a global GDPR programme cannot be reused unchanged because another jurisdiction narrows the available processing grounds.
• Consent Propagation: Consent propagation is the movement of a permission decision from the point of capture into every system that relies on it. If propagation fails, an organisation may have a valid-looking front-end record while downstream applications continue processing outside the user’s intent.

What's in the full article

OneTrust's full blog covers the operational detail this post intentionally leaves for the source:

• The side-by-side lawful processing comparison between GDPR and DPDPA, including where legitimate interests no longer map cleanly.
• The notice, consent, and withdrawal workflow implications for websites, mobile apps, and vendor-supported data collection.
• The children’s data and breach notification differences that privacy and security teams need to localise for India.
• The operational readiness checklist for teams that already have GDPR controls but need DPDPA-specific governance.

👉 OneTrust's full post covers lawful bases, consent orchestration, vendor accountability, and India-specific breach workflows.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle discipline, and secrets management. It helps security and privacy practitioners connect identity control thinking to governance problems that cross system boundaries.