Rule 6 makes platform-level access logging a documented legal obligation, not an internal IT best practice — here's what that actually covers, and where most implementations leave a blind spot.
July 2026 · 5 min read
Rule 6 of the DPDP Rules 2025 turns access and modification logging into something Data Fiduciaries must keep as a matter of law, not something the security team maintains because it's good practice. That reframing matters more than it sounds like it should — because it changes what "adequate" logging actually means.
It helps to first separate access logs from two things they routinely get confused with.
They are not consent logs. A consent log records what a Data Principal agreed to, when, under which version of the notice, and for what purpose — and for a registered Consent Manager, that record carries its own immutability and retention rules. Access logs answer a different question entirely.
They are not your data retention policy either. Retention governs how long you hold personal data itself. Access logs govern who touched the system that holds it. Two obligations, two separate governance trails.
And they are not limited to the moments someone actually viewed or exported personal data. This is the misreading we see most often, and it quietly shrinks the scope of what organisations think they need to log.
Rule 6 asks for logs of access to the platform — the whole system, not just the personal-data fields within it. That's a wider net than most logging setups are built to catch.
Platform-level logging means capturing every interaction with the system: successful and failed logins, every API call regardless of whether it returned personal data, admin actions, configuration changes, exports, and attempts that were denied. A search that came back empty still gets logged. A login that was rejected still gets logged. An administrator who opened a settings screen and changed nothing still gets logged.
The reason is simple once you sit with it: the compliance question is not just "who saw personal data." It's "who had access to this system, when, and what were they trying to do." That's the timeline the Data Protection Board would need to reconstruct after an incident, and a log that only fires on successful data reads can't support it.
A log entry that actually satisfies Rule 6 needs to answer four things about every interaction with the platform:
The "how" field is where most organisations discover their logging isn't as complete as they assumed.
An API call routed through your application layer arrives through a controlled, authorised surface. It gets logged automatically, authorisation is checked at the gateway, and what it can touch is constrained by the API's own design. That's the model Rule 6 assumes as the default.
A direct database connection breaks that assumption. A developer connecting straight to production, a DBA running an ad hoc query, a support engineer with raw SQL access — none of that necessarily passes through the application layer that generates your logs. The platform is being accessed. Your Rule 6 log may never see it.
That's a real blind spot, and the fix isn't more logging code — it's a policy change. Direct database access to production should function as a break-glass action: pre-approved, justified, routed through a separate privileged-access layer that does log it, and reviewed afterward. It should never sit as a standing credential any engineer can reach for on a normal Tuesday.
One piece of platform logging gets skipped constantly: failed attempts. A run of failed logins, a burst of 403 responses on an API, a query that keeps returning nothing — these are exactly the signals a breach investigation or a Board inquiry goes looking for first. They can point to an attempted intrusion, a broken integration, or someone probing for data they shouldn't have.
If your logging only records what worked, you've built a record with a hole exactly where the interesting evidence would be.
When a processor's own staff reach into your platform — a SaaS vendor's support engineer debugging an issue, your cloud provider's infrastructure team doing maintenance, an outsourced analytics partner running queries — that's platform access within your Rule 6 obligation, even though it isn't your employee doing it.
Most vendor contracts today say nothing about handing over logs of the vendor's own staff accessing your platform. Until that's an explicit, specified clause — format and delivery included — you're carrying a Rule 6 exposure that no amount of internal logging infrastructure can close on its own.
Rule 6's periodic review requirement applies to access logs as a living check, not an archive you can point to if asked. Logs that get generated, stored, and never looked at are not evidence of compliance — they're a false sense of one.
The minimum viable version of this is automated alerting on anomalous patterns: volumes that don't match normal operations, connections from systems you don't recognise, direct database access with no corresponding change ticket. Alerting alone isn't enough, though — you need a documented response process behind it: who owns the investigation when an alert fires, and how it gets closed and recorded.
The log is the evidence. The review process is the control. Rule 6 asks for both, not either.
Rule 6's access-log requirement is really about building an auditable record of every interaction with the platform that touches personal data — not just the moments personal data actually got returned. The biggest gap we see isn't the logging tooling itself. It's the absence of API-only access enforcement, and the standing direct-database credentials that leave exactly the blind spot Rule 6 was written to close.
Verifying your current access-logging setup actually meets this bar is exactly what our security posture assessment checks.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation