Tamper-Evident Audit Trail

Overview#

In high-assurance environments where audit logs may face regulatory challenge or forensic dispute, organisations need to prove not just that an event was recorded, but that the record has never been modified since creation. The Tamper-Evident Audit Trail provides exactly that proof through cryptographic hash chaining, where each audit event is sealed to the previous event via SHA-256 digest, creating an append-only chain that makes any modification or deletion immediately detectable.

Regulatory and assurance frameworks increasingly mandate tamper-evident log integrity, including OWASP ASVS V16.2.1 and the audit-integrity expectations of European defence and security programmes such as the European Defence Fund (EDF) and PESCO. This capability closes that requirement for organisations subject to EDF funding, SOC 2, ISO 27001 audits, or evidentiary standards that require cryptographic proof of record integrity.

Key Features#

Hash-Chained Integrity: Every event record is sealed via SHA-256 over its predecessor's hash, creating a cryptographic chain where any modification or deletion breaks all downstream digests and is immediately detectable.
Append-Only Enforcement: PostgreSQL triggers block UPDATE, DELETE, and TRUNCATE operations on the audit table regardless of caller privilege. Rows can only be appended, never altered or erased.
Canonical Field Ordering: Audit events are canonicalised to a fixed byte sequence (timestamp, actor, action, resource, IP, user agent, classification, payload) ensuring that the Python chain verifier and the PostgreSQL trigger compute identical digests.
Periodic Verification: A scheduled job runs hourly to walk the entire audit chain, recompute every row's digest, and emit WARN-level alerts to your security operations dashboard and SIEM when any mismatch is detected.
Genesis Anchor: The first audit row begins with a zero-byte genesis hash (32 zero bytes), creating a cryptographic anchor point against which all downstream events can be validated.
Export and Audit Evidence: The audit chain can be exported in its full cryptographic form for external auditors, enabling independent verification of integrity without re-running your production database.

Use Cases#

Compliance Audits: Demonstrate to regulators (EDF, PESCO, SOC 2 auditors) that your audit logs are tamper-proof and meet evidentiary integrity standards.
Forensic Incident Investigation: When a breach occurs, export the audit chain to prove that no logs were modified in the cover-up, providing admissible evidence for legal or regulatory proceedings.
High-Assurance Certification: Meet ASVS V16.2.1 / V16.3.1 requirements for cryptographic log integrity, enabling certification programs that depend on tamper-evident records.
Supply Chain Assurance: Government and defence contractors verify that log integrity was maintained throughout the audit period, supporting contract compliance and security assessment.

Integration#

Applications emit events through a single audit-emit call, which accepts actor ID, action, resource identifiers, IP address, user agent, classification level, and a JSON payload. The platform writes the event to an append-only audit store, where each new row is sealed with the previous row's hash and a freshly computed SHA-256 digest of the canonical record. The application receives the row ID and sealed hash back for logging or further reference.

Auditors validate integrity by running the chain verifier against a copy of the audit table, recomputing each row's digest and checking that every record's stored previous-hash links to the prior row's sealed hash. Any mismatch indicates tampering and triggers a high-priority incident response. The verifier is read-only by design, never modifying production logs.

Open Standards#

FIPS 180-4 (SHA-256): Every audit event is sealed using a SHA-256 digest over a canonicalised byte sequence, and the genesis anchor and chain-verification logic both depend on the collision-resistance properties defined in this standard.
OWASP Application Security Verification Standard (ASVS) V16: The capability is explicitly designed to satisfy ASVS V16.2.1 and V16.3.1, which mandate cryptographic tamper-evidence and append-only enforcement for audit logs in high-assurance applications.
ArcSight Common Event Format (CEF): The SIEM export service encodes audit events as well-formed CEF log lines (header format CEF:0, severity scale 0, 10, standard extension keys) for ingestion by Splunk, Elastic, Microsoft Sentinel, and IBM QRadar.
ISO/IEC 27001: The cryptographic chain and periodic verification job provide the immutability and integrity controls required as evidence artefacts during Information Security Management System audits against this standard.
NENA i3 / NG911: The platform's NG911 workstreams record state-changing operations using the NENA i3 action vocabulary (I3_CALL_INGRESS, I3_SIPREC_START, I3_ADR_QUERY, and others) directly into the tamper-evident audit store, satisfying i3 admissibility requirements.
JSON (RFC 8259): Audit event payloads, before/after state snapshots, and chain exports are all serialised as standards-compliant JSON, enabling independent verification tooling to consume and recompute digests without proprietary parsers.
SOC 2 (AICPA Trust Services Criteria): The append-only table enforcement, hourly chain verifier, and cryptographic export together satisfy the availability and processing-integrity trust service criteria required for SOC 2 Type II audit engagements.

Security & Compliance#

Cryptographic Proof: SHA-256 hash chaining makes tampering detectable with cryptographic certainty (collision resistance: 2^128 attempts).
ASVS V16.2.1 / V16.3.1 Compliance: Meets the Application Security Verification Standard requirements for tamper-evident audit logs.
Defence-grade audit integrity: Satisfies European Defence Fund and PESCO expectations for tamper-evident audit-log integrity.
ISO 27001 Evidence: Provides the evidentiary integrity control required for information security management system audits.
SOC 2 Type II: Demonstrates audit trail immutability and integrity verification, supporting SOC 2 control requirements.
INSERT-Only Role: The application role holding audit table access receives only INSERT and SELECT grants, preventing any possible mutation even if the role is compromised.

Availability#

Enterprise Plan: Included
Professional Plan: Included

Last Reviewed: 2026-05-14 Last Updated: 2026-05-14