Defensible Record - Incident Documentation Standard
A defensible record is an incident documentation standard that can withstand scrutiny from regulators, auditors, courts, and plaintiffs. The defining property of a defensible record is that the record cannot be modified after the fact without detection. Defensible records are increasingly required by regulators (SEC, EU DPAs, NIS2 competent authorities) and by cyber insurance carriers as a condition of coverage.
What Makes a Record Defensible
- Append-only: events cannot be edited or deleted after creation
- Tamper-evident: any modification is detectable, typically via cryptographic hash chains
- Time-stamped: each event has a server-side timestamp that cannot be backdated
- Attributed: each event is tied to an authenticated identity
- Comprehensive: covers decisions, actions, notifications, handoffs, and approvals
- Exportable: can be produced in a verifiable format for regulators and counsel
Why It Matters
Spreadsheets, Slack messages, email threads, and shared documents are not defensible. They can be edited, deleted, or revised without detection. When regulators or plaintiffs ask whether an event happened at a specific time, the defensible record provides the answer; a Slack channel is evidence of a discussion, not of a binding event.
Defensible Record vs Audit Log
An audit log records system events (who logged in, what changed). A defensible record records incident events (what was decided, who was notified, when handoff occurred). The two are complementary but distinct. Mature programs maintain both, with the defensible record explicitly designed for human-meaningful incident events rather than system telemetry.
Build a defensible record by default
IR-OS is event-sourced with a SHA-256 hash chain, producing a defensible record regulators, courts, and auditors can verify.
Start free