Notifications
Clear all
Topic starter
24/06/2026 7:07 pm
TL;DR: India’s DPDPA shifts data protection from policy intent to access accountability, requiring organisations to prove who can access personal data, under what conditions, and with what evidence, according to Ping Identity. That makes IAM the control plane for compliance, auditability, and trust, not just a supporting system.
NHIMG editorial — based on content published by Ping Identity: DPDPA Is Redefining Data Responsibility in India - Is Your Identity Strategy Ready?
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.
Questions worth separating out
Q: How should organisations govern access to personal data under DPDPA?
A: They should treat identity as the enforcement layer for personal-data access.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Ping Identity's full article covers the operational detail this post intentionally leaves for the source:
- Detailed explanation of how Ping positions IAM as a DPDPA control surface across workforce, partner, and customer journeys
- Specific examples of RBAC, ABAC, and just-in-time access patterns for sensitive personal-data systems
- The vendor’s own discussion of deployment models, residency considerations, and logging controls
- Practical notes on how Ping frames its processor role and security commitments under DPDPA
👉 Read Ping Identity's analysis of DPDPA and identity accountability →
DPDPA and identity accountability: what IAM teams need to change?
Explore further
25/06/2026 4:15 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: DPDPA makes identity the control plane for personal data access
