DPDP Rules 2025 make privileged access a compliance control

At a glance

What this is: The DPDP Rules 2025 turn privileged access, logging, and breach reporting into explicit compliance requirements for organisations handling personal data.

Why it matters: IAM, PAM, and governance teams now have to prove who accessed what, when, and why across both human and non-human administrative paths.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Arcon's analysis of DPDP Rules 2025 and privileged access compliance

Context

The DPDP Rules 2025 turn personal-data access into a governed security problem, not just a privacy policy issue. For identity teams, the hard part is proving that privileged access to systems holding personal data is controlled, logged, reviewable, and attributable across both people and machine accounts.

The article maps those legal obligations to privileged access management, but the underlying governance challenge is broader than PAM tooling. Organisations need evidence that access is limited, sessions are traceable, logs survive long enough for investigations, and breach response can reconstruct who touched personal data and what changed.

This is especially relevant where service accounts, tokens, API keys, and administrative workflows can reach databases, cloud platforms, and application layers. In practice, the regulation exposes the same weakness identity programmes already face elsewhere: visibility is often incomplete, and accountability is easier to promise than to demonstrate.

Key questions

Q: How should organisations govern privileged access to personal-data systems under DPDP rules?

A: Organisations should treat privileged access as a regulated control surface, not an internal convenience. That means limiting access to the smallest workable scope, using time-bound elevation where possible, logging every privileged action, and ensuring investigators can tie activity back to a named identity or governed automation path.

Q: Why do standing admin accounts create compliance risk for personal-data processing?

A: Standing admin accounts create compliance risk because they expand the number of always-on paths that can reach personal data and make accountability harder to prove. If access is permanent, it is also harder to show purpose limitation, harder to review meaningfully, and harder to reconstruct after an incident.

Q: What do identity teams get wrong about breach notification readiness?

A: They often focus on alerting while neglecting the evidence needed to explain the incident. Breach readiness requires session history, identity attribution, and durable logs that show what happened before, during, and after access. Without that record, notification becomes partial and remediation is harder to defend.

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.

Technical breakdown

How the DPDP rules turn access control into an evidence problem

The rules do more than require access control in principle. They require organisations to show that access was authorised, limited to need, and logged well enough to support later investigation and breach reporting. That moves identity governance from design-time policy to runtime evidence. Privileged Access Management becomes the mechanism for tying a session to a named user, recording what was done, and preserving the proof. For personal-data environments, the issue is not only blocking misuse but being able to reconstruct lawful versus unlawful access after the fact.

Practical implication: organisations need session-level auditability for privileged paths that touch personal data, not just account inventory.

Why log retention and session recording matter for breach notification

DPDP’s breach obligations depend on detail. If a breach must be reported to affected individuals and the Board with facts, impact, and remediation steps, then the organisation needs durable evidence before incident response can start. Session recordings, command logs, and immutable archives create that evidence base. Without them, breach reporting becomes guesswork and accountability weakens. This is the point where identity controls and forensics converge: access governance must produce a record that survives the incident lifecycle, not just a live alert.

Practical implication: align privileged logging retention with legal notification and investigation windows, then verify that logs are tamper resistant.

Why just-in-time privilege is now a governance requirement, not a convenience

The rules emphasise minimum necessary access, short duration, and accountability. That makes standing administrative access harder to justify when the same outcome can be achieved through approval-based, time-bound elevation. Just-in-time access reduces the number of always-on pathways that can touch personal data and narrows the evidence surface an auditor must review. It also reduces the number of identities that need to be governed as persistent high-risk accounts, which matters when access reviews are already overloaded.

Practical implication: move high-risk administrative roles toward time-bound elevation and remove standing privilege wherever the business case is weak.

Threat narrative

Attacker objective: The objective is to obtain or alter personal data while preserving enough ambiguity that the organisation cannot confidently report or attribute the activity.

1. Entry occurs when privileged or processor access reaches systems containing personal data through an administrative pathway that has not been tightly constrained or fully observed.
2. Escalation occurs when that access expands beyond the intended purpose, allowing the actor to view, modify, or extract more personal data than the task required.
3. Impact follows when the organisation cannot rapidly reconstruct who accessed what, which blocks accurate breach notification and weakens legal accountability.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

DPDP compliance turns privileged access into regulated evidence. The article is really about proof, not just control. If an organisation cannot demonstrate who accessed personal data, when they accessed it, and what they did, then it cannot satisfy the spirit of the rules even if policy language exists. For practitioners, PAM now sits in the same category as audit logging and incident response.

Standing administrative access is the wrong default for personal-data systems. The rules push toward least-necessary access, but the real governance issue is that persistent privilege creates too many unverifiable pathways. Once access to databases, cloud consoles, and application layers is always on, accountability becomes diffuse and review becomes retrospective theatre. Practitioners should treat standing privilege as a compliance liability, not a convenience.

Session attribution is the control gap the article exposes. DPDP’s accountability requirement is only credible when every privileged action can be tied to a named identity and retained evidence. Shared admin credentials, opaque automation, and weak logging all break that chain. The implication is that identity programmes must close attribution gaps across human admins and machine-operated privileged workflows.

Log retention must be designed as an identity control, not an archive problem. The one-year retention requirement matters because access events often become relevant only after a breach or complaint. If session data cannot be retained, searched, and correlated across systems, the organisation loses its ability to defend lawful processing or explain harm. Practitioners need retention models that support both investigation and regulatory response.

Purpose limitation has a direct privilege-management consequence. The Second Schedule is not abstract governance language. It means access should be granted only for the processing purpose, then removed when that purpose ends. That makes just-in-time elevation and automatic expiry far more aligned to the regulation than broad permanent roles. Identity teams should rework access design around task scope, not job title alone.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• That visibility gap is why the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the right next reference for teams redesigning access reviews and offboarding.

What this signals

DPDP-style evidence requirements will push identity teams toward better session attribution. Organisations that cannot show who accessed personal data will find that policy language alone no longer carries much weight. The practical response is to tighten identity telemetry, improve audit retention, and make privileged pathways searchable by person, account, and action.

Personal-data governance now depends on machine identity hygiene as much as on human admin controls. Service accounts, keys, and automated workflows can all become regulated access paths once they touch sensitive records. Teams that still treat these identities as infrastructure details will struggle to produce the accountability chain regulators expect.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the compliance problem is not just visibility but location discipline. The governance response is to remove secret exposure from places that cannot support auditability and lifecycle control.

For practitioners

• Map personal-data pathways to privileged identities Inventory every human admin account, service account, and automation path that can reach systems holding personal data. Classify them by data sensitivity, log coverage, and whether their access can be attributed to a named individual or process.
• Replace standing privilege with time-bound elevation Move high-risk access to just-in-time approvals with automatic expiry, especially for production databases, cloud consoles, and application administration. Keep permanent access only where you can justify it in writing and review it regularly.
• Retain tamper-resistant session evidence for investigations Store privileged session logs, command output, and recordings in immutable archives for at least the legal retention window. Verify that security, compliance, and legal teams can retrieve the evidence without depending on the original system owner.
• Bind breach reporting to identity telemetry Ensure incident response can reconstruct which identity accessed which system, what data was viewed, and what mitigation steps were taken. Without that telemetry, notification to affected individuals and the Board becomes incomplete or inconsistent.
• Review automated privileged workflows for accountability gaps Treat scripts, bots, and scheduled admin jobs as governed identities when they can touch personal data. Require ownership, rotation, logging, and expiry for any machine path that performs privileged actions.

Key takeaways

• DPDP Rules 2025 make privileged access, logging, and attribution part of the compliance baseline for personal-data systems.
• The biggest operational gap is evidence, because organisations must prove who accessed what and preserve that proof long enough to investigate and report.
• Identity teams should prioritise time-bound privilege, session recording, and machine-account governance before audit pressure forces the redesign.

Key terms

• Privilege-first IAM: An identity model that starts with the accounts, secrets, and sessions most likely to be abused, then applies stronger governance to those pathways first. It shifts attention from generic access administration to the identities that can move laterally, unlock sensitive systems, or create the biggest blast radius.
• Purpose limitation: The rule that data should be used only for the specific business purpose allowed by policy and context. In AI environments, this means a dataset may be technically accessible but still inappropriate for a given model, assistant, or agent if the use case exceeds the approved scope.
• Session Attribution: Session attribution is the ability to link every access action to a specific identity, device, and time window. In CJIS-style environments, weak attribution creates investigative gaps even when the underlying system is technically secured.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

What's in the full article

Arcon's full blog post covers the operational detail this post intentionally leaves for the source:

• Rule-by-rule mapping of DPDP requirements to PAM functions, including how each control supports compliance evidence.
• Product-specific examples of session recording, credential vaulting, and just-in-time elevation in regulated environments.
• Checklist-style comparison of logging, retention, and breach reporting obligations against deployment steps.
• Implementation-oriented guidance on how privileged workflows are aligned to accountability and audit needs.

👉 Arcon's full post covers the DPDP control checklist, PAM mapping, and compliance detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.