TL;DR: Unosecur’s analysis argues that India’s DPDPA makes identity, not policy language, the practical proof of reasonable security because access control, logging, review and processor oversight determine whether personal data stays protected. The compliance test shifts from documentation to demonstrable control over who can touch data and why.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Unosecur's blog post: India's DPDPA makes identity control the operational proof of reasonable security for personal data.
Why it matters: This matters because privacy compliance now depends on proving and governing every identity that can reach personal data, including service accounts and processor access.
👉 Read Unosecur's analysis of how DPDPA makes identity control central to reasonable security
Context
India’s DPDPA does not name identity as a control domain, but its reasonable security requirement depends on it. If an organisation cannot control, justify and evidence access to personal data, it cannot demonstrate the safeguard the law expects.
The practical problem is not just privacy notices or consent flows. Personal data moves through cloud services, SaaS, processors and internal systems, so the governance question becomes who can reach it, whether that access is still needed, and whether the organisation can prove it quickly.
Key questions
Q: How should organisations govern access to personal data under DPDPA?
A: They should treat identity as the enforcement layer for personal-data access. That means tying role, attribute, and context-based access decisions to strong authentication, logging, and review processes, so every access event can be explained and evidenced during audit or investigation.
Q: Why do logs matter for proving reasonable security safeguards?
A: Logs matter because they create durable evidence of authentication, privilege use, approvals, changes and access attempts. That evidence lets an organisation reconstruct who did what, when and from where, detect misuse, and show that controls such as MFA, PAM reviews, account lockout and alerting were operating. Without reviewable logs, reasonable safeguards are hard to demonstrate after a dispute or incident.
Q: What is the difference between purpose limitation and access control?
A: Purpose limitation governs why personal data may be collected and used, while access control governs who may reach it. A system can strictly limit users through RBAC or ABAC and still breach purpose limitation if the processing goes beyond the stated reason, whereas lawful purpose alone does not justify broad access or unrestricted sharing.
Q: How do processor accounts change privacy risk?
A: Processor accounts increase privacy risk because they give a third party authenticated access to personal data under your controller’s instructions. If those accounts are shared, over-privileged, unreviewed or not offboarded, they can expose more data than intended and obscure accountability. Separate named accounts, least privilege, session logging and periodic access reviews reduce that risk.
Technical breakdown
Why access control is the real compliance layer
DPDP Rule 6 turns reasonable security into an identity question because it requires measures to control access to the computer resources used to process personal data. That means the security control is not just encryption or masking, but the ability to decide which identities can reach the system in the first place. In practice, this pulls entitlement design, ownership and review into the compliance model. If access cannot be tied to purpose, ownership and audit evidence, the safeguard is weak even when the data itself is encrypted. See the IAM and IGA Basics.
Practical implication: Treat access governance as part of DPDPA compliance evidence, not as a separate IAM exercise.
Why logs and review matter as much as prevention
DPDPA and its rules require visibility into who accessed personal data, along with logs that can support detection, investigation and remediation. That makes access governance incomplete unless it is observable after the fact. Logs are not just a forensic extra; they are the proof that access was justified, monitored and reviewable. For identity programmes, this means access control and access evidence have to be designed together, especially across cloud and SaaS environments where identity events are scattered. See the Data Mapping and ROPA Guide.
Practical implication: Design identity logging and review as a single control objective so access can be explained under regulatory scrutiny.
How processor and third-party access changes the risk model
A data fiduciary remains accountable for personal data handled by processors, so third-party access is part of the same governance problem. The legal obligation does not stop at the first-party boundary, which means vendor accounts, delegated access and service identities must be inventoried, scoped and revoked with the same discipline as internal accounts. In identity terms, this is where ownership and offboarding matter as much as provisioning. If processor access outlives the relationship, the compliance gap is already established. See the Identity Data Privacy and Consent Guide.
Practical implication: Extend identity governance to processors, integrations and service accounts that can process personal data.
NHI Mgmt Group analysis
DPDPA makes identity the evidentiary layer of privacy compliance: the law’s practical test is not whether a privacy policy exists, but whether the organisation can prove who accessed personal data and why. That turns entitlement ownership, reviewability and access evidence into compliance artefacts, not just security controls. Boards should read this as a proof problem, not a paperwork problem.
Reasonable security collapses into access governance when personal data is distributed: the article’s central point is that data no longer sits behind one perimeter, so the real control is whether every identity touching it is known, scoped and auditable. This is where identity and IGA basics become operational rather than theoretical. Practitioners should treat fragmented access records as a failure to meet the safeguard, not a recordkeeping inconvenience.
Processor access without lifecycle discipline is a compliance exposure, not a vendor detail: if third-party accounts, service identities or delegated integrations outlive the relationship, the fiduciary has already lost control of the processing boundary. DPDPA accountability follows the data, not the org chart. Security and privacy teams need a single view of external access before they can credibly argue reasonable safeguards.
Zero Trust is the only workable interpretation of continuous access governance under DPDPA: the article effectively describes a regime where standing trust is too weak for modern data flows. The named concept here is identity evidence gap, meaning the gap between having access controls on paper and being able to prove access decisions in time. Compliance teams should assume evidence must be available on demand, or it was not operationally real.
What this signals
Identity evidence gap: privacy programmes fail when access decisions exist only in scattered consoles and spreadsheets, because regulators need a defensible record of who could reach personal data and why. The operational shift is from periodic review to continuous proof.
DPDPA will push security teams to collapse the distance between access governance and breach response. If entitlement state, logs and ownership cannot be reconstructed quickly, the organisation will struggle to show that its safeguards were reasonable.
For practitioners
- Map every identity that can touch personal data Build a current inventory of human, service and third-party identities that can reach personal data across cloud, SaaS and on-prem systems.
- Tie access to declared processing purpose Review entitlements against the purpose for which personal data is processed and remove access that is no longer justified by that purpose.
- Unify access evidence across systems Correlate logs and entitlement changes so you can answer who accessed personal data, when they did it and under what authority.
- Extend governance to processors and integrations Apply the same review, revocation and ownership discipline to vendor accounts, service accounts and OAuth integrations that handle personal data.
Key takeaways
- DPDPA compliance now depends on whether an organisation can control and justify access to personal data, not just describe its privacy rules.
- The strongest evidence under the regime is identity evidence: who had access, why they had it and whether the access was reviewable.
- Practitioners need a unified view of human, service and third-party access if they want to defend reasonable security safeguards under the Act.
Related NHI Mgmt Group resources: IAM and IGA Basics · Data Mapping and ROPA Guide · Identity Data Privacy and Consent Guide
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 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | DPDPA compliance here depends on governing who can access personal data and under what authority. |
| DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | The rules require logs, monitoring and review to detect unauthorised access to personal data. | |
| Recommendation — Apply PR.AA-05 to right-size entitlements and evidence who can access personal data. Use DE.CM-01 to monitor identity events and flag unauthorised access to personal data. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Processor and service identities that outlive their purpose create the offboarding gap this article warns about. |
| NHI-05 — Overprivileged NHI | Service accounts and tokens with broad scopes create the exact excess-access risk discussed here. | |
| Recommendation — Revoke processor and service identities promptly when the processing purpose ends. Reduce NHI scopes to the minimum access needed for each personal-data workflow. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is the practical control behind the article's DPDPA access-governance argument. |
| Recommendation — Enforce AC-6 so each identity can reach only the personal data it must process. | ||
Key terms
- Reasonable Security Safeguards: Reasonable security safeguards are the practical protections an organization should use to prevent unauthorized access, misuse, or exposure of data and systems. In identity and cyber security, they typically include strong IAM controls, MFA, least privilege, logging, encryption, vulnerability management, and risk-based policies matched to the sensitivity of the asset.
- 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.
- 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.
- Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
What's in the full article
Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:
- How the Unified Identity Fabric maps human and non-human identities across cloud, SaaS and on-prem systems
- Examples of the access evidence needed to answer regulator and auditor questions in hours, not weeks
- Operational ways to detect excessive privileges, dormant accounts and orphaned identities before they become exposure
- How the platform correlates identity events to support breach assessment and remediation
Deepen your knowledge
NHI governance, identity lifecycle management and workload identity security 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.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org