DPDPA makes identity the control plane for personal data access

At a glance

What this is: This is an analysis of how India’s DPDPA reframes identity as the operational control point for personal data access, accountability, and evidence.

Why it matters: It matters because IAM, IGA, PAM, and privacy teams now need one access model that can prove lawful, contextual, and auditable handling of personal data across workforce, partners, cloud, and SaaS.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Ping Identity's analysis of DPDPA and identity accountability

Context

DPDPA turns personal data access into an accountability problem, not just a privacy policy problem. In practice, that means the organisation must be able to show who accessed data, why they were allowed to do so, and what proof exists for that decision. For identity teams, the primary keyword here is personal data access governance, because the law pushes enforcement into IAM rather than leaving it in legal or policy documents.

The operational gap is familiar to IAM, IGA, and PAM teams: broad access, inconsistent step-up authentication, weak audit trails, and fragmented ownership across regions and business units. That makes DPDPA a governance test for the whole identity stack, especially where workforce, third-party, cloud, and SaaS access all intersect.

This is also where identity lifecycle discipline matters. If access reviews, certification, and offboarding are not tied to evidence and policy outcomes, the organisation can describe intent but cannot demonstrate control. That is a common enterprise pattern, not an edge case.

Key questions

Q: How should organisations govern access to personal data under DPDPA?

A: They should treat identity as the enforcement layer for personal-data access. That means tying role, attribute, and context-based access decisions to strong authentication, logging, and review processes, so every access event can be explained and evidenced during audit or investigation.

Q: Why do broad access entitlements create DPDPA risk?

A: Broad entitlements make it hard to prove that access was necessary, proportionate, and condition-specific. When users or partners can reach too much data by default, the organisation inherits compliance debt, stronger breach exposure, and weaker accountability if regulators ask for evidence.

Q: How do security teams know if identity controls are supporting privacy compliance?

A: Look for evidence that access decisions are contextual, logged, and reviewable. If the organisation can reconstruct who accessed personal data, why access was allowed, and when privileges changed, identity controls are supporting privacy compliance in a measurable way.

Q: Who is accountable when a third party accesses personal data outside policy?

A: The organisation remains accountable for the access model, even when processing is shared with contractors, outsourcers, or cloud providers. That is why third-party access must sit inside the same lifecycle, review, and offboarding process as internal access.

Technical breakdown

Why DPDPA makes identity the access control plane

DPDPA changes the meaning of compliance evidence. Instead of treating privacy as a legal overlay, organisations must use identity signals to prove access decisions in real time. That requires binding authentication, authorisation, policy conditions, and audit logging into one control path. Role-based and attribute-based decisions matter because the law is not only asking whether access exists, but whether it was justified at the moment it was used. In that model, identity becomes the system that enforces and explains access, not just the system that logs in users.

Practical implication: map all personal-data-processing systems to identity-enforced policy decisions and audit trails.

How contextual access changes the DPDPA governance model

Contextual access means access is no longer granted once and assumed valid everywhere. The decision can change based on device, location, risk signals, or data sensitivity. For DPDPA programmes, that matters because the same user may need different treatment across regions, vendors, and processing environments. A static approval model cannot explain those differences well enough when a regulator or auditor asks for evidence. The real shift is from coarse access entitlement to conditional access accountability, where each decision is both enforceable and explainable.

Practical implication: use context-aware policies for sensitive systems rather than relying on broad standing entitlements.

Why lifecycle and auditability now sit inside privacy operations

Lifecycle controls used to be seen as IAM hygiene. Under DPDPA, they become part of the evidence chain for lawful processing, storage limitation, and access minimisation. Access reviews, offboarding, and entitlement certification are only useful if they produce clear proof that access changed when business conditions changed. Without that proof, the organisation cannot defend its access posture during investigations, breach reviews, or consent-related disputes. The key issue is not whether a control exists, but whether it creates a defensible record of identity decisions over time.

Practical implication: connect access reviews and offboarding directly to evidence that can survive audit and regulatory scrutiny.

Threat narrative

Attacker objective: The attacker or negligent insider seeks access to personal data beyond what the organisation can credibly justify or prove.

1. Entry occurs when broad workforce, partner, or SaaS access reaches personal-data systems without sufficiently specific policy constraints.
2. Escalation follows when standing entitlements and inconsistent authentication let users reach more data than their role or context justifies.
3. Impact appears as regulatory exposure, failed investigations, and weakened ability to prove lawful access decisions to the Data Protection Board.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity accountability is now a privacy control, not a back-office hygiene function. DPDPA pushes organisations to prove who accessed personal data, under what conditions, and with what evidence. That shifts IAM from supporting infrastructure to the operational mechanism for compliance, auditability, and dispute handling. The implication is that privacy programmes without identity enforcement remain descriptive, not defensible.

Standing access to personal data creates compliance debt. The access model many enterprises inherited was designed for convenience and broad productivity, not for condition-specific accountability. Under DPDPA, that gap becomes visible because the organisation must explain access decisions rather than merely assert them. Practitioners should recognise this as a governance problem with lifecycle, certification, and policy consequences.

Conditional access is the right concept, but only if it is measurable. Context-aware authentication and authorisation are useful only when they produce traceable decisions that survive audit. If the policy cannot show why access was allowed or denied, it does not solve the compliance problem. The field needs more than policy logic; it needs evidence-grade identity control.

Vendor and third-party access is part of the same identity boundary. DPDPA does not stop at employees, and neither should governance. Outsourcers, SaaS, cloud services, and processors all sit inside the access chain that creates accountability risk. The practical conclusion is that shared access models must be governed as one identity surface, not as separate operational silos.

Personal data access governance is the named concept this law makes unavoidable. The governance model was designed for permissions, but DPDPA demands provable access accountability across people, partners, and platforms. That assumption fails when access decisions must be explained to regulators, auditors, and data principals in operational terms. Practitioners must rethink how identity evidence is generated, not just how access is granted.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams still lack a complete inventory of machine access paths.
• For a broader governance baseline, see Top 10 NHI Issues for the access, lifecycle, and visibility failures that usually precede control breakdowns.

What this signals

Personal data access governance will increasingly sit inside IAM operating models rather than privacy policy documents. Organisations that cannot tie identity decisions to contextual evidence will struggle to defend their compliance posture when access questions become regulator questions. The practical direction is toward policy-enforced access records that can be inspected as part of day-to-day governance, not assembled after an incident.

The strongest signal for practitioners is that privacy, IAM, and PAM can no longer operate as parallel programmes. Once entitlement review, authentication strength, and auditability are part of the same DPDPA evidence chain, gaps in one area become gaps in all three. Teams should prepare for a much tighter link between access recertification, third-party governance, and compliance reporting.

Identity lifecycle controls will become a board-level trust issue in India-facing programmes. When users, contractors, and service accounts all touch personal data, offboarding and certification are no longer housekeeping tasks. They are the proof layer that tells the organisation whether access was truly minimised or merely documented after the fact.

For practitioners

• Map personal-data systems to identity enforcement points Identify every application, API, SaaS tenant, and cloud service that processes Indian personal data, then document which identity control enforces access and which log proves the decision. Prioritise systems where multiple teams share ownership or where access is inherited through third parties.
• Standardise contextual access for sensitive processing Apply role-based and attribute-based access controls with step-up authentication for systems handling personal data, especially where users operate across regions or business units. Keep policy decisions explainable so audit teams can reconstruct why access was granted.
• Tie access reviews to evidence, not just attestation Run certification on high-risk entitlements and require each review cycle to produce a defensible record of what changed, who approved it, and which personal-data systems were affected. Use the review outcome as the control evidence, not the spreadsheet alone.
• Treat third-party access as part of one lifecycle Bring contractors, outsourcers, and service providers into the same provisioning, review, and offboarding process as employees when they can reach personal data. Offboarding must revoke access and preserve the proof that revocation occurred.
• Build audit trails that survive regulator questioning Centralise logs for authentication, authorisation, and policy decisions across hybrid and multi-cloud environments. Make sure the record can answer who accessed what, when, and under which policy without requiring manual reconstruction.

Key takeaways

• DPDPA makes identity the mechanism for proving lawful access to personal data, not just controlling login events.
• Broad entitlements, inconsistent authentication, and weak audit trails are now privacy liabilities as much as security weaknesses.
• Teams that connect access reviews, conditional policy, and third-party offboarding to evidence will be better positioned for audit and enforcement.

Key terms

• Personal Data Access Governance: The discipline of controlling, evidencing, and reviewing access to personal data across systems, teams, and third parties. It combines identity, policy, and audit capabilities so organisations can prove who accessed data, why access was allowed, and what changed over time.
• Conditional Access: An access model where authentication and authorisation depend on context such as device, location, risk, or data sensitivity. It is more than step-up login because the policy decision must also be explainable and recorded for audit and compliance purposes.
• Identity Evidence: The records that show how an access decision was made and whether it was valid at the time. In regulated programmes, identity evidence includes policy logs, authentication events, entitlement changes, and review outcomes that can survive audit or incident inquiry.
• Access Certification: A recurring governance process in which access rights are reviewed and revalidated against current business need. For regulated data, certification must do more than confirm ownership. It must produce a clear record that access was retained, changed, or removed for a documented reason.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Ping Identity: DPDPA Is Redefining Data Responsibility in India - Is Your Identity Strategy Ready? Read the original.