Audit-as-evidence

The product’s design philosophy is that supervision must be evidenced. PS22/11 made this explicit at the regulatory level, shifting the obligation from “you should supervise” to “you must evidence supervision”. The product is built around the second formulation. Every supervisory action is recorded, attributed, time-stamped, and retrievable. Every change to a record is captured in a tamper-evident chain.

This page is about the audit log as the spine of regulatory evidence.

Design-by-evidence

The principle: if a supervisory act has happened but the record of it cannot be reconstructed, the principal cannot defend it. Conversely, if every act is recorded with sufficient context, the principal’s defence position is reconstructible from the data alone.

Three design rules follow:

1. No silent state changes. Every state transition that has supervisory significance emits an AuditEvent. Reading a record is not audited; changing one always is. State transitions include creating, editing, signing off, withdrawing, escalating, notifying, and deleting (soft-delete only; see SYSC 9).
2. Attribution is mandatory. Every event carries actorUserId and actorRole. System-initiated events carry actorUserId: null and a system role tag, but the upstream cause is captured in the event metadata.
3. Tamper evidence at the chain level. The audit log is a hash chain, so any retroactive edit to an earlier event invalidates every subsequent hash and is detectable on verification.

The AuditEvent shape

Every supervisory action emits a single event with the following fields:

export interface AuditEvent {
  id: Ulid; tenantId: Ulid; at: IsoTimestamp;
  actorUserId: Ulid | null; actorRole: Role;
  action: string;                       // e.g. "breach.notify-fca"
  subjectType: "ar" | "breach" | "review" | "annual-review" | "mi-return" | "tenant" | "user";
  subjectId: Ulid;
  ip: string | null; userAgent: string | null;
  prevHash: string;                     // SHA-256 of prior event for tamper evidence
  hash: string;
}

The action string is namespaced. Examples from the live action catalogue:

• ar.create, ar.suspend, ar.terminate, ar.permission-grant, ar.permission-revoke
• breach.create, breach.severity-update, breach.assign, breach.notify-fca, breach.resolve
• review.schedule, review.start, review.finding-add, review.complete, review.challenge
• annual-review.draft, annual-review.review, annual-review.director-sign-off, annual-review.challenge-reissue
• mi-return.draft, mi-return.submit, mi-return.query, mi-return.accept
• tenant.config-update, user.role-change, user.suspend

The action namespace is part of the regulatory contract. New surfaces extend it; existing actions are not renamed because doing so would break the historical audit trail.

The hash chain

The audit log is a hash chain. Each event’s hash is computed from a canonical serialisation of all the event’s other fields plus the previous event’s hash. The genesis event for each tenant has a fixed sentinel prevHash.

Properties of the chain:

• Adding an event is O(1) and only requires the previous event’s hash.
• Verifying the chain end-to-end is O(n) and recomputes hashes from genesis.
• Any retroactive edit to an earlier event changes its hash, which changes every subsequent event’s prevHash, which is detectable on verification.
• Insertion in the middle is detectable for the same reason.

The chain does not prevent a determined attacker with full database access from rewriting all events from the modified point forward. It does ensure that any such tampering is detectable to a regulator who has the latest hash recorded out-of-band (for example, in a periodic regulatory submission or an external timestamping service). The engineering spec covers external timestamping as a future enhancement.

Replayability for Section 166 reviews

Section 166 of FSMA empowers the FCA to require a “skilled person review” of a regulated firm. Section 166 reviews are common in the AR oversight context because the FCA can use them to test a principal’s supervision rigorously without bringing direct enforcement action.

A Section 166 reviewer typically needs to reconstruct:

• Why was this AR appointed despite indicators X, Y, Z.
• When did the principal first become aware of issue A, and how long until the FCA was notified.
• What evidence supports the principal’s view that AR B’s risk band is “moderate” rather than “elevated”.
• What changed in the supervisory programme after event C.

The audit log supports each of these reconstructions directly. Every record state at any point in time is reconstructible by replaying events up to that timestamp. The product’s reporting layer exposes a “replay to point in time” query that takes a tenant ID, a subject ID, and an at timestamp, and returns the state of the subject at that moment.

Replayability for regulator visits

Less formally, FCA supervisory visits to the principal often involve walking through specific cases. The product’s AR detail surface includes an audit timeline panel that renders the event sequence for the AR in human-readable form, with filters by event type and by date range. The same query that drives the panel produces the underlying event list for export to the FCA on request.

Cross-links

• SYSC 9 for the retention floor and the relationship to UK GDPR.
• Annual self-assessment for director sign-off as a distinct audit object.
• SUP 15 for the three timestamps on every breach, all of which emit audit events.