A personal data breach under DPDP is not only a hacker breaking in. It is also your own employee accessing data they were never supposed to see.
Section 2(u) of the DPDP Act, 2023 defines a personal data breach as any unauthorised processing of personal data — not just external attacks. If a customer service executive can access the financial records of ten thousand unrelated customers, that is a structural compliance failure. The breach exists before any attacker arrives.
This is Episode 4 of our series on Technology & DPDP Compliance. Today we cover Access Control and Identity Management — the statutory obligation most organisations underestimate, and the one that touches every employee, every system, and every vendor relationship simultaneously.
The statutory foundation — Rule 6(1)(b), DPDP Rules 2025
The DPDP Rules require a Data Fiduciary to implement appropriate measures to control access to the computer resources used by such Data Fiduciary or Data Processor, wherever applicable. The term “computer resource” carries the same meaning as defined in the Information Technology Act, 2000 — covering computers, systems, networks, and data.
This is not a policy requirement. It is a technical architecture requirement. Controlling access to computer resources means your systems must be designed so that access to personal data is granted deliberately, reviewed regularly, and revoked promptly. The law does not accept “we trust our employees” as a safeguard.
Identity and Access Management — the compliance architecture
The IS Audit Standards (ICAI) define Identity and Access Management (IAM) as a framework of policies and technologies for ensuring that proper people in an enterprise have the appropriate access to technology resources. The core objective is one identity per individual — ensuring every action within a system is attributable to a specific, known person.
For DPDP compliance, IAM must address the following:
🪪 Unique user IDs for every individual Shared accounts destroy accountability. If three employees share a login, no log can tell you who accessed a customer’s personal data at 11pm on a Tuesday. CERT-In’s Elemental Cyber Defense Controls (ACIM.1) require assigning unique user IDs to all individuals to ensure full traceability of system activity. Traceability is essential for the breach investigation and remediation obligations under Rule 6(1)(c) of the DPDP Rules.
🔐 Role-Based Access Control (RBAC) and least privilege Access privileges must be aligned with job responsibilities — no more, no less. CERT-In (ACIM.2) requires implementing role-based access controls aligned with defined job responsibilities, following the principle of least privilege. Under DPDP, this principle has direct legal weight: a Data Fiduciary is required under Section 8(3) to ensure that personal data processed is limited to what is necessary for the specified purpose. If your access architecture permits employees to reach data beyond what their role requires, you are in breach of this purpose-limitation principle even without any malicious act.
🔑 Multi-Factor Authentication (MFA) Authentication must verify identity before granting access — not just rely on passwords. CERT-In (RPP.3) requires enabling MFA for all critical systems, administrative accounts, and remote access tools. For systems processing personal data, MFA is the baseline — biometric authentication or cryptographic methods such as digital certificates should be used for higher-risk systems.
👑 Privileged Access Management System administrators, database administrators, and network administrators hold elevated powers within computer systems. IS Audit by ICAI is explicit: privileged access should be assigned based upon function and job necessity, approved by the information owner, and privileged users must use their personal user IDs for non-privileged activities. CERT-In (ACIM.4) reinforces this: grant administrative privileges only when essential, and enforce segregation of duties. Shared or standing admin accounts are a compliance exposure — they make audit trails meaningless and breach investigation impossible.
🔄 Access review, transfer, and offboarding Access rights are not a one-time decision. CERT-In (ACIM.3) requires reviewing and updating user access privileges at least quarterly — or immediately upon role changes, transfers, or employee exits — using a formal offboarding checklist. IS Audit Module 5 similarly specifies that there must be a predefined account lifetime, after which re-registration is required. Personal data accessed by a former employee using a dormant account constitutes unauthorised processing under Section 2(u) of the DPDP Act — with penalties extending to ₹200 crore for failure to implement reasonable security safeguards.
The insider threat is the most overlooked DPDP risk
External breaches make headlines. But the most common source of personal data compromise is internal — employees with excessive privileges, dormant accounts, shared credentials, or no access review process. Under DPDP, all of these are compliance failures, not just security risks.
Your IAM architecture must answer three questions at any point in time: Who has access to this personal data? Why do they have it? When was that access last reviewed?
If you cannot answer all three quickly and accurately, your access controls are not DPDP-compliant.
Episode 5 of this series will cover Logs, Monitoring and SIEM — the visibility layer that makes breach detection and the 72-hour reporting obligation technically achievable.
Follow DSK Sustainability Tech LLP for the full series.
In association with our knowledge partners — Karthik & Sunil, Chartered Accountants.
Disclaimer
The contents of this post are intended for general awareness and informational purposes only. They do not constitute legal opinion, professional advice, consultancy, statutory interpretation, or a recommendation to act in any particular manner.
The Digital Personal Data Protection Act, 2023, related rules, notifications, regulatory guidance and judicial interpretations may evolve from time to time. The applicability of the law may also vary depending on the facts, sector, nature of data processing, organisational role, contractual terms and compliance framework.
Readers should not rely solely on this post for making legal, business, HR, technology, data-processing or compliance decisions. Specific advice from a qualified legal, privacy, cybersecurity, governance or compliance professional should be obtained before acting on any matter discussed.
The author / publisher shall not be responsible for any loss, liability, claim, penalty or consequence arising from reliance on the contents of this post without independent professional advice.
Leave a Reply