Keep the audit trail in write-once storage, separate from the application database
Context
GxP requires an audit trail that nobody can change. Today the audit rows sit in the same database the application writes to, so anyone with write access to the application can also change its history.
Options considered
- 1Audit table in the same database · RejectedCheapest to build, but a compromised application can still rewrite it.
- 2Write-once object storage with a retention lock · ChosenEvents are appended and cannot be changed or deleted before the retention period ends, even by an administrator.
- 3A third-party audit service · RejectedMeets the requirement, but the data-residency review would delay go-live by a quarter.
Consequences
- Benefit: The audit trail survives a compromise of the application.
- Benefit: Inspectors read one store, with one retention rule.
- Cost: Two stores to back up and monitor, and reports move to a separate read model.

