Why does DPDP make identity and access control a privacy issue?

Because personal data usually moves through human users, service accounts, and third-party integrations before it reaches its final destination. If those identities have broad access, the organisation cannot prove purpose limitation, minimization, or containment. Identity control becomes the mechanism that makes privacy obligations enforceable in production.

Why DPDP Turns Identity and Access Control into a Privacy Control

DPDP changes identity and access control from a purely operational security concern into a privacy control because access now determines whether personal data is handled only for a defined purpose, by the right person or system, and for the shortest practical scope. If a user, service account, or integration can reach data without tight purpose alignment, privacy obligations become difficult to evidence rather than merely difficult to promise. The OWASP Non-Human Identity Top 10 is relevant here because machine identities often carry the widest blind spots in real environments.

That is why DPDP makes identity governance part of privacy governance: who can authenticate, what they can see, and how long that access survives all affect whether collection and processing stay defensible. In practice, privacy failures often appear first as overbroad entitlements, unmanaged tokens, or stale third-party access rather than as obvious data leaks. In practice, many security teams encounter privacy non-compliance only after access paths have already drifted beyond the original processing purpose.

How Access Paths Shape DPDP Compliance in Practice

DPDP is not only about what data exists. It is also about whether the organisation can limit who processes that data, prove why they needed it, and show that the access was controlled across the full lifecycle. Identity and access control are the operational layer that turns policy into enforceable boundaries. If those boundaries are loose, privacy controls become aspirational because the organisation cannot reliably contain personal data to approved users, systems, and vendors.

In practice, the security question is less “Can this identity log in?” and more “Should this identity still be able to reach this category of personal data at all?” That distinction matters because excessive access increases the blast radius of ordinary operational mistakes, misrouted data flows, and partner integrations. It also undermines minimization, because even if the data was collected lawfully, broad downstream access can expose more records, attributes, or retention paths than the original purpose justified.

Human users should be scoped to the narrowest role that matches the processing task.
Service accounts and APIs should be treated as privacy-relevant identities, not just technical plumbing.
Third-party access should be time-bound and reviewable, especially where vendors process personal data on the organisation’s behalf.
Privileged access should be separated from routine access so that administrative convenience does not become persistent privacy exposure.

The strongest control signal is not perfect centralisation; it is whether each access path can be explained, bounded, and revoked without breaking the business process. The guidance breaks down when organisations inherit undocumented integrations, shared accounts, or legacy workflows that cannot be mapped back to a defensible processing purpose.

Where DPDP Privacy Questions Get Harder: Shared Accounts, Tokens, and Legacy Integrations

Tighter access control often increases operational overhead, requiring organisations to balance privacy assurance against administrative friction. That tradeoff becomes most visible where applications were built around shared credentials, static API keys, or indirect vendor handoffs. Those patterns are convenient, but they blur accountability and make it difficult to answer a simple privacy question: which identity processed which personal data, under which purpose, and with what scope?

There is no consensus that every environment must use the same access model, but there is broad agreement that privacy obligations weaken when identity is opaque. Shared accounts reduce attribution. Long-lived tokens reduce revocation confidence. Legacy integrations often bypass normal approval paths, which means the organisation may believe it has a privacy boundary when it actually has a convenience boundary.

That is why DPDP discussions should focus on the actual access topology, not just the policy statement. A narrow policy with broad inherited entitlements is still broad access. A well-written retention rule does not help if export jobs, analytics tools, or partner portals can copy personal data into places the original purpose did not cover. The practical answer is to treat any identity that can read, move, transform, or export personal data as part of the privacy control surface, even when that identity is non-human.

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 address the attack surface, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the technical controls, and DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC	DPDP privacy exposure is driven by who can access personal data and how that access is governed.
Recommendation: Access rights must be limited and managed so personal data stays within approved processing boundaries.
CIS Controls v8	6	Overbroad user and service access directly creates privacy exposure for personal data.
Recommendation: Control and review identities so only authorised actors can reach sensitive data.
OWASP Non-Human Identity Top 10	NHI-01	Service accounts and tokens often carry the privacy-relevant access paths in data processing.
Recommendation: Machine identities and credentials must be governed to prevent uncontrolled personal-data access.
NIST SP 800-63	AAL	Identity assurance affects whether access to personal data can be trusted and attributed.
Recommendation: Stronger authentication supports defensible access to personal-data processing systems.
DORA	ICT risk management	Poorly controlled identities can create operational exposure in regulated processing environments.
Recommendation: Access governance must be resilient enough to keep personal-data processing under control during disruption.

Practitioner Guidance

What to prioritise: Map which identities actually touch personal data, including service accounts, batch jobs, vendor connections, and admin paths. The first privacy failure to hunt for is usually not a missing notice, but an access path that is broader than the documented purpose.

What to verify: Confirm that each high-value data flow has a named owner, a defined purpose, a revocation path, and a review cycle. If any of those are missing, the organisation may have a privacy policy without a controllable enforcement point.

Common mistake: Treating identity hygiene as separate from privacy compliance. Once personal data is processed through technical identities, stale access and uncontrolled delegation become privacy exposure, not just account management debt.

Practitioner takeaway: DPDP becomes enforceable only when access rights are narrow enough that the organisation can explain and defend every path by which personal data is seen, moved, or exported.