DPDP Rules 2025, Rule 6(1)(b): What “Access Control on Computer Resources” Actually Requires

Part of a series on DPDPA Section 8(5) and DPDP Rules 2025, Rule 6. Read the pillar post first if you haven’t.

The Clause, Verbatim

“(b) appropriate measures to control access to the computer resources used by such Data Fiduciary or such a Data Processor, wherever applicable;”

DPDP Rules 2025, Rule 6(1)(b)

Rule 6(2) adds one more piece: “computer resource” carries the same meaning given to it in the Information Technology Act, 2000. That’s a deliberately broad, technology-neutral definition, and it’s worth reading in full before assuming this clause only means “who has database access.”

What It Technically Requires

Under the IT Act’s definition, “computer resource” covers computer systems, networks, data, computer databases, and software, essentially the full stack a Data Fiduciary or Processor uses to touch personal data, not just the data store itself. Read that way, Rule 6(1)(b) requires access control across:

Application-layer access. Role-based access control (RBAC) governing which users and services can read or write personal data through your product’s own interfaces and APIs, with roles scoped to what each function actually needs rather than broad admin defaults.

Data-layer access. Database-level permissions independent of application logic, so a compromised application credential doesn’t automatically mean unrestricted database access. This includes row-level or column-level restrictions where a single table mixes personal data with non-personal data.

Infrastructure access. Who can SSH into servers, access cloud consoles, or modify infrastructure-as-code that provisions systems processing personal data. A well-secured application sitting on a cloud account with broad, unaudited IAM permissions has a real gap here, even if the application layer looks clean.

Authentication strength. Multi-factor authentication for any account with access to personal data, particularly privileged or administrative accounts, and particularly for Data Processors who may be accessing your systems remotely.

Offboarding and review. A process for revoking access when someone changes roles or leaves, and periodic review of who currently has access versus who should. Access granted correctly six months ago and never revisited is a common gap between “we have access control” and “our access control reflects reality.”

Where This Gets Subjective

Granularity. “Control access to computer resources” is satisfied, minimally, by an application login screen. It’s satisfied more thoroughly by RBAC scoped to specific data fields, and more thoroughly still by attribute-based access control that factors in context (device, location, time) before granting access. The clause doesn’t specify a granularity, so organisations reasonably disagree about how far down the stack “control” needs to reach before it’s genuinely controlling anything.

What counts as a “computer resource” in your environment. Does the definition extend to developer laptops that have local copies of production-adjacent data? CI/CD runners that process personal data during test runs? A contractor’s personal device used to access an admin panel? The IT Act’s definition is broad enough to plausibly capture all of these, but organisational access-control programmes very often stop at production infrastructure and treat everything upstream of it (developer environments, build pipelines, third-party tooling) as out of scope. That’s a defensible operational boundary. It’s a much harder one to defend as a legal boundary if a breach originates from exactly that upstream environment.

“Wherever applicable.” The clause itself carries a built-in qualifier: access control is required wherever applicable, which implicitly concedes that not every computer resource needs the same treatment. Reasonable people will disagree on where “applicable” starts and stops, particularly for lower-sensitivity data or internal tooling several steps removed from the personal data itself.

What the Breakdown Really Means

If your access-control programme starts at the production database and stops there, Rule 6(1)(b) is asking you to look one layer further up the chain than that.

Vimalendukumar Dwivedi is Co-founder of Scrutora, a Code Compliance Platform.