Audit Trail vs Evidence: What Privacy Review Actually Needs

"Just check the logs" is the answer people give when they have no evidence. But a reviewer does not want to grep logs, and your logs were not written to answer their question. There are three different things here—server logs, an audit trail, and evidence—and treating them as the same is how "we can show what happened" falls apart in practice.

The three layers

Server logs are the debug output of your application: request lines, errors, stack traces, cache misses. They are voluminous, noisy, and shaped for engineers debugging incidents, not for proving a process. Nobody hands an auditor a folder of production logs.

An audit trail is an event timeline of actions: who did what, in what order, on what record. It is structured—"operator verified case 104, then started deletion"—and it is the raw material for review. It lives in your system and answers "what happened here?"

Evidence is a portable package assembled from that trail for a specific outcome: a consent publish or a deletion case. It contains the facts, the steps, and the outcomes in a form you can export and hand to someone. It is the deliverable; the trail is the source.

| Layer | Purpose | Shape | |-------|---------|-------| | Server logs | Debugging | Raw, noisy, voluminous | | Audit trail | Reconstruct events | Structured timeline in the system | | Evidence | Prove an outcome | Exportable package for a case |

What a reviewer actually asks

A reviewer—internal, customer, or regulator—asks a small set of questions:

• Was a request received and verified before anything was done?
• Which systems were acted on, and what was the outcome in each?
• Did anything fail, and was that recorded?
• Can I take this with me, as a file, and check it?

Notice what is missing: nobody asks for your logs. They ask for the record. The record only exists if you deliberately built the steps and outcomes into it.

The two traps

Trap one: logs are not a record. Even with perfect logging, reconstructing "what happened to user 42" from request logs is archaeology. Logs rotate, are filtered by level, and do not connect a user's deletion across ten systems in one view.

Trap two: an audit trail is not automatically evidence. A timeline inside your console proves events happened, but it is not portable, not filtered to the relevant facts, and not a file a reviewer can hold. Evidence requires a deliberate assembly step: pick the case, gather the facts and steps, and export.

What honest evidence includes

A defensible evidence package contains the facts of the case and the outcomes, including the failures. The presence of a failed connector step is not a flaw in the evidence—it is the evidence. An honest "failed here" is more trustworthy than a clean-looking package that hides it.

What honest evidence is not: a cryptographically sealed legal archive, a compliance score, or a guarantee. Those are marketing claims. A reviewer can check a real record; they can only be impressed by a seal.

How Erasure separates the layers

Erasure keeps Activity and Evidence as distinct things. Activity is the in-console event timeline—who did what, in order. Evidence is a portable package assembled from that timeline for a consent publish or a deletion case, exportable as JSON, CSV, or a readable report. The evidence documentation is explicit about the limits: it covers Erasure-mediated actions, is not a legal seal, and is not a substitute for counsel.

The consent receipts post covers the consent side of proof, and the privacy evidence hub collects the related material.