Episode 42 · Module 9 · Audit & Logging

Hash-Chained Immutable Logs

19 May 2026 · 8:49 · Security for Legal SaaS

8:49 8:49

In Episode 41, we designed audit logs that capture who did what, when, and to which resource. This episode adds the critical property that makes those logs trustworthy: tamper evidence. Specifically, we'll implement hash chains — a technique where each log entry is mathematically linked to every entry before it, so that modifying any single entry breaks a chain that is trivially detectable. A hash chain gives you a guarantee that append-only storage alone cannot: not just that entries should not be modified, but that if they were modified, you would know.

Today’s Lesson

Security for Legal SaaS — Episode 42: Hash-Chained Immutable Logs

If Someone Can Edit the Audit Log, You Don't Have an Audit Log

A hash chain gives you a guarantee that append-only storage alone cannot: not just that entries should not be modified, but that if they were modified, you would know.

Hash Functions: A Quick Primer

A hash function — which we first covered in Episode 17 in the context of password storage — is a one-way mathematical transformation that takes an input of any size and produces a fixed-length output (the "hash" or "digest"). Two properties matter here:¹

Deterministic: The same input always produces the same hash
Collision-resistant: It is computationally infeasible to find two different inputs that produce the same hash

SHA-256 (Secure Hash Algorithm, 256-bit) is the standard choice for audit log chains. It produces a 64-character hexadecimal string from any input. Change a single character in the input, and the output changes completely and unpredictably.²

How Hash Chains Work

The principle is straightforward: each log entry's hash includes the hash of the previous entry.

Entry	Data	Previous Hash	This Entry's Hash
Entry 0	`"System initialised"`	`(none — genesis entry)`	`SHA-256("System initialised" + "0000...")` = `a3f2...`
Entry 1	`"sarah.chen viewed doc-001"`	`a3f2...`	`SHA-256("sarah.chen viewed doc-001" + "a3f2...")` = `b7c1...`
Entry 2	`"james.wong approved filing"`	`b7c1...`	`SHA-256("james.wong approved filing" + "b7c1...")` = `d4e8...`
Entry 3	`"system.ai classified doc-002"`	`d4e8...`	`SHA-256("system.ai classified doc-002" + "d4e8...")` = `f1a9...`

If someone modifies Entry 1 — changing "sarah.chen" to "john.doe" to cover tracks — the hash of Entry 1 changes. But Entry 2's hash was computed using Entry 1's original hash. Now Entry 2's stored hash doesn't match what you'd get by recomputing it. The chain is broken. To hide the tampering, the attacker would need to recompute the hash of every subsequent entry — and if anyone has a copy of any later hash (a checkpoint, an external witness), the fraud is detectable.³

You've seen this before. Git — the version control system — uses exactly the same mechanism. Every commit's hash includes the hash of the parent commit. If anyone modifies a historical commit, every subsequent commit hash changes, and the tampering is immediately visible. Certificate transparency logs use the same principle. So do blockchains — though our use case requires none of the decentralisation overhead.

Implementation: Blockchain-Lite Without the Blockchain

Hash-chained audit logs provide the tamper-evidence property of a blockchain without the consensus mechanism, cryptocurrency, or distributed infrastructure. This is sometimes called "blockchain-lite" — you get the mathematical integrity guarantee without the operational complexity.⁴

A Minimal Implementation

Each audit log entry includes:

json

{
  "sequence": 42,
  "timestamp": "2026-05-18T14:23:07.442Z",
  "event_type": "document.classify",
  "actor": "sarah.chen@firm.com",
  "resource": "doc-a3f2c1",
  "outcome": "success",
  "previous_hash": "b7c1e3d4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2",
  "entry_hash": "d4e8f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0"
}

The `entry_hash` is computed as: `SHA-256(sequence + timestamp + event_type + actor + resource + outcome + previous_hash)`. Every field that matters for the audit record is included in the hash computation. Changing any field changes the hash.⁵

Verification

To verify log integrity, you recompute the hash chain from the beginning (or from a trusted checkpoint):

Start at the genesis entry (or the last verified checkpoint)
For each entry, compute `SHA-256` of its fields plus the previous entry's hash
Compare the computed hash to the stored `entry_hash`
If any computed hash doesn't match the stored hash, that entry or a prior entry has been tampered with

This verification can run as a scheduled job — daily, hourly, or continuously — and should trigger an immediate alert if integrity breaks.⁶

Tamper Evidence: What Can and Cannot Be Detected

Scenario	Detectable?	How
Entry modified	Yes	Hash chain breaks at the modified entry
Entry deleted	Yes	Sequence gap; or chain breaks if entries are re-numbered
Entry inserted	Yes	Subsequent hashes no longer match (the chain moved)
Entries appended (normal)	N/A	This is expected behaviour
All entries recomputed by an attacker	Only with external witness	If no external checkpoint exists, a full rewrite could go undetected

The "full rewrite" scenario is the weakness of a single-system hash chain. If the attacker controls the log storage and can recompute the entire chain, they can produce a consistent but fraudulent chain. The defence: external witnesses.

External Witnesses and Checkpoints

To protect against a full chain rewrite, periodically publish a checkpoint — the latest hash — to a location the log administrator cannot control:⁷

Witness Method	Description	Strength
Separate internal system	Write checkpoint hashes to a different server with different access controls	Protects against single-admin compromise
Cloud object storage (immutable)	Write checkpoints to S3 with object lock	Provider guarantees immutability
Public transparency log	Publish hashes to a Certificate Transparency-style log	Publicly verifiable; strongest guarantee
Email to external party	Automated daily email of the chain head hash to compliance officer's personal account	Simple; surprisingly effective
Print and sign	Monthly printout of checkpoint hashes, signed by the compliance officer	Physical evidence; useful for court

For most legal SaaS platforms, writing checkpoint hashes to a separate cloud storage account with object lock provides a practical balance of security and simplicity.

Practical Options

AWS QLDB (Quantum Ledger Database)

AWS QLDB is a purpose-built ledger database that provides an immutable, cryptographically verifiable transaction log. Every change to the database is tracked in an append-only journal, and QLDB uses SHA-256 hash chains internally to provide tamper evidence.⁸

Key characteristics:

Append-only journal: Data cannot be modified or deleted after being committed
Cryptographic verification: Built-in digest computation and verification API
SQL-like interface: Familiar query language (PartiQL) for reading data
Serverless: No infrastructure to manage

QLDB is particularly well-suited for audit logs because it handles the hash chain implementation internally — you write events, and QLDB provides the integrity guarantees automatically.

Note: AWS announced QLDB end-of-life for July 2025, directing customers to Amazon Aurora PostgreSQL with ledger tables or Amazon DynamoDB with provenance tracking. The underlying principles — append-only storage with cryptographic verification — remain the same regardless of the specific service.⁹

Custom Implementation with PostgreSQL

For teams that prefer not to depend on a proprietary service:

Create an append-only audit table (INSERT-only permissions for the application, no UPDATE/DELETE)
Compute and store the hash chain in application code
Store the table in a separate database with restricted administrative access
Run a verification job that recomputes and checks the chain
Publish checkpoint hashes to external storage

This approach gives you full control and avoids vendor lock-in, at the cost of implementing and maintaining the hash chain logic yourself.

Append-Only Databases

Several databases support append-only or immutable table modes:

PostgreSQL with restricted permissions and triggers that prevent UPDATE/DELETE
CockroachDB with change data capture for audit streams
ImmuDB — an open-source immutable database specifically designed for tamper-evident data storage¹⁰

When Immutability Matters Most

Not every log entry justifies the overhead of hash-chained immutability. Prioritise:

Event Category	Immutability Priority	Rationale
Privilege access events	Critical	Who accessed privileged data and when; discoverable in litigation
AI-generated legal documents	Critical	Provenance and approval chain for AI outputs (EP37, EP43)
Financial transactions	Critical	Billing, trust account movements, fee calculations
Authentication events	High	Login history is often subpoenaed in investigations
Document production/disclosure	Critical	What was produced to opposing counsel and when; irreversible
Configuration changes	High	Who changed security settings, access controls, or system behaviour
General document access	Medium	Important for compliance but lower litigation exposure

Combining With Episode 41 Design

The complete audit logging architecture:

Structured JSON entries with the six W's (EP41)
Append-only storage preventing modification or deletion (EP41)
Hash chain linking each entry to all previous entries (this episode)
External checkpoint witnesses protecting against full chain rewrites
Automated verification running continuously or on schedule
Access controls separating writers, readers, and administrators
Retention policy aligned with regulatory requirements (7+ years)

This architecture produces an audit trail that is structured, searchable, tamper-evident, and legally admissible — the foundation that every security control in this series depends on.

What's Next

Episode 43 moves to Provenance Chains for AI Outputs — tracking not just who did what, but which AI model generated a specific legal document, what data it relied on, and whether the same output could be reproduced. When a court asks "where did this analysis come from?", you'll have the answer.

Sources & Further Reading

Sources & references

DEV Community, Building a Tamper-Evident Audit Log with SHA-256 Hash Chains (Zero Dependencies).
DEV Community, The Architecture Behind Tamper-Proof Audit Logs.
MDPI Electronics, AuditableLLM: A Hash-Chain-Backed, Compliance-Aware Auditable Framework for Large Language Models.
Devoteam, Is AWS QLDB Built on Blockchain Technology?.
DZone, Immutable Data Integrity Using QLDB and Blockchain.
Mattermost, Compliance by Design: 18 Tips to Implement Tamper-Proof Audit Logs.
Pangea, Understanding Audit Logs: What It Is & How to Build One.
Medium (Mihir Popat), The Future of Immutable Data: A Comprehensive Guide to AWS QLDB.
GeeksforGeeks, What Is Amazon QLDB? Step-By-Step Process to Configure.
Bits Lovers, The Benefits of Using Amazon QLDB for Your Business.
SUDO Consultants, AWS Quantum Ledger Database: Quantum-Resistant Distributed Ledger.

Alice: Welcome back to Security for Legal SaaS. I'm Alice.

Dan: And I'm Dan. Episode 42 — hash-chained immutable logs. Last episode we designed the audit log. This time we're making it tamper-proof?

Alice: Tamper-evident, specifically. There's an important distinction. Tamper-proof means nobody can modify it. Tamper-evident means if somebody does modify it, you can detect it. With the append-only storage from Episode 41, we made it hard to modify logs. With hash chains, we make it mathematically detectable if someone manages to modify them anyway. Belt and suspenders.

Dan: Mm. So walk me through how a hash chain works. And remember — I skipped computer science.

Alice: Think of it like a notary chain. Imagine every time you write an entry in your audit log, a notary stamps it — but the stamp includes a reference to the previous entry's stamp. Entry one says "Sarah viewed document 001" and gets stamped. Entry two says "James approved a filing" and gets stamped — but entry two's stamp is calculated using entry one's stamp as an ingredient. Entry three's stamp uses entry two's stamp. And so on. Every entry is mathematically chained to every entry before it.

Dan: Right. And if someone changes entry one?

Alice: Entry one's stamp changes — because the stamp is calculated from the content. But entry two was calculated using the original stamp of entry one. Now entry two doesn't match anymore. The chain is broken. To hide the tampering, you'd have to recalculate every stamp from entry one all the way to the end. And if anyone has a saved copy of any stamp from anywhere in the chain, they can compare it and catch the fraud.

Dan: Hmm. The "stamp" in this analogy — that's the hash?

Alice: Exactly. A hash function — we covered these in Episode 17 when we talked about password storage — takes any input and produces a fixed-length output. We use SHA-256, which produces a 64-character string. Same input always produces the same output. Change one character of the input, and the output changes completely. So for each audit log entry, we compute SHA-256 of the entry's data combined with the previous entry's hash. That's the chain.

Dan: Yeah. And this is actually the same idea behind Git? The version control system?

Alice: Exactly the same mechanism. Every Git commit's hash includes the parent commit's hash. If you modify a historical commit, every subsequent commit hash changes, and the tampering is immediately visible. Certificate transparency logs work the same way. Blockchains work the same way — we're just using the chain part without the cryptocurrency, the consensus mechanism, or the distributed infrastructure. Blockchain-lite, if you will.

Dan: Mm. So it's a proven technique, just applied to audit logs.

Alice: <sigh> Proven for decades, and still most legal tech platforms store their audit logs in a regular database table that any administrator can modify with an UPDATE query. The hash chain is the difference between "we believe the logs are intact" and "we can mathematically prove they're intact." For a system that might need to produce evidence in court, that difference matters.

Dan: Mm-hmm. You mentioned a weakness though — if the attacker controls the entire log, they could rewrite the whole chain?

Alice: That's the one scenario a simple hash chain doesn't cover. If someone has complete control of the log storage — they're the database admin, they have write access to every entry — they could delete everything, rewrite the entries with whatever story they want, recompute all the hashes, and produce a consistent but completely fraudulent chain. The defence is external witnesses.

Dan: Right. What does that look like practically?

Alice: You periodically take the latest hash — the head of the chain — and publish it somewhere the log administrator can't touch. The simplest version: an automated daily email of the chain head hash to the compliance officer's personal email. Now even if the administrator rewrites the entire chain, the compliance officer has an independent record of what the hash should be. More robust versions: write checkpoint hashes to a separate cloud storage account with object lock — like S3 with a retention policy that prevents deletion. Or publish to a public transparency log. For most legal SaaS platforms, the separate cloud storage approach is the practical sweet spot.

Dan: Hmm. There are also dedicated databases for this, right? I've heard of AWS QLDB.

Alice: AWS QLDB — Quantum Ledger Database — was purpose-built for this. Append-only journal, built-in SHA-256 hash chains, cryptographic verification API. You write events, and QLDB handles the integrity guarantees automatically. One important caveat: AWS announced QLDB end-of-life for July 2025 and is directing customers to Aurora PostgreSQL with ledger tables or DynamoDB with provenance tracking. The specific service may be going away, but the underlying approach — append-only storage with cryptographic verification — is the pattern that matters, not the specific product.

Dan: Yeah. What about building your own? If you don't want vendor lock-in?

Alice: Completely viable. PostgreSQL with a dedicated audit table. The application's service account has INSERT permission only — no UPDATE, no DELETE. Your application code computes the hash chain — each entry's hash includes the data plus the previous hash. A scheduled verification job recomputes the chain and checks for breaks. And checkpoint hashes get written to external storage. It's maybe a hundred lines of code for the core logic. The hard part isn't the implementation — it's the operational discipline of maintaining separation of duties and running verification consistently.

Dan: Mm. Not everything needs this level of protection though, right? Which events get the hash chain treatment?

Alice: Prioritise by consequence. Privilege access events — who accessed privileged data and when — that's critical, because it's discoverable in litigation. AI-generated legal documents — the approval chain and provenance from Episode 37. Financial transactions — billing, trust account movements. Document production events — what was disclosed to opposing counsel and when, because you can't un-produce a document. Authentication events — login history gets subpoenaed in investigations. For general document access, standard append-only logging without hash chains is usually sufficient.

Dan: Right. So the full picture is — structured JSON entries from Episode 41, append-only storage, hash chain linking every entry, external checkpoints, automated verification, access controls, and seven-year retention?

Alice: That's the complete architecture. Structured, searchable, tamper-evident, and legally admissible. Every security control we've discussed in this series ultimately depends on this. When a regulator asks "prove that you redacted PII before sending data to the cloud," your answer is in these logs. When opposing counsel challenges the integrity of a document produced in discovery, your answer is in these logs. When a court wants to know whether a human actually reviewed an AI-generated filing, your answer is in these logs. Without tamper-evident audit trails, every other control is just a claim.

Dan: Mm. That's a strong way to put it. Every security control is only as good as the log that proves it happened.

Alice: Which is why we spent two full episodes on this. Get the logging right, and every other investment pays off. Get it wrong, and you're building security controls you can never prove were operational.

Dan: Next episode — Provenance Chains for AI Outputs. Tracking which model, which data, and which human approved every piece of AI-generated legal work.

Alice: Until then, I'm Alice.

Dan: And I'm Dan.

Alice: Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.

Security for Legal SaaS is a series written with AI assistance. Alice and Dan are AI-generated voices — no professional advice here, just education.