The Cyber Incident Response Field Manual 2026

Plan

Operator intent: every named role, every decision authority, every escalation path, every runbook is written down, approved, and current.

The plan is the source of truth the IRC reaches for at 03:00 on a Sunday. A real plan extends a recognized framework with the named roles, the runbooks for the incident types the organization actually faces, the regulatory clocks the organization is subject to, and the integrations with the cyber insurance carrier and counsel of record. Update at least annually and after every material incident.

Frameworks IR-OS provides as starting templates

• NIST SP 800-61 (Rev 3). US federal four-phase model: Preparation, Detection and Analysis, Containment Eradication and Recovery, Post-Incident Activity. Familiar to federal contractors and US public companies.
• ISO/IEC 27035-1. International standard, five phases: Plan and Prepare, Detection and Reporting, Assessment and Decision, Responses, Lessons Learned. The default for multinational organizations under ISO 27001.
• IR-OS Expert template (developed by our team with Advisory Board input from Mark Lynd). Seven-phase operator structure that aligns to this manual. Includes the six IRC functions, the parallel-clock notify phase, the structural-privilege document phase.

What an IR-OS plan contains

• Six IRC functions (Commander, Operations, Planning, Communications, Legal, Executive Sponsor) with primary and alternate
• Decision authorities (who can declare, who can pay ransom subject to OFAC clearance, who can issue public statements, who can engage counsel of record)
• Escalation paths with time thresholds
• Runbooks for the incident types the organization faces (ransomware, BEC, supply chain, insider, DDoS, lost device, third-party compromise, regulatory-driven scenarios)
• Regulatory clock map: which clocks apply to this organization, who owns each
• External-party contact list: insurance carrier, broker, breach counsel, forensic firm, public relations, regulator contacts
• Communications templates (holding statement, customer notice, regulator notification, board brief)

Plan artifacts and references

Exercise

Operator intent: the plan has been pressure-tested against realistic scenarios with full C-suite participation before an actual incident arrives.

A plan that has never been exercised is a document, not an operating system. The minimum cadence is one full tabletop per year. Mid-market and enterprise programs typically run two to four exercises per year covering different scenarios. The 30-minute self-run tabletop the IR-OS Field Manual links to is designed for quarterly cadence between annual full exercises.

Exercise types

• Full C-suite tabletop. 2 to 4 hours, all six IRC functions plus the Executive Sponsor and board observer. Annual minimum.
• 30-minute self-run tabletop. Quarterly, function-focused. A single scenario, one decision point, captured gaps.
• Functional exercise. Walk a runbook for a single incident type with the function lead. Used to pressure-test the runbook itself.
• Red-team-driven scenario. Live or simulated red team triggers the IRC. Highest realism, highest cost.
• Regulator-driven scenario. Required for some DORA-subject financial entities and some SEC-registrant boards.

Exercise artifacts and references

Respond

Operator intent: from declaration to containment, the IRC operates as a single team with named owners, time-bound tasks, and a hashed timeline.

Respond is the technical and operational workstream of the live incident. The IRC assembles, the six functions activate, the runbook for the incident type opens, the timeline begins. Single owner per task. Time-bound. Hashed events. The Command Center surface in IR-OS is the screen the Commander runs from.

Time to Command

Time to Command is the elapsed time from incident declaration to the IRC being assembled, the six functions assigned, the timeline open, and the runbook started. Best-in-class programs measure Time to Command in minutes, not hours. The IR-OS Command Center surface is designed to compress Time to Command by automating role assignment, runbook selection, and timeline opening from the declaration event.

Runbooks IR-OS publishes

• Ransomware. Detection, IRC declaration, OFAC ransom-payment screening, decryptor evaluation, containment, restoration, customer notice, regulator notice.
• Business email compromise (BEC). Wire fraud holds, FinCEN SAR, OFAC screening, account containment, customer notice, regulator notice.
• Supply chain compromise. Third-party trigger, dependency analysis, scope containment, vendor coordination, regulator notice.
• Insider threat. Forensic image preservation, HR coordination, counsel-led containment, evidentiary handling.
• Lost or stolen device. Remote wipe, encryption attestation, breach analysis, notification trigger evaluation.
• Third-party compromise affecting the organization. NY DFS 500.17(a) and SEC materiality analyses run in parallel.

Respond artifacts and references

Notify

Operator intent: every regulatory clock the incident triggers is running, owned, and on track. Missing first-notice voids insurance. Missing SEC voids defense. Missing GDPR voids penalty mitigation.

Six to nine clocks running in parallel is common for a mid-market US-incorporated organization with EU customers, payment-card data, or healthcare records. Most plans track one clock. Real cyber-IR teams run all of them from a single incident record. The Field Manual links to all eight major clocks with the source paragraph each one cites.

The eight major regulatory clocks

• SEC 8-K Item 1.05 (4 business days from materiality determination). US public companies. SEC reporting surface · SEC clock explained
• GDPR Article 33 (72 hours from awareness). EU personal-data controllers. GDPR 72-hour notification explained
• NY DFS 23 NYCRR 500 (72 hours from determination). NY-regulated financial entities.
• HIPAA Breach Notification Rule (60 days, plus 500+ media notice). US covered entities and business associates.
• PCI DSS 12.10 (brand-dependent, typically immediate). Entities storing, processing, or transmitting cardholder data.
• NIS2 (24h early warning / 72h notification / 30-day final). EU essential and important entities. NIS2 reporting surface
• DORA Article 19 (4h initial / 72h intermediate / 1mo final). EU financial entities. DORA reporting surface
• CIRCIA (72 hours / 24 hours for ransom). US critical-infrastructure entities.

Notify artifacts and references

Communicate

Operator intent: the right audience hears the right message at the right time, every release approved through the privilege chain, every outbound logged.

Crisis communications is a peer workstream to Respond and Notify, not a sub-task. The IR-OS Crisis Communications surface treats stakeholder messaging as a first-class part of the incident lifecycle. A holding statement in hours, regulator notifications as clocks fire, customer notices once material facts are confirmed, employee updates daily, public messaging coordinated with counsel and PR.

Communication sequencing

• Hour 0 to 24: holding statement. Pre-drafted, attorney-shape, under privilege. Bridges to a more complete disclosure once material facts are confirmed.
• Hour 0 to 72: regulator notifications. Per the clock map from Phase 4.
• Hour 24 to 72: internal employee update. What we know, what we don't, what employees should and should not say externally.
• Day 2 to 30: customer breach letters. Once material facts are confirmed, jurisdiction by jurisdiction.
• Day 5 to 30: public statement. Coordinated with counsel and PR, often paired with the SEC 8-K filing.
• Day 30 to 90: board brief and ongoing stakeholder updates.

Privilege chain

Every release is approved through the Legal-Communications-Executive Sponsor chain. In IR-OS the signoff is captured at SHA-256 granularity in the hash-chained event ledger so privilege is structural in the data model and the approval trail is defensible in subsequent regulatory or litigation review. Privilege is not asserted by the responder after the fact; it is structural in the record.

Communicate artifacts and references

Document

Operator intent: every decision, action, escalation, approval, and outbound message is in the record, append-only, hashed in a chain a third party can re-prove.

A defensible incident record is the substrate that lets every other phase be trusted later. Counsel reviews drafts knowing the chain is intact. Regulators receive submissions knowing the underlying record is verifiable. Insurance carriers receive first-notice knowing the timeline is the actual timeline. The append-only ledger and the public verifier are the architectural commitments that make this possible.

How the record is structured

• Append-only event ledger. The incident_events table is write-once. No update, no delete.
• SHA-256 chained. Each event hashes the prior event hash plus the new event content, producing a verifiable chain.
• Structural privilege. Counsel-led work is captured under privilege boundaries enforced in the data model, not asserted after the fact.
• Public verifier. Available at app.ir-os.com/verify. Anyone with the record snapshot can re-prove the chain.
• Submission capture. Submissions to regulators and outbound communications are captured back into the ledger so the defensible record is end-to-end complete.

Document artifacts and references

Review

Operator intent: within 30 days the AAR is written, distributed, and the gaps are tracked back into the plan and the next exercise cycle.

After-action review (AAR) is the structured review process at the close of a cyber incident: scope, timeline, decisions, what worked, what failed, root causes, gaps closed, gaps tracked. AAR comes from the US military and government lineage and is the standard term in cyber-IR. The IR-OS auto-generated AAR composes the eight sections from the event ledger itself, then routes to the IRC for narrative additions and to the Executive Sponsor for sign-off.

The eight AAR sections

1. Scope. What this incident was, what it was not, what data and systems were affected.
2. Timeline. From first detection signal through containment and remediation, with the key decision points.
3. Decisions. Every IRC decision with the decision-maker, the rationale, the outcome.
4. What worked. Plan elements, runbook steps, and IRC behaviors that performed as designed.
5. What failed. Plan elements, runbook steps, and IRC behaviors that did not perform as designed.
6. Root causes. Why the failures happened (people, process, technology, third party).
7. Gaps closed. Changes made during the incident that closed gaps in the plan or runbook.
8. Gaps tracked. Open gaps with named owners and dates, written back into the plan and into the next exercise cycle.

Plan writeback

The AAR feeds back into the Plan phase. Gaps tracked in Phase 7 become items on the next quarterly tabletop in Phase 2 and updates to the plan itself in Phase 1. The loop is the operating system. A program that produces AARs but does not write them back to the plan is a program that learns the same lesson twice.

Review artifacts and references