Incident Response Planning Without a Security Team

Most incident response plans fail for a reason that has nothing to do with technical depth: nobody knows who decides. When something is wrong at 11pm on a Friday, the questions that stall a response are who declares an incident, who is authorized to take a revenue-generating system offline, who calls the insurer, and who talks to customers. An organization with no security team can answer all four in advance. That is most of the plan.

This is how we build one with the staff a growing firm actually has — a general IT lead, an operations manager, a finance lead, and an executive who can make a business call.

Start with the decision rights, not the runbook

Write four names and four thresholds before writing anything technical.

The delegate column is not decoration. Incidents disproportionately begin outside business hours, and a plan whose single decision-maker is on a plane is a plan that stalls.

The current NIST model, and why it changed

NIST SP 800-61r3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, finalized April 3, 2025 — replaced the familiar four-phase life cycle from the prior revision with a model built on the six CSF 2.0 Functions. NIST’s own explanation of the change is worth quoting in substance, because it reframes what a small organization should build.

Under the older model, incidents were relatively rare, narrow in scope, and usually resolved within a day or two, so it made sense to treat response as a separate set of activities performed by a separate team. NIST’s assessment is that this no longer holds: incidents occur frequently, cause more damage, and recovery often takes weeks or months. Response is now treated as a part of cybersecurity risk management that should be integrated across organizational operations, and lessons learned should be shared as soon as they are identified rather than held until after recovery concludes.

The practical consequence for an organization without a security team: you are not building a separate response capability. You are adding decision rights, contacts, and rehearsal to functions you already run. GOVERN, IDENTIFY, and PROTECT are the preparation that reduces how often and how badly this happens; DETECT, RESPOND, and RECOVER are the response itself; and the Improvement category inside IDENTIFY is where lessons from every function feed back.

The first hour, on one page

The single highest-return artifact is a first-hour guide short enough that someone under stress will actually follow it. Ours fits on one page and covers:

1. Do not power off; do isolate. Disconnecting from the network preserves memory-resident evidence that a shutdown destroys. Say this explicitly, because the instinct is to pull the plug.
2. Start a written timeline immediately. Time, who, what was observed, what was changed. Handwritten is fine. This becomes the basis of every later report, insurance claim, and notification decision.
3. Preserve, do not clean. Do not delete files, reimage machines, or reset every password until someone has decided what evidence is needed. Well-intentioned cleanup is the most common way small organizations destroy their own forensic record.
4. Make the four calls in order. Incident declarer, executive decision-maker, insurer’s breach hotline, counsel. The insurer call is early on purpose: many policies require prompt notice and many carriers direct which response firms may be engaged. Calling a vendor first can create a coverage problem.
5. Contain what is understood. Disable compromised accounts, revoke sessions and tokens, block the identified path. Do not begin broad remediation before scope is understood.
6. Say nothing externally yet. Route every inbound question to the named communicator.

Print it. Keep a copy off the network, because the plan stored only on the file share that is currently encrypted is not available. A ready-to-print version of exactly this is our incident response first-60-minutes decision card.

The contact sheet nobody has until they need it

A page with names, mobile numbers, and account numbers, stored offline and refreshed quarterly:

• Incident declarer and alternate; executive decision-maker and delegate.
• Cyber insurance carrier, policy number, and the 24/7 breach hotline. Also record any panel requirement — whether the policy restricts which response firms may be used.
• Outside counsel with breach experience, engaged in advance rather than searched for at 11pm.
• Incident response provider. An organization without an internal security team must have a named firm that performs live digital forensics and incident response, because that work requires specialist capability and is not something an advisory relationship substitutes for. Confirm the engagement basis before an incident — a retainer, a pre-negotiated rate, or at minimum an existing contact.
• IT provider or MSP, with the escalation path and after-hours number.
• Law enforcement. The FBI’s Internet Crime Complaint Center is the federal reporting channel and the FBI recommends filing a report; CISA is the federal channel for reporting cyber incidents.
• Key vendors and customers whose contracts contain notification clauses, with the notice window each one requires.

What your obligations already require

Many organizations that believe they have no compliance surface already have a written-plan obligation. Non-banking financial institutions under the FTC Safeguards Rule are the clearest example: 16 CFR 314.4(h) requires a written incident response plan designed to respond to and recover from any security event materially affecting the confidentiality, integrity, or availability of customer information, and it enumerates seven areas the plan must address — the plan’s goals, the internal response processes, clear roles, responsibilities and levels of decision-making authority, internal and external communications and information sharing, requirements for remediating identified weaknesses, documentation and reporting of events and response activities, and evaluation and revision of the plan after an event.

The same rule at 16 CFR 314.4(j) requires notice to the FTC no later than 30 days after discovery of a notification event involving the information of at least 500 consumers, and treats an event as discovered on the first day it is known to any employee, officer, or agent other than the person who committed the breach. That last clause is the one to internalize: the clock starts when a staff member knows, not when leadership is told.

Organizations handling protected health information have parallel duties under the HIPAA Security Rule at 45 CFR Part 164 Subpart C, and contractual notice windows in customer agreements frequently run shorter than any statute. Inventory those windows now; they drive the communication plan far more than most teams expect.

Rehearse it, cheaply

A tabletop exercise is a facilitated conversation, not a technical test, and a useful one runs ninety minutes with six people in a room. Pick a scenario with a business decision embedded in it — a finance mailbox compromised and a payment already sent, a shared drive encrypted on a Friday afternoon, a vendor notifying you that your data was in their breach. Walk the clock. Stop at each decision point and ask who decides, on what information, by when.

What comes out is never the scenario. It is that nobody knew the insurer requires notification within a defined window, or that the person authorized to take the ERP offline is the same person who would be doing the technical work, or that the contact sheet lists a phone number belonging to someone who left last year. Fix those; run it again in six months with a different scenario.

For leaders looking for a plain-language starting structure, CISA’s Cyber Essentials organizes small-organization readiness into six Essential Elements — Yourself, Your Staff, Your Systems, Your Surroundings, Your Data, and Your Crisis Response — and is explicitly written for leaders of small businesses and small government agencies rather than for security specialists.

Where outside help fits

The honest division of labor for an organization without a security team: you own the decision rights, the contact sheet, and the rehearsal. A specialist owns live response when it happens. An advisor owns the planning, facilitation, and the after-action work in between.

That middle role is our incident response and ransomware readiness engagement — a bounded two-to-four-week method that reviews evidence and dependencies, maps response roles and decision rights, facilitates executive and technical tabletop exercises, records recovery objectives and representative restore-test evidence, produces the first-hour guide, and delivers an after-action roadmap. It is readiness work, and the boundary is explicit: it is not live digital forensics and incident response, not breach counsel, not malware eradication, and not a 24/7 retainer. Live-response handoffs to a specialist firm stay named in the plan.

The recovery half of readiness deserves its own drill; see how to prove your backups will actually restore. And if the underlying question is who should own security direction at all, vCISO vs MSP vs MDR: who owns what draws those lines.

FAQ

Can a company without a security team have a real incident response plan?

Yes. The highest-value components — named decision-makers with alternates, written declaration thresholds, pre-approved authority to take systems offline and to spend on outside help, an offline contact sheet, and a one-page first-hour guide — require organizational decisions rather than security expertise. What cannot be substituted is live digital forensics and incident response capability, which should be named as an external specialist in the plan before an incident occurs.

What does NIST SP 800-61r3 change about incident response?

Finalized April 3, 2025, it replaces the four-phase life cycle of the prior revision with a model built on the six CSF 2.0 Functions and is published as a CSF 2.0 Community Profile. NIST’s rationale is that incidents are now frequent, more damaging, and often take weeks or months to recover from, so response should be integrated into cybersecurity risk management rather than treated as a separate activity by a separate team, with lessons learned shared as soon as they are identified.

What should we do in the first hour of a suspected incident?

Isolate rather than power off so memory-resident evidence survives; start a written timeline; preserve rather than clean, since reimaging and mass password resets can destroy the forensic record before scope is known; call the incident declarer, the executive decision-maker, the insurer’s breach hotline, and counsel in that order; contain only what is understood; and route all external questions to the named communicator. Keep the guide printed and off the network.

Are we legally required to have a written incident response plan?

It depends on what you are. Non-banking financial institutions under the FTC Safeguards Rule are required by 16 CFR 314.4(h) to establish a written incident response plan addressing seven specified areas, and 16 CFR 314.4(j) requires FTC notification no later than 30 days after discovering a notification event involving at least 500 consumers. Entities handling protected health information have parallel duties under the HIPAA Security Rule, and customer contracts frequently impose shorter notice windows than any statute. Confirm your specific obligations with counsel.

How often should we run a tabletop exercise?

Twice a year is a reasonable cadence for a ninety-minute facilitated scenario, with an additional exercise after any material change to the business, the technology estate, or the response team. Vary the scenario each time, and re-run it after any real incident so the after-action findings are validated rather than filed.

What this guide is / What it is not

What it is: A practitioner method for building an incident response plan without an internal security function, anchored to NIST SP 800-61r3 (April 3, 2025), NIST CSF 2.0, CISA’s Cyber Essentials, the FTC Safeguards Rule at 16 CFR 314.4, and the HIPAA Security Rule at 45 CFR Part 164 Subpart C. What it is not: Legal advice, an audit, a certification, an attestation, or a guarantee of any regulatory, insurance, or litigation outcome. A plan reduces and organizes risk; it does not prevent incidents. DSE provides readiness planning, facilitation, and after-action advisory work — not live digital forensics and incident response, breach counsel, malware eradication, or 24/7 monitoring or response. Notification obligations are legal determinations for your counsel.

The Bottom Line

The parts of incident response that most often fail are organizational, and an organization without a security team can fix all of them: name the decision-makers and their alternates, write the declaration threshold down, pre-approve the authority to disconnect a system and to spend on help, keep an offline contact sheet with the insurer’s hotline on it, print the first-hour guide, and rehearse twice a year. Then name the specialist who does live response, before you need them. That is a real plan, and it is buildable in weeks.