TL;DR: India’s DPDP Act turns privacy into an enforceable operating requirement, with Data Fiduciaries expected to prove how personal data is collected, shared, retained, and secured across live systems, according to LEVO. Static policies and periodic audits are no longer enough when breach exposure, third-party flows, and AI-driven processing can all create liability.
At a glance
What this is: India's DPDP Act makes runtime evidence, not policy, the basis for proving how personal data is collected, shared, retained, and protected.
Why it matters: IAM, data security, and governance teams now need auditable controls over live access, data flows, and third-party processing, not just static compliance artefacts.
By the numbers:
- The Data Protection Board can impose penalties that go up to INR 250 crore for certain classes of non-compliance.
Context
The core governance problem is no longer whether an organisation has privacy policies, but whether it can prove control over personal data inside live systems. DPDP treats processing as an operational activity across applications, APIs, cloud services, and processors, which means compliance now depends on runtime visibility into who touched data, why they touched it, and what happened next.
For identity and access teams, that shifts privacy from a legal document exercise into a control evidence problem. Access scope, third-party delegation, retention, and breach response all become part of the same audit trail, especially where data moves through service accounts, automation, or AI-enabled workflows. The organisations most exposed are the ones still treating data governance as a periodic review rather than a continuously enforced operating model.
Key questions
Q: What breaks when personal data governance is only documented in policies?
A: Policies do not prove how personal data moved through live systems, who accessed it, or whether delegated processors stayed within scope. Under DPDP, that leaves organisations exposed because compliance depends on runtime evidence, not static intent. Teams need continuous visibility into identities, systems, and data flows to defend their control decisions.
Q: Why does DPDP create higher risk for APIs and third-party workflows?
A: Because those paths often move personal data outside the primary application where ownership is clearer. When APIs, cloud services, and processors share responsibility for the same data, small access or logging gaps can become a breach and a compliance failure at the same time. The risk is highest when no one can prove the full chain of handling.
Q: How can organisations tell whether data protection is actually working?
A: Look for fewer high-risk access paths, better alignment between privilege and task, and cleaner separation between normal business use and bulk or administrative movement. If privileged identities still reach more sensitive data than they need, the programme is still compensating after exposure instead of preventing it.
Q: Who is accountable when third parties process personal data under the DPDP Act?
A: The Data Fiduciary remains accountable even when processors or other third parties handle the data on its behalf. That means the organisation must set security requirements, define breach notification duties, and ensure contracts reflect compliance responsibilities. Accountability cannot be outsourced, because the fiduciary still determines why and how the data is processed.
Technical breakdown
Why DPDP turns runtime data flows into the control surface
DPDP regulates digital personal data in motion and at rest, not just formal records or policy statements. Because the law covers collection, storage, sharing, adaptation, and erasure, every API call, SaaS integration, and processor workflow becomes part of the compliance perimeter. That matters for IAM because authorisation is no longer only about human access to a system. It is also about whether services, automations, and processors can touch personal data under a defensible purpose and with traceable evidence.
Practical implication: map personal data access to runtime systems and identities, not only to application owners or policy documents.
How breach notification and evidence requirements change operational controls
DPDP expects organisations to notify the Board and affected individuals after a personal data breach, which means teams need logs, monitoring, and incident reconstruction that actually show what happened. A breach under this model is not just an access event. It is a failure to prove containment, scope, and impact across the systems that held or moved the data. That pushes security and privacy teams toward evidence-rich telemetry, especially where data traverses multiple environments before it is disclosed or altered.
Practical implication: ensure logging, correlation, and data-flow traceability are sufficient to reconstruct breach scope without manual guesswork.
What reasonable security safeguards mean for identity and access governance
The Act names reasonable security safeguards, and in practice that includes role-based access controls, multifactor authentication, encryption, reviews, and vulnerability assessment. For identity programmes, the important point is that access control alone is not enough unless it is tied to current purpose, current entitlement, and current data location. Personal data protection in a DPDP environment depends on whether entitlement, retention, and sharing controls remain accurate as systems change, not on whether a control existed at design time.
Practical implication: align identity governance, entitlement review, and data lifecycle controls so access evidence remains current when systems, vendors, or workflows change.
Threat narrative
Attacker objective: The objective is to misuse or expose personal data in a way that creates regulatory liability, operational disruption, and audit failure for the organisation.
- Entry occurs when personal data is collected or exposed through live applications, APIs, or third-party workflows that sit inside the DPDP scope.
- Credential or workflow abuse then allows unauthorised access, disclosure, alteration, or loss of that data across connected systems.
- Impact follows when the organisation cannot reconstruct what was accessed, who was responsible, and whether notification and containment obligations were met.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime data governance is now an identity problem as much as a privacy problem. DPDP does not merely ask whether organisations wrote a policy about personal data, it asks whether they can prove who accessed it, through which systems, and for what purpose. That means access governance, data-flow visibility, and processor oversight now sit on the same enforcement path. The practitioner conclusion is that privacy controls must be operationalised through live identity and data evidence.
DPDP creates audit pressure on systems, not on documents. A controller that cannot show how personal data moved through APIs, cloud services, and outsourced workflows will struggle under scrutiny even if its policy set is complete. The critical governance gap is between declared control and runtime control, and that gap widens when automation, service accounts, or external processors touch regulated data. The practitioner conclusion is that audit readiness now depends on production telemetry, not annual attestations.
Named concept: runtime personal data accountability. This is the shift from proving intent to proving control in live environments where personal data actually moves. It is especially relevant where identity systems, third-party integrations, and AI-enabled workflows all touch the same regulated dataset. The practitioner conclusion is that accountability has to be measured at execution time, not only at policy review.
DPDP will force stronger alignment between IAM, privacy, and data security teams. The law links lawful processing, breach response, and Data Principal rights into a single operational chain, which means siloed ownership is no longer defensible. Board-level risk discussions will increasingly ask for evidence of entitlement scope, retention enforcement, and third-party access traceability. The practitioner conclusion is to treat runtime access governance as a regulatory control, not just an IT hygiene issue.
The organisations most at risk are those that rely on periodic checks for a continuous data-flow problem. Static inventories and quarterly reviews cannot keep pace with the way personal data moves through modern microservice and SaaS estates. DPDP makes that gap visible and potentially expensive. The practitioner conclusion is to shift from point-in-time compliance to continuous evidence generation across systems that process personal data.
What this signals
Runtime personal data accountability: DPDP pushes enterprises toward evidence that lives in production, not in policy repositories. Teams should expect audit requests to focus on access paths, retention proof, processor oversight, and breach reconstruction, which means identity governance and data governance now need shared telemetry and shared ownership.
The organisations that cope best will be the ones that treat personal data as a continuously governed asset. That requires tighter alignment between IAM, API oversight, third-party access review, and breach response so compliance can be demonstrated when the data is actually in motion.
For practitioners
- Map personal data to runtime identities Identify which human users, service accounts, processors, and automation paths can touch regulated personal data in production, then reconcile that map against actual access and data movement.
- Instrument breach-grade logging for personal data flows Make sure access logs, API logs, and data-flow telemetry can reconstruct who accessed personal data, where it moved, and what changed before a notification decision is needed.
- Tie third-party access to current purpose and retention Review vendor and processor access so delegated rights, retention windows, and offboarding actions match the data being handled, not the contract language alone.
- Prepare rights workflows for access, erasure, and grievance Build operating procedures that can locate personal data across systems, verify requestors, and complete correction or erasure requests with evidence that the work was done.
Key takeaways
- DPDP makes personal data governance an operational proof problem, not just a privacy policy problem.
- The most important evidence is runtime visibility into who accessed data, where it flowed, and whether third parties stayed within scope.
- Teams that align IAM, data security, and breach logging will be better positioned to defend compliance when regulators ask for proof.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | DPDP enforcement depends on proving who can access personal data and why. |
| Recommendation — Apply PR.AA-05 to align entitlements with current purpose and personal data scope. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is central where personal data flows through systems, APIs, and processors. |
| Recommendation — Enforce AC-6 so access to personal data stays narrowly scoped across live workflows. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle control is necessary when humans, services, and processors all touch regulated data. |
| Recommendation — Use CIS-5 to review and remove unnecessary accounts that can reach personal data. | ||
| GDPR | Art.32 — Security of Processing | DPDP is framed through security safeguards and breach handling that mirror processing security obligations. |
| Recommendation — Use Art.32 as a benchmark for security safeguards, logging, and breach readiness. | ||
Key terms
- Data Fiduciary: The organisation or person that decides why and how personal data is processed under the DPDPA. The concept is central because it carries accountability for lawful purpose, consent, rights handling, security safeguards, and downstream governance across processors and partners.
- Data Principal: The individual to whom personal data relates under the DPDPA. The term matters because rights, notices, and consent mechanics all revolve around this person, and operational controls must reliably identify the right individual before any data action is taken.
- Significant Data Fiduciary: A data fiduciary designated for enhanced obligations because of the volume or sensitivity of data it processes. The label matters because it brings stronger governance expectations, including formal accountability structures and potential future requirements tied to risk and scale.
- Reasonable Security Measures: Reasonable security measures are the safeguards an organisation is expected to use to protect personal information based on context, risk, and operational reality. The term is intentionally flexible, which makes it important for teams to document baseline controls, exception handling, and how they justify adequacy when challenged by regulators or auditors.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle control. It is a useful fit for practitioners who need to connect access governance to broader security and compliance responsibilities.
Published by the NHIMG editorial team on September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org