Access logs for personal data: recording who read which record

What it is

An access log for personal data records reads, not only writes: which principal (a staff user, a service, a support tool, an export job) read which subject's record, when, through which path, and for what stated reason. It complements the audit log of state changes. Two layers can produce it. At the application layer, the handler that loads a customer record emits an event carrying the subject identifier. At the database layer, an extension such as pgAudit logs statements; its README states that object audit logging logs statements that affect a particular relation and supports SELECT, INSERT, UPDATE and DELETE, configured through a role granted privileges on the relations to watch. NIST SP 800-92 covers the surrounding discipline; its abstract describes guidance on establishing log management infrastructures and on log management processes, which is where storage, protection and analysis of the access log itself belong.

Why it matters

The questions this log must answer are subject-centric: "who looked at this person's data in the last year?" and "did anyone read records outside their own case load?" Neither is answerable from request logs keyed by URL. Misuse of internal tools by authorised staff is a commonly reported class of incident that only a read log can detect.

How to apply

• Log at the application read path with a fixed schema: actor, actor_type, subject_id, object, action, reason, request_id, at. Bulk reads log the query and the row count, not every row.
• Make the reason a required field on internal tools: a ticket number or a picklist entry, since free text is hard to analyse later.
• Index by subject and by actor; build the two standard reports (per subject over time, per actor against expected case load) before the first incident, not during it.
• Use database-level logging for paths that bypass the application (ad hoc SQL, migrations, analysts) and reconcile it with the application log; a read without a matching application event is a finding.
• Keep the access log itself under strict access and its own retention: it is personal data about both the actor and the subject.
• Alert on patterns: one actor reading many subjects in a short window, reads of flagged records, reads outside working hours for roles that have none.

Pitfalls

Logging every list view creates volume without information; scope to detail views and exports. A cache hit never reaches the handler, so log at the read API, not at the database call. An access log that support staff can browse reveals which colleagues are under review. Database-level statement logging can capture parameter values, which puts personal data into the log; in pgAudit the pgaudit.log_parameter setting controls whether the parameters passed with a statement are included.

Bulk reads and exports

A list view that renders fifty customers is a read of fifty subjects, and an export is a read of every subject in it; the subject-centric question cannot be answered from a query text and a count, because the query cannot be re-run later against the data as it was. Log the subject identifiers actually rendered: a list view has a page size, so the array is small. For an export, store the manifest of subject identifiers (or a hash list) with the export job and reference it from the access-log event. Only aggregate reports, whose rows carry no subject identifier, are logged as query plus count. The pgaudit.log_relation setting adds one line per relation touched, which is enough for the reconciliation with the database log but not a substitute for the identifiers.