What is an incident response plan (IRP)?

Key takeaways

• The IRP defines who decides what, when, with whose input, during a cybersecurity incident.
• A good IRP is short enough to use under pressure and specific enough to actually answer the questions that arise. Most IRPs fail one of those criteria.
• The IRP is not the incident response process; the IRP is the documented version of the process the organization actually follows.
• Required (explicitly or implicitly) by NIST CSF 2.0, NIST SP 800-171, CMMC, ISO 27001, and most cyber insurance underwriting.
• ARG delivers IRP scaffolding as part of the engagement; the client team owns the maintenance and the executive sign-off.

What does an incident response plan need to contain?

A serious IRP has eight components. Each one answers a specific question that comes up during a real incident.

1. Scope and definitions. What incidents the plan covers (cybersecurity events, data breaches, ransomware, BEC, physical incidents with cyber implications, OT incidents). Definitions for incident, event, breach, so the team uses vocabulary consistently. Severity tiers (typically 1-4 or critical/high/medium/low) with criteria.

2. Roles and responsibilities. The incident commander (single person responsible for decisions during the incident), the executive sponsor (decision authority for severe incidents), technical leads (IT, security, OT where applicable), legal, communications, HR. Each role has named individuals plus backup, with contact information.

3. Detection and escalation. What detection sources feed the IRP. Who receives initial alerts. How an event escalates to an incident. The escalation tree for severity tiers. Time-of-day considerations (business hours vs after-hours vs weekend).

4. Response procedures. For each severity tier and each major scenario, the response sequence. Containment options, eradication steps, recovery sequence. Where the IRP references scenario-specific playbooks (ransomware, BEC, OT, insider, etc.).

5. Communication plan. Internal communications (executive team, broader staff, customers, board), external communications (customers, regulators, law enforcement, insurance, vendors, public), and channel selection. Templates for the first hour, the first day, the first week.

6. Notification and reporting obligations. Regulatory notification timelines (DC3 for DoD contractors, state breach laws, GDPR if applicable, SEC if applicable), customer notification requirements (under contracts), insurance notification (typically within a specified window).

7. Evidence preservation. What to capture, what not to delete, chain-of-custody procedures, forensic preservation. For an IRP supporting CMMC or 800-171 work, this section satisfies specific control requirements.

8. Post-incident review. The lessons-learned process: who participates, what is documented, how findings flow into the risk register and back into the IRP.

The eight components together produce a document that someone awakened at 2 a.m. can use to figure out what to do next.

IRP vs business continuity plan vs disaster recovery plan

Three documents that overlap but answer different questions.

• Incident response plan (IRP). How the organization responds to security incidents. Covers detection, containment, eradication, communication, evidence, lessons learned.
• Business continuity plan (BCP). How the organization continues operations during disruption (of any kind: cyber, weather, supply chain, pandemic, facility loss). Covers prioritized operations, alternate work arrangements, succession, customer commitments.
• Disaster recovery plan (DRP). How IT systems are restored after a major disruption. Covers backup restoration, system rebuild, data validation, return to production.

The three overlap because a major cyber incident is also a continuity event and a recovery event. The IRP covers the first phases; the BCP covers ongoing operations during recovery; the DRP covers technical restoration.

Mid-market manufacturers often combine the three into a single document. That can work, but the combined document tends toward generality. Separate documents are usually better; cross-references between them solve the overlap problem without compromising specificity.

Why most IRPs are useless during a real incident

A typical IRP at a mid-market manufacturer fails one of seven specific ways:

1. It does not exist. The most common failure. The organization has a placeholder document or a template never adapted.
2. It is too long. A 200-page IRP that cannot be read under pressure. Hard to navigate, hard to find the right section, hard to use in the first hour.
3. It is too generic. Sentences like "the incident commander will coordinate the response" without specifying who that is. Action without specificity is no action.
4. Contact lists are stale. Phone numbers, email addresses, names changed. The first calls in a real incident go to people who left the company eighteen months ago.
5. It assumes systems that are unavailable. "Send the alert via Slack" when Slack is down because the same incident took it down. "Email the executive team" when email is the compromised system.
6. It has never been practiced. The first time the team uses it is the actual incident. The plan reads like it works on paper because no one has tried to actually follow it under time pressure.
7. Decision authority is undocumented. The plan describes actions without specifying who decides. Real incidents stall at decision points; the IRP that pre-authorizes decisions saves hours.

Each failure is preventable. The discipline is in the writing and the maintenance.

Examples of IRP failures and what they cost

What ARG and the broader industry see:

• Ransomware Friday night, IT lead reaches voicemail. Ransomware encrypts servers; the IT lead's IRP-listed phone number rings to voicemail. The IT lead changed phone numbers six months ago. Two hours lost finding correct number.
• Wire-fraud incident, no documented bank contact. BEC wire goes out Friday; recovery requires bank engagement within hours. The IRP does not list the bank's fraud-team contact; finding it takes most of Saturday morning. Recovery window narrows; funds become unrecoverable.
• OT incident, IRP only covers IT. Ransomware reaches the engineering file server, then a SCADA-adjacent server. The IRP has no OT-specific section; the engineering team is not in the contact tree; production stops because no one knows whether to halt operations.
• Insurance notification window missed. Policy requires notification within 72 hours of "knowledge of incident". The IRP does not surface this timeline; the team focuses on technical response; the notification goes out on day five; coverage dispute follows.
• Communication template missing for customer notification. A breach affects customer data; customer notification needs to go out within days; the IRP has no template; legal review of an ad-hoc draft takes a week; customers learn from press coverage first.
• Decision authority for production stoppage is unclear. Ransomware staging detected in IT; the IRP does not pre-authorize a production stoppage; the operations team continues running while IT debates; ransomware reaches OT-adjacent systems before the stoppage is approved.

Each failure has a fix in the IRP. None of the fixes are expensive. All of them require the discipline of writing the specific answer in advance.

How to write an IRP a tired person can follow at 2 a.m.

Eight principles for writing an IRP that actually works.

1. Start with the worst-case 2 a.m. scenario. Imagine the IT lead awakened by an alert. What is the first page they need to see. Build the IRP around that page.
2. Decision-first structure. Each section opens with the decision the reader has to make, then the inputs to the decision, then the options. Not the other way around.
3. Specific names, not roles. "Call David Ashby at 555-0123" rather than "contact the IT lead". Roles are abstract; names are operational. (Maintain the names through changes.)
4. Time-boxed actions. "Within 30 minutes" rather than "promptly". Specific times produce action.
5. One-page playbooks for top scenarios. Ransomware, BEC, insider, OT, supply chain. Each scenario has a single page that lists the first hour's actions in order.
6. Pre-authorized decisions within thresholds. "Production stoppage authorized below tier 3 incident, IT lead decides; tier 3 and above requires executive sponsor approval." Decisions made in advance save hours during the incident.
7. Test in practice, not in theory. Every tabletop exercise is a stress test on the IRP. Gaps surface during tabletops; the IRP updates accordingly.
8. Format for low-bandwidth consumption. Short paragraphs, lots of headings, bullet points where useful, tables for time-boxed actions. The IRP reader is not reading; they are scanning under pressure.

A well-written IRP feels short. It includes the questions that come up under pressure and the answers to those questions. It does not include philosophy, framework theory, or general security guidance; those belong in other documents.

Best practices for keeping an IRP usable over time

The IRP is a living document. The maintenance discipline:

1. Named owner. A single person responsible for keeping the IRP current. Usually the IT lead or designated security owner. The owner is not responsible for every decision in the IRP; the owner is responsible for the document.
2. Quarterly review cadence. A 30-to-60 minute review every quarter to check contact lists, validate procedures, confirm pre-authorized decisions still match the organization.
3. Update triggers. Material changes (new systems, new vendors, new leadership, new compliance regime, new product line) trigger an IRP update. Each change documents the impact.
4. Tabletop-driven improvement. Every tabletop produces IRP corrective actions. The actions land within 30 days; the next tabletop validates them.
5. Post-incident-driven improvement. Every actual incident produces IRP updates as part of the lessons-learned phase.
6. Annual full review. Once a year, a top-to-bottom read with the executive sponsor. The review confirms the IRP still matches reality; updates land before the next quarter.
7. Document the changes. A change log at the top of the IRP shows when and why changes were made. The change log is the evidence trail for compliance audits and insurance underwriting.
8. Pair the IRP with an offline-accessible copy. Cloud-only documents are vulnerable to the incident they describe. A printed copy or local copy on the incident commander's device provides resilience.

Incident response plan FAQs

Is an IRP required for cyber insurance?

Effectively yes. Most cyber insurance underwriting questionnaires ask whether the organization has a documented IRP and whether it is tested. Carriers do not always require it explicitly as a binding condition, but the absence of an IRP affects pricing and (in tightening markets) availability of coverage. See What is cyber insurance underwriting?.

How long should an IRP be?

Twenty to forty pages for the core plan. Plus appendices: contact lists, scenario-specific playbooks, communication templates, evidence-handling procedures. Longer IRPs are usually worse; the discipline is to keep the plan short enough that a tired person can find what they need at 2 a.m.

Who should sign off on the IRP?

The executive sponsor (CEO, COO, or equivalent), the IT lead, and (where applicable) legal counsel. Sign-off matters because the plan pre-authorizes specific decisions; without executive sign-off, the people in the response have to escalate decisions that should already be authorized.

How often should the IRP be updated?

After every tabletop exercise (corrective actions land), after every actual incident (lessons learned), after any material organizational change (new systems, new vendors, new leadership), and at least annually. The IRP is a living document; an IRP that has not changed in a year is usually wrong about something.

How ARG delivers IRP scaffolding alongside audit reports

Every ARG engagement at a manufacturing client produces, as a byproduct, the scaffolding for a usable incident response plan. The work is led by James Wall on the digital and procedural side, with David Ashby contributing on physical and OT scenarios.

The scaffolding includes:

• A core IRP template. Adapted to the client's environment based on the audit findings: actual systems, actual vendors, actual roles, actual decision authority.
• Scenario playbooks for the top six incident types. Ransomware, BEC, OT/SCADA incident, insider, supply chain compromise, physical incident with cyber implications. Each playbook is a one-page action sequence for the first hour, with extensions for hours 2-24.
• Communication templates. First-hour internal escalation, first-day executive update, first-week customer notification (where applicable), regulator notification (where applicable), insurance notification, board notification.
• Pre-authorized decision matrix. Decisions documented with thresholds and named authorizers. Production stoppage, ransom decision (escalates to executive in all cases), customer notification, public disclosure.
• Contact lists. Internal team, external IR partner (or recommendation if no retainer exists), legal, insurance, banking, regulators, key vendors.
• Evidence-handling procedure. Chain of custody, what to preserve, what not to delete, forensic capture process aligned with NIST SP 800-171 and CMMC requirements.

The client team owns the IRP going forward. ARG's role is initial scaffolding plus continuous validation: every tabletop, every adaptive simulation finding, and every quarterly review feeds back into the IRP through documented corrective actions. The IRP that exists at the end of Year 1 reflects real engagement findings, not template content.

For founding clients, IRP scaffolding and quarterly maintenance support are part of the monthly retainer.

Apply as a founding client or see how the engagement works for the full delivery cycle.