Three Things Access Logs Are Not
Before getting into what Rule 6 requires, three common confusions are worth clearing.
Access logs are not the same as consent logs. Consent logs record what a Data Principal agreed to, when, under which notice version, and for which purpose. For registered Consent Managers, the framework imposes specific obligations around immutability and retention. Access logs are a different instrument entirely.
Access logs are not a data retention policy. Data retention governs how long personal data itself is held. Access logs track who accessed the platform that holds that data. These are separate obligations with separate governance requirements.
Access logs are not narrowly limited to moments when personal data was viewed or returned. This is the most common misread of Rule 6, and it significantly understates what the obligation covers.
What Rule 6 Actually Requires: Platform-Level Access
Rule 6 mandates that Data Fiduciaries maintain logs of access to the platform, not just to the personal data records within it. That distinction matters considerably in practice.
Platform-level logging means capturing every interaction with the system: authentication events (successful and failed), API calls whether or not they returned personal data, administrative actions, configuration changes, export requests, and failed access attempts. A query that returned zero results still needs to be logged. A login that was rejected still needs to be logged. An admin who opened a configuration panel and made no changes still needs to be logged.
Why? Because the compliance question is not only "who saw personal data." It is "who had access to the system, when, and what did they attempt to do." That is the audit trail the DPBI needs to reconstruct a timeline after an incident.
A compliant access log entry answers four questions about every platform interaction:
- Who: the identity of the actor, a specific user account, a service account, a vendor's system, an API key
- How: the method of access, API call, application interface, direct database connection, admin console
- What: the action attempted and its outcome, query, export, configuration change, login, deletion request, and whether it succeeded or failed
- When: a precise, tamper-evident timestamp
The API vs. Direct Database Access Problem
The "how" field is where most platform logging implementations have a critical gap.
An API call from your application layer enters the platform through a controlled, authorised surface. Every call is logged by design, authorisation is enforced at the gateway, and the scope of what can be accessed is constrained by the API's design. This is the correct default.
A direct database connection, a developer connecting to the production database using a database client, a DBA running an ad hoc query, a support team with raw SQL access, bypasses all of that. It often bypasses the application's logging entirely. The platform is being accessed, but not through any surface that your Rule 6 logging covers.
This means your access log has a blind spot. Platform access that happens outside your API layer is invisible in your compliance record. Direct database access to production should be treated as a break-glass operation: requiring advance approval, executed only with justified purpose, logged through a separate privileged access management layer, and reviewed after the fact. It should not be a standing credential that any technical staff member can use at will.
Failed Access Attempts Are Platform Access Too
An often-overlooked dimension of platform-level logging: access attempts that fail are as important to log as those that succeed.
A series of failed login attempts, a pattern of API calls returning 403 errors, or a repeated query returning no results, these are the signals a DPBI investigation or a breach forensics exercise will look for. They can indicate an attempted unauthorised access, a misconfigured integration, or an insider probing for data they should not reach.
If your logging only captures successful platform interactions, you are missing the events most likely to be relevant in a compliance investigation.
The Third-Party Platform Access Gap
When a Data Processor's staff access your platform, a SaaS vendor's support engineers connecting to debug an issue, your cloud provider's infrastructure team performing maintenance, an outsourced analytics partner querying your data environment, that access is platform access within your Rule 6 scope.
Most vendor contracts do not currently require processors to provide logs of their own staff's access to your platform. Until that obligation is explicit in the contract, with a defined format and delivery mechanism, you have a Rule 6 exposure your internal logging infrastructure cannot close.
Periodic Review: The Control Above the Log
Rule 6's periodic review obligation applies to access logs as a live control, not a historical archive. A log that is generated and stored but never examined is not a compliance control. It is a false assurance.
Automated alerting on anomalous platform access patterns, access volumes inconsistent with normal operations, connections from unexpected systems, direct database access without a corresponding change management record, is the minimum viable review mechanism. What must accompany it is a documented response process: what happens when an alert fires, who owns the investigation, and how it is closed and recorded.
The platform access log is the evidence. The review and response process is the control. Rule 6 requires both.
The Bottom Line
Access logs under Rule 6 are about establishing an auditable record of every interaction with the platform that processes personal data, not just the moments when personal data was returned. The most significant gap in most organisations is not the logging infrastructure itself. It is the absence of API-only access controls that route all platform access through a logged, authorised surface, and the standing direct database credentials that create a blind spot Rule 6 was specifically designed to close.
Book a demo at truconsent.io/book-demo to see how truConsent structures platform access logging across consent and data operations.