DPDP Rules 2025, Rule 6(1)(c): What “Visibility Through Logs, Monitoring and Review” 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

“(c) visibility on the accessing of such personal data, through appropriate logs, monitoring and review, for enabling detection of unauthorised access, its investigation and remediation to prevent recurrence;”

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

Three distinct activities are named here, not one: logs (the record), monitoring (watching the record), and review (periodically assessing it). All three exist in service of a stated purpose, detecting unauthorised access, investigating it, and preventing recurrence, which is worth keeping in view, because it’s easy to satisfy the letter of “we have logs” while missing the purpose entirely.

What It Technically Requires

Access logging. Every read or write of personal data, at minimum at the application and database layer, captured with enough detail to answer “who accessed what, when, and from where.” That means user or service identity, timestamp, the specific resource accessed, and the action taken, not just “someone queried the users table.”

Centralised, tamper-resistant log storage. Logs held somewhere separate from the systems that generate them, with access to the logs themselves controlled (an attacker who can access personal data and then edit the log of that access has defeated the purpose of logging entirely).

Monitoring and alerting. Automated detection for patterns that indicate unauthorised access: unusual access volume, access from unfamiliar locations or at unusual times, access patterns inconsistent with a user’s or service’s normal behaviour, failed authentication spikes. This is what turns a log (a passive record) into visibility (an active capability).

Investigation workflow. A defined process for what happens when an alert fires or an anomaly is flagged: who’s notified, how the incident is triaged, how findings are documented.

Periodic review, independent of alerting.Scheduled review of access logs and access grants, not only reactive review triggered by an alert. This catches the access patterns that are individually unremarkable but cumulatively wrong, like an account that’s accumulated access it no longer needs.

Remediation and feedback loop. A documented path from “we found unauthorised access” to “we changed something so it’s less likely to recur,” whether that’s revoking a credential, tightening a permission, or patching a gap the investigation surfaced.

Where This Gets Subjective

Does automated alerting alone satisfy “review”? The clause names monitoring and review as separate activities. A system with excellent automated alerting but no human periodically looking at logs independent of alerts has arguably implemented monitoring without implementing review. Whether that’s sufficient is genuinely unsettled: some teams treat well-tuned automated detection as functionally equivalent to review, on the reasoning that a human looking at logs nobody flagged is a poor use of time compared to a system that flags the right things. Others treat periodic human review as a distinct, necessary check, because automated systems only catch the anomaly patterns someone thought to configure, and miss the ones nobody anticipated.

What “appropriate” logs means in volume and retention. Logging every field access on every request generates enormous volume and cost at scale; logging only login events generates almost no useful signal for detecting misuse after authentication. Where organisations draw that line, what gets logged versus what’s considered too granular or too expensive to capture, is a genuine engineering trade-off the clause doesn’t resolve.

Passive collection versus active process. A company that ships logs to a storage bucket and never looks at them unless subpoenaed has, technically, produced “logs.” A company running an active detection and review process has done something categorically different. Both can point to the same clause language. Only one of them would actually catch unauthorised access in time to matter, which is the entire stated purpose of the clause.

What the Breakdown Really Means

The clause’s own language, “for enabling detection... investigation and remediation,” is the test. If your logging setup couldn’t have plausibly caught an actual unauthorised access event before someone else told you about it, the letter of the clause may be technically met, but its purpose almost certainly isn’t.

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