Design audit trails that expose tampering without exposing people

An audit trail can show that a record changed after it was written. It cannot, by that fact alone, prove that the original record accurately described a person’s action.

That distinction matters when a system records consent, access or deletion. Integrity controls protect the history that was captured. Reliable capture, meaningful event definitions and appropriate authorisation are separate requirements.

A good design gives reviewers enough evidence to assess all of them without placing customer payloads in every event.

Decide what alteration must be detectable

Consider a hypothetical privacy request service. Operators can correct case details, administrators maintain the application and a reviewer investigates disputed closures.

The threat model should ask whether someone could edit an event, remove selected events, reorder the sequence or disable logging while continuing to process cases. Different controls address different possibilities.

OWASP’s Logging Cheat Sheet recommends protecting logs against unauthorised access, modification and deletion, and detecting interrupted logging or tampering. It also recognises that logs themselves can contain sensitive information.

An append-only interface may prevent routine application edits, but it does not automatically constrain a database administrator or a compromised infrastructure account. Define which actor each control is intended to restrict.

Separate capture, storage and review

The application should emit clear events for significant decisions. The logging path should preserve them with suitable integrity controls. The review interface should expose the evidence needed for a particular investigation.

Giving the same account unrestricted control over all three stages weakens independent assessment. Where the risk warrants it, separate operational administration from log administration and review access.

A restricted copy or independently controlled destination can help preserve evidence if the primary system is altered. Its access, retention and operational monitoring still need design. Copying logs to another location without protecting that destination merely creates another exposure.

Keep failure handling explicit. If events cannot be recorded, decide which actions may proceed, which should pause and how the gap will be reported. A silent failure makes a complete-looking timeline misleading.

Use integrity mechanisms for a stated purpose

Hashes, signatures or linked event structures can support alteration detection when implemented and managed correctly. Their value depends on what is protected, where verification material is held and whether an attacker can rewrite both the records and the expected evidence.

Do not invent a custom cryptographic scheme for a blog diagram or a pilot shortcut. Use established components and review the design against the actual threat model.

An integrity check should produce an understandable result: which records were verified, against what evidence, at what time and with which unresolved gaps. “Blockchain-backed” or “immutable” is not a substitute for those answers.

Even a perfectly preserved event may record an incorrect claim. If the application writes “deletion complete” before a processor has confirmed its action, integrity protection preserves that premature statement. It does not make it true.

Minimise the content that must be preserved

For the request service, an event may need a case reference, actor, action, affected system, decision, timestamp and outcome. It usually does not need the customer’s full request text or identity evidence.

Use controlled references to supporting material. Limit who can resolve those references, and avoid embedding direct identifiers in event names or resource paths.

OpenTelemetry’s sensitive-data guidance supports minimisation and controlled transformation of telemetry. Apply those principles before data reaches a long-lived audit store where removal may be operationally difficult.

Under the DPDP Act’s definition of personal data, a pseudonymous reference can still be personal data when it relates to an identifiable individual. Restrict access and retention accordingly. Integrity is not a reason to preserve every detail indefinitely.

Rehearse an investigation

Create a synthetic case, record its normal events and then simulate a permitted correction, a missing event and an unauthorised modification attempt in the test environment.

Ask the reviewer to explain:

• Which event sequence is supported by the available evidence?
• Which alteration attempts were prevented or detected?
• Which gaps remain visible?
• Who could change the records or the verification evidence?
• What personal data was necessary to conduct the review?
• Does a completion event correspond to a confirmed operational outcome?

This exercise tests whether the audit trail helps a person reason about the case. It also exposes exaggerated labels. A defensible claim describes the alterations the design can detect and the limits of the evidence, while keeping the original event’s truth open to appropriate scrutiny.