India’s DPDP Act makes runtime data governance an audit issue

At a glance

What this is: India’s DPDP Act moves privacy compliance from documentation to provable control over live personal data flows.

Why it matters: This matters to IAM and security teams because access, retention, breach response, and processor oversight now have to be evidenced across systems that touch personal data, not just in policy documents.

By the numbers:

• The average cost of a data breach in India reached INR 220 million in 2025.
• The Data Protection Board can impose penalties of up to INR 250 crore for certain non-compliance.

👉 Read LEVO's analysis of India's DPDP Act and runtime privacy governance

Context

The DPDP Act changes the privacy conversation from policy language to operational accountability. For security and identity teams, the core issue is not whether a notice exists, but whether personal data can be traced, controlled, and defended across systems, APIs, cloud services, and third-party processors.

That makes the governance gap clear: organisations often know where data was intended to go, but not where it actually flows at runtime. In practice, the article’s starting position is typical for modern enterprises, because distributed applications and shared credentials make evidence of control harder than declarations of compliance.

Key questions

Q: How should security teams govern personal data across APIs and cloud services under DPDP?

A: Treat personal data governance as a runtime control problem. Security teams should map where data moves, restrict access to the smallest workable set of identities and processors, and keep evidence of collection, sharing, retention, and deletion across APIs and cloud services. That gives regulators and audit teams a defensible trail when they ask how data was actually handled.

Q: Why does the DPDP Act increase the importance of identity and access controls?

A: Because DPDP makes organisations accountable for how personal data is accessed in real systems, not just how it is described in policy. Identity and access controls determine who can reach the data, which service accounts can move it, and whether third-party access is still justified. Weak entitlement control becomes a compliance problem, not only a security one.

Q: What breaks when processor access is not reviewed under DPDP?

A: Processor access drift breaks accountability. If vendor accounts, service credentials, or delegated permissions remain active after the business need changes, the fiduciary may still be liable for misuse or exposure. Teams then lose the ability to prove that access was limited, timely, and revoked, which weakens both breach response and compliance defence.

Q: What should organisations do when a personal data breach may have affected Indian residents?

A: They should preserve logs, identify affected systems and identities, confirm the scope of exposed personal data, and prepare notifications to the Data Protection Board and affected individuals. The key is to move fast with evidence, because DPDP enforcement will depend on whether the organisation can reconstruct what happened and show reasonable safeguards were in place.

Technical breakdown

What DPDP means by digital personal data processing

DPDP regulates processing, not just storage or collection. Processing includes collection, recording, use, sharing, retention, and erasure, which means any workflow that touches personal data becomes part of the compliance perimeter. That is a runtime problem, because the same record may move through CRM systems, SaaS tools, APIs, analytics platforms, and AI-driven automation. The law therefore creates a governance obligation to understand the full data path, not just the original point of collection.

Practical implication: build data-flow visibility that covers live application and API paths, not only static inventories.

Why fiduciary accountability extends into processor and cloud access

The DPDP model separates responsibility from execution. A Data Fiduciary remains accountable even when processors, cloud providers, or outsourced vendors handle the data on its behalf. That means contractual terms are necessary but insufficient. The fiduciary must also prove that access is limited, monitored, and revocable across the environments where third parties actually operate. In identity terms, processor access is not just a procurement issue, it is an access governance issue.

Practical implication: treat third-party access as part of IAM and PAM governance, including review, scope control, and offboarding.

How breach reporting and rights fulfilment depend on evidence

DPDP obligations around breach notification, correction, erasure, nomination, and grievance redressal all depend on one thing: being able to reconstruct what happened to a specific person’s data. Without logs, identity context, and retention control, teams cannot prove which systems held the data, who accessed it, or whether a request was fulfilled correctly. That makes observability and auditability core control requirements rather than after-the-fact reporting features. The article correctly frames this as an operational enforcement problem, not a paperwork exercise.

Practical implication: align logging, access records, and data lineage so rights requests and incident response can be evidenced quickly.

Threat narrative

Attacker objective: The objective is to gain unauthorized access to personal data at scale and create operational or regulatory impact through misuse, disclosure, or loss of control.

1. Entry occurs when personal data is exposed across distributed systems, APIs, or third-party services that were not governed as part of the live processing surface.
2. Escalation follows when overbroad access, weak processor oversight, or poor visibility allows unauthorized use, disclosure, or alteration of that data.
3. Impact lands as regulatory exposure, breach notification work, and financial penalties that can follow from failing to control personal data in production.

NHI Mgmt Group analysis

DPDP turns runtime data governance into a control requirement, not a policy exercise. The law is only partly about consent and notice. Its real enforcement value comes from whether an organisation can show what happened to personal data across live systems, processors, and APIs. That is why static compliance artefacts fail under scrutiny, while operational evidence becomes the deciding factor. For identity teams, this means access governance must be tied to actual data movement and not just to role design.

Processor oversight is now an identity governance problem as much as a legal one. DPDP leaves the fiduciary accountable even when a third party performs the processing. That makes delegated access, service credentials, and vendor offboarding part of the compliance surface. The named concept here is processor access drift, where third-party permissions outlive the business need that justified them. Organisations that cannot bound that drift will struggle to defend their control posture.

DPDP raises the evidentiary bar for breach response and rights fulfilment. The law expects organisations to notify, correct, erase, and explain data use with enough precision to withstand challenge. That requires line-of-sight into identity, retention, and data lineage, not just incident tickets. The governance lesson is straightforward: if a team cannot reconstruct who accessed personal data and why, it cannot prove compliance. Practitioners should therefore treat auditability as a first-class security control.

AI and automation systems now sit inside the DPDP control boundary. The article correctly includes analytics, AI, and automation systems among the environments that touch personal data. That matters because machine-driven workflows often consume data at scale and at speed, which makes access review and purpose limitation harder, not easier. The practical conclusion is that DPDP readiness now requires governance over both human and machine access paths.

India’s enforcement model will reward organisations that can demonstrate control in production. DPDP is not satisfied by statements about intent or high-level principles. It rewards evidence that data is discoverable, access is bounded, breach paths are visible, and third-party handling is supervised. That is the direction privacy governance is heading more broadly: control proof over control claims.

What this signals

The practical signal for Indian enterprises is that privacy controls now need the same operational discipline as privileged access management. If a team cannot show which identities touched personal data, which processors still have access, and how quickly exposure can be contained, compliance claims will remain fragile. Processor access drift: the longer delegated access survives after a business relationship changes, the harder it becomes to defend accountability or prove reasonable safeguards.

That creates a strong overlap between DPDP readiness and identity governance. Organisations should expect audit teams to ask for more than policy artefacts and consent language. They will need evidence of bounded access, retention enforcement, and recoverable audit trails, anchored to operational systems rather than document repositories. For identity-led programmes, this is a clear signal to align data controls, IAM, and PAM around live processing paths.

For practitioners

• Map personal data to live processing paths Track where digital personal data moves across applications, APIs, SaaS tools, analytics platforms, and AI workflows so you can evidence processing scope at runtime.
• Tighten third-party access governance Review processor accounts, service credentials, and delegated permissions to ensure every vendor access path is time-bounded, monitored, and revoked on offboarding.
• Align rights fulfilment to audit evidence Link access logs, retention controls, and data lineage records so correction, erasure, nomination, and breach notification workflows can be reconstructed for regulators.
• Embed breach-ready observability Use logging and monitoring that can identify who accessed personal data, which systems handled it, and whether the access was expected or anomalous.

Key takeaways

• DPDP makes privacy a production control problem, because compliance now depends on how personal data behaves inside live systems.
• The enforcement risk is material, with breach costs and penalties high enough to change board-level priorities.
• Teams that can prove access, retention, and processor oversight in runtime will be better positioned than teams relying on static documentation.

Key terms

• Digital Personal Data Protection Act: India’s privacy law for digital personal data, including data collected offline and later digitised. It requires organisations to justify processing, protect data with reasonable safeguards, and support rights handling, breach notification, and accountability through operational controls rather than policy alone.
• 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.
• 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.
• Processor Access Drift: The condition where vendor, service, or delegated access continues beyond the business need that originally justified it. In practice, this creates hidden compliance exposure because the organisation may still be accountable for permissions that are no longer actively reviewed, bounded, or necessary.

What's in the full article

LEVO's full article covers the operational detail this post intentionally leaves for the source:

• The article breaks down DPDP obligations by role, including Data Fiduciary, Significant Data Fiduciary, and Data Processor responsibilities.
• It details how penalties, breach notification, and Data Principal rights change the operational burden on compliance and security teams.
• It explains where runtime visibility, API monitoring, and sensitive data discovery fit into the compliance model.
• It includes a DPDP versus GDPR comparison that helps teams separate Indian obligations from EU privacy requirements.

👉 LEVO's full article covers the compliance checklist, role definitions, and DPDP versus GDPR differences in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners build the control discipline that modern compliance and audit demands.