We value your privacy

We use cookies to analyze site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Cybersecurity
  3. Incident response plan
Incident response plan development for US businesses

Most plans fail for two reasons at once: nobody had read it, and it lived on the share that just got encrypted.

This document gets judged exactly once, at speed, by people who had no hand in writing it. Everything follows from that. It has to be short, reachable when the network is not, unambiguous about who has authority over what, and rehearsed enough that the first run-through is not the actual emergency.

Book an incident response planning sessionSee what a usable plan contains
Incident response plan development for US organizations
  • Findable offlineBecause the file share may be down
  • Named decisionsWho declares, who authorizes, who speaks
  • ExercisedA plan never rehearsed is a document
  • CIS Control 17Incident response management, in the eighteen
What a usable plan contains

Seven things that separate a plan from a document.

The current federal guidance is the third revision of the NIST incident response publication, issued in April 2025 as a CSF 2.0 Community Profile under the title Incident Response Recommendations and Considerations for Cybersecurity Risk Management. It sets out to help organizations prepare properly, cut both how often incidents happen and how much they cost, and make detection, response, and recovery more efficient.

Named people, named deputies, and current numbers

Naming only roles ages badly. Naming individuals without a backup collapses the moment one of them is on a plane. What works is the person, their deputy, and a way to reach either that does not run through corporate email or the corporate network, since in a real incident both may be down or actively untrustworthy.

A declaration threshold somebody can apply at 3am

The single most consequential moment is the one where somebody says this is now an incident. A plan promising that the security team will assess severity and respond appropriately gives absolutely nothing to the person actually holding the phone at midnight. What helps is a threshold written as things you can observe, plus the name of whoever is allowed to make the call.

Decision rights, especially the expensive ones

Who is allowed to pull a production system down. Who can cut an entire site off the network. Who can commit money to external responders, and how much before a second signature is needed. Who decides that no ransom will be paid. In practice these get decided under pressure by whoever happens to be awake, and pre-authorizing them removes the single largest source of delay in most real incidents.

External contacts, gathered before you need them

Incident response retainer, cyber insurance carrier notification route and policy number, breach counsel, key vendors, and the account team at each critical supplier. For public companies, the officers involved in a materiality determination belong on this list too. Assembling it is an afternoon of work in peacetime and a very bad hour during an incident.

Scenario playbooks, not one general procedure

Ransomware, a compromised mailbox, data walking out the door, a trusted insider, and a critical supplier going dark all behave differently and demand different opening moves. One general procedure handles every one of them poorly. Three or four playbooks of two pages each handle the realistic cases properly, and people actually read them.

Exercised, because that is where the plan gets fixed

Rehearsal surfaces what reading never will: the contact who resigned in March, the decision everybody deferred, the quiet assumption that a particular system would still be up. The federal guidance is built around preparing for incident responses, and an exercise is the moment preparation stops being a document.

Available when the network is not

Kept only on the file share, or only inside Teams, it is unreachable in precisely the incidents where it counts. Paper copies in the hands of the people who need them, plus one copy stored entirely outside the environment, is unfashionable and it is the whole difference between having a plan and having had one.

The three questions every real incident asks first

Three questions decide everything: is this an incident, who says so, and can that server be pulled off the network.

Nearly every plan we are asked to review answers all three in language nobody could act on at two in the morning.

  • Whether this counts as an incident. Written as conditions somebody can observe rather than a severity judgment, so whoever is on call can apply it without first needing to be the most senior person in the company.
  • Who has the authority. One named person and one named deputy, contactable by a route that does not rely on the corporate network or corporate mail, since either may be down or compromised.
  • Can we take that offline. Pre-authorized containment decisions with a named authorizer and a clear boundary, because the delay between recognizing containment is needed and being permitted to do it is where most damage accumulates.
  • Everything else in the document matters less than these three. Two pages that answer them concretely beat forty pages that answer them in principle and cannot be located while the incident is running.
Ask us to review your existing plan
How we approach it

Four things that decide whether it holds up on the day.

Enough real incidents have taught us which pages get opened and which never do. The ratio is nothing like what most plans are written to assume.

We agree the decisions before we write the document

Who calls it, at what threshold, who may disconnect systems, who may commit money, who talks to the outside, and where counsel comes in. That is the plan. A document written before those are settled is a tidy list of unanswered questions, and every one of them gets asked again at the worst imaginable moment.

Short enough that somebody reads it while the room is loud

A core document readable in ten minutes, plus two-page playbooks for the scenarios that could actually happen to you. Length and use run in opposite directions. The exhaustive plan covering every conceivable eventuality is the one that stays closed, because nobody reads forty pages at two in the morning with the phone ringing.

We verify the contact pack by calling it

The responder retainer, your carrier and its policy number, breach counsel, and the critical vendors with named account teams. A contact list nobody has dialed is a list of assumptions. Calling every entry on a quiet Tuesday takes one afternoon and reliably turns up two or three that are wrong.

We exercise it before we call it finished

A tabletop with the real response team against a scenario that fits your business. What comes out is a list of corrections, not a grade, because the objective is finding the gaps while fixing them still costs almost nothing. An unexercised plan is a draft no matter how well it reads.

How we build it

Four phases, and it is the rehearsal that finishes the plan rather than the writing.

Written and handed over, it is still a draft. It becomes a plan only after the people who would actually use it have run it against a scenario and corrected everything that fell apart.
  1. 01
    Weeks 1 to 2

    Establish the decisions before the document

    Who declares one, against what threshold, who authorizes containment, who authorizes spending money, who speaks to the outside world, and who notifies whom, including the point where breach counsel takes over. Those answers are the plan. Drafting the document before settling them produces a beautifully formatted list of open questions.

    • Declaration threshold expressed in observable conditions
    • Named decision makers with named deputies
    • Pre-authorized containment boundaries
    • Spend authority for external response agreed in advance
  2. 02
    Weeks 3 to 4

    Write it short, and build the contact pack

    A core document short enough to read while an incident is running, with playbooks of roughly two pages per scenario. Then the external contact pack: responders, your carrier with the policy number, breach counsel, and critical vendors with their account teams, each one verified by an actual phone call rather than copied out of a three-year-old file.

    • A core document short enough that somebody will genuinely read it
    • Scenario playbooks for the realistic cases
    • A verified external contact pack, tested by calling
    • Out-of-band communication arrangements agreed
  3. 03
    Weeks 5 to 6

    Exercise it, and fix what the exercise finds

    A tabletop run with the people who would really be in the room, against a scenario that could plausibly happen to your business. Nobody passes or fails. What comes out is a correction list: the contact who left last spring, the decision nobody felt authorized to make, the system everybody assumed would still be reachable.

    • A tabletop exercise with the real response team
    • A findings list from the exercise, not a certificate
    • Plan corrected against what the exercise revealed
    • Second exercise scheduled before the engagement closes
  4. 04
    Ongoing

    Keep it current, because it decays quietly

    People resign, numbers get reassigned, systems get replaced, and suppliers change hands. The document rots quietly and the rot is invisible right up until somebody opens it in anger. A short quarterly pass over the contact list and a written review after any material change is what keeps it usable.

    • Quarterly contact verification
    • Review after any material change to people or systems
    • An exercise at least annually, ideally more often
    • Offline copies refreshed when the plan changes
Where this matters most

Six moments when American companies write one of these, and one where they wish they had.

The prompt almost always comes from outside: a carrier at renewal, a customer questionnaire, an auditor, or a board member who read something. Occasionally it is a breach at a competitor, which is the cheapest warning anyone ever gets.

A company with notification obligations and a clock that starts on recognition

State breach notification statutes, sector rules such as HIPAA, and SEC disclosure obligations for public companies all share one property: the process starts at a point somebody has to recognize. That makes the declaration threshold and the escalation to counsel a compliance control rather than an operational preference, and it needs to be written, exercised, and evidenced rather than understood.

An organization renewing cyber insurance

Underwriters now routinely ask three things: is there a plan, when was it last rehearsed, and is the notification route written down. Each takes a sentence to answer if the work exists and produces an awkward silence if it does not. The route to your carrier, with the policy number beside it, belongs inside the plan itself, because a great many policies make coverage conditional on prompt notice.

A group of companies where nobody can say who actually decides

Multi-company groups face the worst version of this, because whoever can authorize taking a subsidiary system offline may sit in a different legal entity and a different time zone. Establishing that during an incident burns hours. Establishing it beforehand takes a single meeting.

An operator where disconnecting means stopping production

Containment is easy when unplugging something merely annoys people. It becomes a real commercial decision when unplugging stops a plant, a production line, or a distribution center. IT cannot make that call, and nobody can make it quickly unless the authority and its limits were settled in advance.

A healthcare organization where systems cannot simply be turned off

Clinical systems change the containment arithmetic completely, and the plan has to be written with clinical staff in the room rather than assuming a standard playbook transfers. It must name who weighs patient safety against containment, what information they need to do it, and exactly what falling back to paper looks like, with the HIPAA notification obligations run through counsel in parallel.

An organization that has just watched a peer be attacked

This is the cheapest prompt available and by far the best moment to do the work. Attention exists, the board is already asking, and nobody is operating under duress. A plan written and rehearsed in that window costs a fraction of one assembled in the wreckage of your own incident, and it turns out considerably better.

Three positions

How US organizations are prepared for an incident.

Most companies sit in the middle column. There is a plan, it was written competently, it has never been rehearsed, and the phone numbers in it are three years stale.
A written plan exists
Exercised and currentYes
A plan that has never been usedYes
No planNo
Available when the network is not
Exercised and currentYes
A plan that has never been usedNo
No planNot applicable
Declaration threshold actionable
Exercised and currentYes
A plan that has never been usedVague
No planNot applicable
Containment pre-authorized
Exercised and currentYes
A plan that has never been usedNo
No planNo
Contacts verified
Exercised and currentYes
A plan that has never been usedStale
No planNone
Scenario playbooks
Exercised and currentYes
A plan that has never been usedOne general procedure
No planNo
Exercised in the last year
Exercised and currentYes
A plan that has never been usedNo
No planNo
External responders identified in advance
Exercised and currentYes
A plan that has never been usedNo
No planNo
Insurer notification route known
Exercised and currentYes
A plan that has never been usedRarely
No planNo
First hour of a real incident
Exercised and currentStructured
A plan that has never been usedImprovised
No planChaotic
Feature
Exercised and current
A plan that has never been used
No plan
A written plan exists
YesYesNo
Available when the network is not
YesNoNot applicable
Declaration threshold actionable
YesVagueNot applicable
Containment pre-authorized
YesNoNo
Contacts verified
YesStaleNone
Scenario playbooks
YesOne general procedureNo
Exercised in the last year
YesNoNo
External responders identified in advance
YesNoNo
Insurer notification route known
YesRarelyNo
First hour of a real incident
StructuredImprovisedChaotic
The scenario playbooks

Five scenarios, and why the opening hour looks nothing alike across them.

These are the playbooks we write for most American companies. Keeping them separate matters because the opening moves genuinely differ, and one catch-all procedure blurs precisely the distinctions you need clearest under pressure.

Scenario

Ransomware

What the first hour is about
Determining spread and stopping it, before anything else
The decision that cannot wait
Whether to disconnect, and who is permitted to authorize it

Scenario

Business email compromise

What the first hour is about
Working out what the account touched and whether any money has already left
The decision that cannot wait
Contacting the bank, and who can instruct a recall

Scenario

Data exfiltration

What the first hour is about
Establishing what left, when, and whose it was
The decision that cannot wait
Whether counsel needs to start a notification analysis now

Scenario

Insider action

What the first hour is about
Preserving evidence before the person is aware
The decision that cannot wait
Who gets told, in which sequence, and where HR and counsel come in

Scenario

Critical vendor outage or compromise

What the first hour is about
Establishing your exposure through their access and their data
The decision that cannot wait
Whether to cut the connection at all, and who actually owns that vendor relationship
ScenarioWhat the first hour is aboutThe decision that cannot wait
RansomwareDetermining spread and stopping it, before anything elseWhether to disconnect, and who is permitted to authorize it
Business email compromiseWorking out what the account touched and whether any money has already leftContacting the bank, and who can instruct a recall
Data exfiltrationEstablishing what left, when, and whose it wasWhether counsel needs to start a notification analysis now
Insider actionPreserving evidence before the person is awareWho gets told, in which sequence, and where HR and counsel come in
Critical vendor outage or compromiseEstablishing your exposure through their access and their dataWhether to cut the connection at all, and who actually owns that vendor relationship
How an engagement runs

Five steps, finishing with a rehearsal rather than a delivered file.

Four to six weeks including the tabletop, typically. The drafting is quick. What sets the pace is getting the decision makers into one room long enough to agree who holds which authority.
  1. 1

    Establish the decisions and the obligations

    Who declares an incident and at what threshold, who authorizes containment and within what boundary, who authorizes emergency spend and up to what value, who speaks externally, and what notification obligations apply from state statutes, sector regulation, contracts, or insurance, mapped with your counsel. These are agreed before anything is written.

  2. 2

    Write a core plan somebody will read

    Kept short, with the three questions answered on page one: is this an incident, who calls it, and what may be disconnected. Roles carry named people and named deputies. Communication arrangements assume neither the corporate network nor corporate email is available or trustworthy.

  3. 3

    Build scenario playbooks for the realistic cases

    Five playbooks of roughly two pages: ransomware, a compromised mailbox, data leaving the building, a trusted insider, and a breach at a critical supplier. They are separate because the opening hour is genuinely different in each. One catch-all procedure handles every case poorly and reads as though nobody had a specific incident in mind while writing it.

  4. 4

    Assemble and verify the contact pack

    Your responders, your carrier with both the policy number and the notification route, breach counsel, and each critical supplier with a named account team. Then we phone every one of them, because a list nobody has dialed is a set of assumptions, and two or three usually turn out to be wrong.

  5. 5

    Exercise, correct, and schedule the next one

    A tabletop with the genuine response team against a scenario that fits your business, producing corrections rather than a score. The document is then updated against what the exercise exposed, offline copies go out to the people who need them, and the next rehearsal is in the calendar before we leave, because scheduling it later never happens.

Straight answers

What organizations ask about incident response plans.

The reference point is the third revision of the NIST incident response publication, released in April 2025 as a CSF 2.0 Community Profile carrying the title Incident Response Recommendations and Considerations for Cybersecurity Risk Management. It is written to help organizations fold incident response through the whole of their risk management work, with the aims of better preparation, fewer and smaller incidents, and more efficient detection, response, and recovery. Separately, CIS Controls v8.1 places incident response management at Control 17 out of eighteen.

Shorter than almost anyone writes it. Ten minutes of reading for the core, with roughly two pages per scenario playbook. Length and use move in opposite directions, because nobody reads forty pages at two in the morning. Anything that is reference material rather than an instruction belongs in an appendix or a separate file entirely.

Three, and they turn up almost every time. There is no usable threshold for declaring, so nobody is sure when a problem becomes an incident. Containment is not pre-authorized, so hours evaporate between knowing something must be disconnected and being allowed to do it. And the contact list has never been dialed, so at least two of the names have moved on.

Anywhere the incident itself cannot reach. Kept only on the corporate file share or inside the collaboration platform, it is unreachable in precisely the scenarios it was written for. Printed copies in the hands of the people who need them, plus one copy held completely outside the environment, is deeply unglamorous and entirely the point.

For the scenarios that could realistically happen to you, yes, because the opening hour is genuinely different in each. Ransomware is a question of stopping spread. Mailbox compromise is a question of whether a payment has already gone. Exfiltration is a question of what left and whose data it was. Insider action is a question of preserving evidence before the person realizes anyone is looking. A single procedure handles all four poorly.

One named person and one named deputy, with the threshold written as things somebody can observe rather than as a judgment about how bad it seems. Whoever is holding the phone at three in the morning is rarely the most senior person available, and a threshold they can apply on their own is what turns hesitation into action.

Because that gap is where the damage compounds. In most companies the time between realizing a system has to come off the network and actually being allowed to do it runs to hours, and with ransomware those hours decide whether you lose one office or all of them. Pre-authorizing the action, with a clearly drawn boundary around it, removes the delay completely.

By naming the handoff, not by containing legal analysis. Every US state has a breach notification statute with its own definitions and timing, sector rules like HIPAA add federal obligations, and public companies carry SEC disclosure obligations for material incidents. The plan should say who calls breach counsel, at what point, and what facts the technical team must be assembling for them. The legal determinations belong with counsel; the plan makes sure they get the facts fast.

Yes, and it needs to name who speaks and to which audience. Customers, employees, any regulator with jurisdiction, your carrier, the press, and for public companies the securities disclosure workstream. Settling it in advance prevents the classic failure where three people say three different things on day one, which is a reputational injury that outlasts the technical one and is entirely self-inflicted.

Once a year at minimum, and more often where staff turn over or the risk is elevated. The rehearsal is not an examination to pass. It is the mechanism that corrects the plan while corrections still cost nothing. Every exercise we run finds something, and the companies that rehearse most often find the least, which is precisely the argument for doing it.

The people who would genuinely be involved, which extends well past IT. Whoever declares, whoever authorizes containment, whoever can commit money, whoever handles external communication, and someone from each function the incident would hit. An exercise attended only by the technology team rehearses the technical work and leaves every decision untested, and the decisions are the half that fails.

They overlap without being the same thing. Incident response covers handling the event itself: spotting it, containing it, removing it, and recovering. Business continuity covers how the company keeps trading while all that is going on. You need both documents, they should point at each other, and the moment one hands over to the other has to be written down rather than assumed.

Decide this beforehand rather than during. Bringing in specialist responders mid-incident means negotiating a contract while your systems are down, which is both slow and expensive. Whether that ends up as a retainer, an agreed rate card, or simply a named firm you have already spoken to, the decision belongs in the plan and not in the emergency.

Put the notification route and the policy number in the plan itself. Cyber policies commonly demand prompt notice, and many restrict you to responders drawn from an approved panel. Finding that out mid-incident, having already engaged a firm the policy will not cover, is a recoverable error that costs a great deal of money.

Scoping depends on how many entities and scenarios are involved and whether a tabletop is included, which it should be. Reviewing what you already have is faster than writing from scratch and is usually the right starting point, because most companies have something that needs correcting rather than nothing at all. Quoted per engagement.
Test your existing plan

Fifteen questions worth putting to the plan sitting in your drive right now.

Nearly everyone has a plan. These questions establish whether it would survive contact with a real incident, and you can answer all fifteen in an hour without any outside help.

Could you find it

  • Where is it stored?
    If the only answer is the file share, write that down as finding one.
  • Is there an offline copy?
    With the people who would need it.
  • When did anyone last open it?
    Access logs answer this honestly.
  • How long is it?
    Length is inversely related to use.
  • Would a new hire understand it?
    They may be the one on call.

Could you act on it

  • What is the declaration threshold?
    Observable conditions, not a judgment.
  • Who declares, and who deputizes?
    Both named, not roles.
  • Who can take a system offline?
    Pre-authorized, with a boundary.
  • Who can authorize emergency spend?
    And up to what value.
  • Who speaks to customers and press?
    Decided now, not then.

Is it current

  • Are all the contacts still employed?
    Check, do not assume.
  • Have the numbers been dialed?
    A contact pack is untested until called.
  • Does it reference systems you still run?
    Plans outlive platforms.
  • Is your insurer notification route in it?
    With the policy number.
  • When was it last exercised?
    If never, it is a draft.
Related reading

The pages around this one.

Incident response

The reactive service, for when something has already happened.

Learn more

Disaster recovery and business continuity

How the organization keeps operating while the incident is handled.

Learn more

Cybersecurity audit and compliance

Where incident readiness sits inside the wider control assessment.

Learn more
Next step

Pick three colleagues and ask where the incident response plan lives. Then ask when they last opened it.

If the first answer is the file share and the second is never, you have already found the two most common failures without our help. Both take weeks to fix. Neither can be fixed while an incident is underway.

Book an incident response planning sessionSee cybersecurity services

Related Services

Explore more solutions that work great with this service

Cyber Incident Response

Cyber incident response for US businesses. 24/7 on-call IR engineers

Learn more

Ransomware Protection

Layered ransomware protection for US businesses covering prevention

Learn more

Security Policy Development

Security policy development for US organizations: obligations

Learn more

SOC-as-a-Service

24/7 security operations delivered as a service

Learn more

Data Backup

Automated backup and data protection

Learn more

IT Compliance

HIPAA, SOC 2, NIST, CMMC, CCPA readiness

Learn more
GR IT SERVICES

IT services for US businesses,
delivering enterprise-grade solutions
remotely, coast to coast.

Microsoft CSP PartnerApple Jamf PartnerCISGuard

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support USA
  • IT AMC USA
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • hello@gritservices.io
  • gritservices.io

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie PolicyCCPA/CPRA