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.
Why DPDP Raises the Stakes for Identity Decisions
The DPDP Act changes the practical meaning of access control because accountability now extends to who can reach personal data, why they can reach it, and whether that access is still defensible when reviewed later. Identity becomes the control plane for proving that access is limited, attributable, and proportionate. That matters for employees, contractors, partners, and the machine identities that often move data between systems.
For teams working under privacy obligations, the issue is not only breach prevention. It is also evidencing lawful access, reducing unnecessary privilege, and stopping stale or overbroad access from becoming routine. OWASP Non-Human Identity Top 10 is useful here because service accounts, API keys, and other non-human credentials frequently become the hidden path by which personal data is copied, enriched, or exposed outside the original approval boundary. In practice, many security teams discover entitlement drift only after access reviews or incident response expose how much personal data a forgotten account could still reach.
How Identity and Access Controls Turn a Privacy Duty into an Operating Control
DPDP-style accountability is enforced through operational evidence, not policy language alone. That means identity and access management has to answer four questions continuously: who has access, what type of access it is, what data it can reach, and whether that access remains justified. If an entitlement cannot be tied back to a legitimate purpose, it becomes difficult to defend under privacy governance even if the system was configured correctly at some earlier point.
In practice, this changes the priority order for control design:
- Access must be specific enough to separate ordinary business use from broad data exposure.
- Privileged paths must be treated differently from standard user access because they can override ordinary data boundaries.
- Non-human accounts must be inventoried with the same seriousness as people, because they often have wider and less visible reach.
- Logging must support attribution, review, and challenge, not just technical troubleshooting.
That is why identity governance, privileged access management, and entitlement review are no longer just security hygiene. They become the operational mechanism for demonstrating minimisation, purpose limitation, and controlled sharing in live systems. A useful complementary reference is CIS Controls v8, especially where teams need practical control priorities around access management, account lifecycle, and auditability. PCI DSS v4.0 is also relevant as a mature example of how access restriction, authentication, and evidence-based control validation are translated into measurable requirements.
Where organisations get caught out is usually not in one dramatic failure, but in ordinary access paths that were never re-validated after role changes, vendor onboarding, system integration, or automation rollout. Once those paths exist, they tend to persist because they are embedded in business process and rarely challenged until an audit, complaint, or incident forces a reset.
When the Usual Access Model Stops Being Good Enough
Tighter access control often increases friction for users and administrators, so organisations have to balance privacy assurance against operational speed. That trade-off becomes sharper when data is shared across functions, outsourced services, or automated workflows, because the number of identities and approval paths grows faster than manual review capacity.
One common gap is over-reliance on role labels. A role may sound narrow, but if it bundles reporting, support, export, or administrative functions, it can still expose personal data far beyond what the business purpose requires. Another edge case is delegated access: third-party or temporary access may be valid at the moment it is granted, then become unjustified once the task ends or the contract changes. For that reason, access expiry and periodic re-certification matter as much as initial approval.
There is also a material difference between human and machine access. A human can be questioned about why they opened a record; a service account can silently continue doing the same thing for months unless its scope is tracked and its activity reviewed. That is why many privacy control failures only become visible when someone asks who actually moved the data, not who was supposed to be able to see it. The point is not to eliminate all broad access, but to know exactly when broad access exists and why it is still justified.
Risk and Threat Considerations
DPDP increases the risk impact of weak identity control because excessive or stale access can turn ordinary business accounts into persistent exposure paths for personal data. The material issue is not only unauthorised disclosure by outsiders, but also unauthorised or unjustified internal access that cannot be defended after the fact.
Failure mechanism: overprivileged users, unmanaged service accounts, weak joiner-mover-leaver processes, and poorly scoped third-party entitlements allow personal data to remain reachable after the original business need has ended. Attackers and insiders both benefit from this because broad access reduces the effort needed to find, export, or quietly aggregate regulated data.
Impact: organisations can lose the ability to prove that access was limited to legitimate purposes, which creates compliance exposure, increases breach blast radius, and weakens trust in audit evidence and access attestations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | DPDP accountability depends on knowing who can access personal data. |
| Recommendation: Defines access governance as a core control for limiting and evidencing data reach. | ||
| CIS Controls v8 | 6 | The question centers on entitlement control and restrictive access paths. |
| Recommendation: Prioritises account and access governance to reduce unnecessary exposure. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 | Service accounts and API credentials often move personal data in DPDP-covered systems. |
| Recommendation: Requires visibility and ownership for machine identities that can access personal data. | ||
| PCI DSS v4.0 | 7 | Although sector-specific, it directly mirrors need-to-know access restriction discipline. |
| Recommendation: Treats business need as the basis for limiting access and verifying entitlement scope. | ||
| MITRE ATT&CK | T1078 | Misused legitimate accounts are a common way to access data without obvious intrusion. |
| Recommendation: Highlights how valid credentials can be abused to reach sensitive data quietly. | ||
Practitioner Guidance
What to prioritise: focus first on the access paths that can reach the largest volume of personal data with the least user friction. That usually means privileged accounts, service accounts, shared accounts, and third-party integrations before ordinary user access.
What to verify: teams should be able to show not just who has access today, but why that access exists, when it was last reviewed, and how it is removed when the purpose ends. If those answers depend on tribal knowledge, the control is weaker than it appears.
What practitioners underestimate: the hardest problem is often not authentication, but entitlement drift. The access model may have been sensible at go-live and still fail privacy expectations later because roles, data flows, and automation changed faster than governance.
Practitioner takeaway: under DPDP, identity control is not a side discipline of cybersecurity; it is the evidence layer that proves personal data access is bounded, attributable, and still necessary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
