Designing Access Controls That Satisfy Section 8(5) Security Safeguards

Section 8(5) of the DPDP Act obliges a Data Fiduciary to implement reasonable security safeguards to prevent a personal data breach, and the accompanying Rules describe a baseline that includes encryption or masking, access controls paired with logging, and retention of relevant security logs for a defined period to support breach detection and investigation. None of this specifies a particular access control model, which means the burden falls on engineering judgment, and that judgment needs to be defensible later, not just convenient now.

In practice, defensible means you can answer three questions for any given dataset: who can access it, why they can, and how you would prove that at a point in time in the past. A role name in an IAM console does not answer the second question. The access control design has to carry an explicit mapping from role to business justification, and the logging has to be granular enough to reconstruct actual access, not just successful logins.

Role-based access control is the right starting point for most systems: it is auditable, easy to explain to a Data Protection Board, and maps cleanly onto job functions. The failure mode is role explosion, where every edge case spawns a new role until the role list is as unmanageable as the permissions it replaced. This tends to happen fastest around personal data, where support, fraud, analytics, and engineering teams all want slightly different slices of access.

Attribute-based access control, layered on top of a smaller set of coarse roles, handles this better once the exceptions start piling up. Instead of a new role per exception, attributes like data sensitivity tier, purpose tag, and requester context drive the decision at query time. This is more work to build but scales without the audit trail turning into an unreadable list of one-off roles that nobody remembers the reason for.

Every access control system eventually meets an incident where someone legitimately needs access they do not normally have, right now, to fix a production problem touching personal data. If there is no sanctioned break-glass path, people route around the controls informally, and that informal path is exactly what an inquiry will find and flag. Build an explicit break-glass mechanism: time-boxed elevated access, mandatory justification captured at the time of use, and automatic, prominent logging that is reviewed afterward rather than filed away.

The review step matters as much as the access grant. A break-glass event that is never looked at again is indistinguishable, from an audit perspective, from an access control that does not exist. Route every break-glass use to a queue that a second person actually clears, and treat repeated use by the same person or team as a signal that the standard access model has a gap worth fixing.

Access controls decay even when nobody changes the configuration, because the people behind the roles change jobs, projects end, and contractors roll off without their access being revoked. A periodic recertification process, where role owners actively confirm each grant is still needed, is what keeps the access model matching reality instead of documenting a snapshot from eighteen months ago.

This does not need to be a fully manual spreadsheet exercise. Automate the collection of who-has-access-to-what, route it to the right owner, and require an explicit action rather than silence-as-approval, since silent recertification tends to rubber-stamp stale access. Tie the cadence to data sensitivity: high-sensitivity stores reviewed quarterly, lower-sensitivity systems on a longer cycle.

If you are not yet sure how your current access model measures up, the Readiness Assessment tool on this site walks through the practical gaps organizations typically have against Section 8(5) expectations, and the Checklist Generator can turn the gaps you find into a tracked remediation list.