Designing Audit Logging That Actually Satisfies a Data Protection Board Inquiry

A Data Protection Board inquiry into a complaint or a breach is not going to ask for your application logs in the generic sense; it is going to ask specific reconstructive questions — who accessed this individual's data, on what date, for what stated purpose, and under what consent status at that time. Most application logging, built for debugging and performance monitoring, cannot answer these questions cleanly because it was never designed to track access to specific personal data at the level of an individual data subject.

Audit logging for this purpose is a distinct concern from operational logging, even though the two often get conflated into the same logging pipeline. Operational logs answer 'is the system working'; audit logs need to answer 'who touched this person's data and why,' and conflating the two tends to produce a pipeline that is noisy for audit purposes and incomplete for genuine audit questions.

A useful audit log entry captures, at minimum: the acting identity (which user or service account), the action taken (read, modify, export, delete), the specific data subject or record affected, the purpose or context under which the action was taken if the system tracks purpose, and a precise timestamp. Logging 'user table accessed' without identifying which specific records were touched is close to useless for an inquiry that is asking about one individual's data specifically.

Correlation IDs matter as much as the individual fields, because a single user action in a modern application typically touches multiple services, and an inquiry reconstructing a data access event needs to trace it across all of them, not just the one service that happened to log clearly. Propagate a single correlation ID through the request chain and tag every audit log entry generated from that request with it, so a reconstruction can pull the full picture rather than fragments from unrelated services.

In a microservices architecture, audit-relevant events are generated across many independent services, and centralizing them into a single searchable store is necessary for an inquiry to be answerable in a reasonable timeframe rather than requiring someone to manually query a dozen separate systems. This centralization needs to preserve the original fidelity of each event — do not summarize or aggregate audit logs on the way into the central store, since a summarized log that lost the individual-record detail defeats the purpose.

Access to the centralized audit log store itself needs to be tightly controlled and, ideally, logged in turn, since an audit log that anyone can quietly edit is not credible evidence in an inquiry. Treat the audit log store as a higher sensitivity tier than most of the operational data it describes.

Write-once storage or append-only log structures, where entries cannot be modified or deleted after being written, give an audit log real credibility during an inquiry, because a mutable log is always open to the question of whether it reflects what actually happened. Cryptographic chaining of log entries, where each entry includes a hash of the previous one, is a stronger version of the same idea and makes any retroactive tampering detectable even if someone did gain write access.

Retention needs to be long enough to cover realistic inquiry timelines, which can look back well past the DPDP Rules' one-year security log baseline depending on when a complaint is raised relative to the underlying event. Treat that one-year figure as a floor for security-relevant logs specifically, not as the retention period for every category of audit log, and set retention deliberately based on how far back an inquiry might reasonably need to look for the specific systems in question.

The Evidence Tracker tool on this site is built to help organize exactly this kind of auditable record over time, complementing the technical audit log with a structured internal trail of decisions and actions taken.