Technical Whitepaper

Audit Engine Architecture

Audital's cryptographic audit chain is designed so that tampering with any historical record is mathematically detectable — immediately and independently. This document describes the five layers of that guarantee.

01

Immutability Layer — SHA-256 Hash Chain

Every audit event is hashed with SHA-256 and chained to the hash of the immediately preceding event. The chain begins at a genesis event when each organisation's audit ledger is initialised. Any retroactive alteration of any event changes its hash, which breaks every subsequent link in the chain.

Chain Formula

H(n) = SHA-256( H(n-1) ‖ event_id ‖ event_type ‖ payload_hash ‖ timestamp )

Where ‖ denotes concatenation and H(0) is the organisation genesis hash.

Audit Event Structure

{
  "id":              "evt_01HX...",
  "organisationId":  "org_01GZ...",
  "eventType":       "MODEL_DEPLOYED",
  "actorEmail":      "jane.smith@firm.co.uk",
  "payloadHash":     "sha256:3a1f...",
  "chainHash":       "sha256:9c2e...",
  "previousEventHash": "sha256:b4d1...",
  "complianceFrameworks": ["FCA_SS1_23", "EU_AI_ACT"],
  "rfcTimestamp":    "2026-03-01T09:14:32Z",
  "rfcTimestampToken": "<base64-encoded DER token>",
  "createdAt":       "2026-03-01T09:14:33.104Z"
}
02

RFC 3161 Trusted Timestamping

Hash chain integrity alone proves that events have not been reordered or altered since the chain was formed — but it does not prove when a given event occurred. RFC 3161 timestamping solves this.

For each audit event, Audital sends the event's payload hash to the DigiCert Timestamping Authority (TSA). The TSA returns a signed timestamp token — a cryptographic receipt that binds the hash to a specific point in time under a trusted certificate authority. This token is stored alongside the event record.

What This Means for Regulators

  • ✓An event timestamped at 09:14:32 on 1 March 2026 carries a cryptographically verifiable proof that the data existed at that exact time.
  • ✓The timestamp cannot be backdated or fabricated — it is signed by DigiCert's root CA, which is independently trusted.
  • ✓Regulators can verify the timestamp token independently using any RFC 3161-compliant verification tool.
  • ✓Audital provides the raw DER-encoded token in the evidence package so verification requires no dependency on Audital's infrastructure.
03

AES-256-GCM Encryption with HKDF Key Derivation

All audit payloads and integration credentials are encrypted using AES-256-GCM before storage. The cipher provides both confidentiality (the ciphertext reveals nothing about the plaintext) and authenticity (any tampering with the ciphertext is detected on decryption).

Encryption keys are never stored alongside encrypted data. Instead, per-organisation keys are derived on demand using HKDF (HMAC-based Key Derivation Function) from a master key held in a secrets manager. The derivation binds the key to the organisation ID, ensuring that a key derived for one organisation cannot decrypt data from another.

Key Derivation

org_key = HKDF-SHA-256( master_key, salt=org_id, info="audital-v1", len=32 )

A 256-bit key unique to each organisation, derived without storing the key itself.

04

Append-Only Audit Ledger

The audit ledger is enforced as append-only at three independent layers. No single layer failure can enable retroactive modification.

Application Layer

The API contains no UPDATE or DELETE routes for audit events. All write operations go through a single append function that enforces the chain hash calculation before insertion.

Database Layer

PostgreSQL row-level security policies deny UPDATE and DELETE on audit event tables for the application user role. A separate privileged role exists only for schema migrations and is not used by the application at runtime.

Object Storage Layer

Evidence packages and RFC 3161 timestamp tokens are written to object storage with immutability locks enabled. Once written, objects cannot be overwritten or deleted for the configured retention period.

05

Tenant Isolation — Per-Organisation Key Derivation

Each organisation's audit data is encrypted with a key derived specifically for that organisation. This means that even in the event of a partial infrastructure breach, an attacker who obtains encrypted data from one organisation cannot use it to access another organisation's records.

All API queries are scoped to the authenticated user's organisation ID at the data access layer. Cross-organisation data access is structurally impossible at the query level — there is no route in the API that returns data from a different organisation than the one the authenticated user belongs to.

Tenant Isolation Properties

  • —Separate HKDF-derived 256-bit key per organisation
  • —All database queries include organisationId filter enforced in middleware
  • —Encryption keys never co-located with ciphertext
  • —Organisation ID bound into key derivation — cross-tenant decryption structurally impossible
  • —Session tokens scoped to organisation at issuance — cannot be used cross-tenant

Security Documentation

Request the full security pack

The security architecture document, data processing agreement, sub-processor list, and penetration testing summary are available to procurement teams before any contract is signed.

Request Documentation →