Hash-Chain Incident Record

A hash-chain incident record is an append-only, tamper-evident ledger of every event in a cyber incident response. Each entry includes a SHA-256 hash computed over the entry payload and the previous entry's hash. Any modification to a past entry breaks every subsequent hash. This page covers the cryptographic design, the public verifier, and why a tamper-evident incident ledger is the right substrate for regulator inquiries, litigation discovery, insurance claims, and AI agent provenance.

The mechanism

Each ledger entry contains four fields: the actor identity, the action class, the timestamp, and the payload (the actual content of the event). The entry hash is computed as SHA-256(payload || actor || timestamp || prev_hash) where prev_hash is the hash of the immediately preceding entry. The chain extends one entry at a time. There is no facility for editing or removing past entries. The chain only grows.

The tamper-evident property follows directly from the cryptographic strength of SHA-256: changing payload[k] for any past entry k changes hash[k], which forces a change in hash[k+1], which forces a change in hash[k+2], and so on through to hash[N]. Recomputing every subsequent hash is computationally possible. Doing so without detection at the published root is not. The root is what anchors the chain to an externally verifiable timestamp.

What goes in the ledger

Every state change in the incident response is committed to the chain. The IR-OS ledger captures: incident open with classification, role assignments, severity changes, materiality determinations, regulator clock starts and stops, draft creations and revisions, approvals (with named approver and bound output hash), transmissions to regulators (with transport metadata), communications releases, AI agent invocations (with model, prompt hash, retrieval hash, output hash), evidence acquisitions (with chain-of-custody metadata), and incident close.

The ledger is not a chat transcript. It is an audit trail of accountable actions. A chat message about lunch does not enter the ledger. A draft regulator notification, an approval, a transmission, a materiality determination - those enter the ledger.

Public verifier

IR-OS publishes the chain root to the public verifier at app.ir-os.com/verify. Any third party who receives an export of the ledger can recompute the chain locally with any SHA-256 implementation, check that each entry's hash matches the formula, and confirm that the final hash matches the published root. The verifier requires no IR-OS account. The verifier source code is auditable.

The public verifier exists because tamper-evidence is a claim that has to be independently testable to be meaningful. If only the platform can verify the chain, the customer has to trust the platform. With the public verifier, the customer's counsel, the regulator, and the insurer can each verify independently. Trust is in the cryptography, not in the platform.

Regulator and litigation use

Regulators reviewing a cyber incident routinely ask: when was the incident discovered, when was materiality determined, when was counsel engaged, what was decided when, who approved each communication. A hash-chain ledger answers all these questions with cryptographic proof. SEC enforcement counsel reviewing an Item 1.05 filing can see the exact materiality determination timestamp and the named decision-maker. GDPR supervisory authorities reviewing an Article 33 notification can see when awareness was established and when the notification was approved by the controller.

Litigation discovery requests for cyber incident records can pull years-old data. The hash-chain provides authentication support under Federal Rules of Evidence 901 and 902, particularly the 902(13) and 902(14) provisions for records generated by an electronic process and for copies of digital evidence. Counsel can present the ledger with the cryptographic verification, supporting the foundational showing of integrity.

NIST and ISO alignment

NIST SP 800-92 Guide to Computer Security Log Management requires log integrity protection. NIST SP 800-86 Computer Forensics Guide aligns with chain-of-custody and evidence preservation. NIST SP 800-61 Revision 3 (April 2025 final) updates incident handling guidance and supports the hash-chained ledger pattern for incident records. ISO/IEC 27037 (digital evidence) and ISO/IEC 27035 (information security incident management) align with tamper-evident incident records.

The hash-chain is one direct implementation of the integrity controls these standards require. The chain does not by itself produce certification; the customer must implement the surrounding policies (retention, access control, separation of duties). The chain provides the technical substrate; the customer provides the program.

AI agent provenance

The hash-chain ledger is also the substrate that makes AI for cyber incident response defensible. Every AI agent invocation produces a ledger entry with: the agent identifier, the model name and version, the prompt hash, the retrieval context hash, the output hash, and the named human approval signature. The hash-chain makes the AI activity record tamper-evident.

When a regulator or counsel asks "was this draft regulator notification AI-generated, what was the prompt, who approved it" the answer is in the chain. The AI provenance is not separate from the incident record; it is part of the same chain. The architecture treats AI and human actions as first-class events on the same ledger.

Operational properties

Append-only means there is no edit and no delete. A mistake in a past entry is corrected by a subsequent entry that supersedes the prior content. The original error remains in the chain with the correction linked to it. This is consistent with how regulators and courts expect a defensible record to behave: the record shows the response as it actually unfolded, with corrections visible.

The chain is per-incident. Each incident has its own genesis entry and its own root. There is no cross-incident chaining at the application layer. This keeps the verification model simple and the per-incident export clean. Customer policies may chain multiple per-incident roots into a per-organization root for retention purposes; the IR-OS export supports either model.

Comparison with alternatives

Hash chain with published root is the right design point for cyber-IR: tamper-evident, independently verifiable without key management, low latency, and operationally simple. Public blockchain adds latency and cost without meaningful incremental integrity over a published root.

Frequently Asked Questions