Boardroom Answers · Security & Compliance · Compliance, Regulatory & Legal
Decision Audit Trail: Producing Full History for a Regulator
The question a Chief Compliance Officer (CCO) asks: “If a regulator or opposing counsel demands the complete history of a decision made on your platform two years from now, what can you actually produce — and can anyone have edited it?”
The short answer
Every action is in an append-only, hash-chained ledger — editing history breaks the math visibly. AI outputs carry model-and-source provenance, and privacy scrubbing pseudonymises without breaking the chain.
The full executive answer
We can produce the full chain, and no — not even we can silently edit it. Every material action on the platform — who ran an assessment, what data went in, what the AI produced, who viewed it, who exported it, every permission change — is written to a dedicated audit log that is append-only by construction: at the database level there are no update or delete permissions on that table, and writes go through one controlled function. Each entry is cryptographically hash-chained to the previous one, like a ledger — altering or removing any historical row breaks the chain visibly. That transforms "trust us, the log is accurate" into "verify it yourself mathematically."
For AI outputs specifically — the thing opposing counsel would actually target — we retain provenance: which model and version generated an insight, what the inputs were, and our numeric-provenance system requires every figure in generated prose to trace to a licensed source. The product also includes a regulator-facing evidence vault that assembles immutable, hash-verified evidence packs per jurisdiction, where completeness is computed rather than asserted and gaps render as explicit gap entries — it structurally cannot pretend to be complete, which is precisely the property you want in front of a regulator.
On retention and eDiscovery mechanics: tenant business data and the audit log are classified "retain" in our declarative retention policy — never auto-pruned; deletion happens only through the explicit, logged GDPR erasure path. And where privacy law forces us to remove personal data from old audit entries, we pseudonymise the identifying fields while preserving the row and its hashes, so the chain — and your evidentiary continuity — survives the privacy obligation. The honest caveat: we're pre-launch, so no log has yet been tested in actual litigation, and formal legal-hold tooling (freeze-on-demand workflows for named custodians) is roadmap, not shipped — today a hold would be operated manually with our support.
Grounded in: SOC 2 TSC CC7.2/CC4.1 (audit evidence); NIST SP 800-53 AU-9 (protection of audit information); GDPR Art. 5(1)(e) (storage limitation) reconciled via pseudonymisation.
The natural next questions
Related governed answers
- You keep saying your controls live in code. What does that actually mean — how would my compliance team verify a control is operating?
- Enumerate every third party that touches my data. Vendors always forget two — don't be that vendor.?
- Do you have SOC 2 or ISO 27001? If not, you understand my procurement team will stop reading right there.?
Want this answered live, on your data?