Veteran Forge Strategies Deck Log graphic: FIRST HOUR — contain, don't destroy the evidence. Three status tiles: isolate first not power off, the DFARS 72-hour reporting clock, and a rehearsed tabletop plan.
| |

You Can’t Write the Plan During the Fire

ByJohn Farmer

The first hour of a security incident is the one where you have the least information and the most adrenaline, and that combination is exactly why most of the damage in a breach gets done by the people responding to it, not the attacker.

The instinct is almost always wrong

Something looks off — a ransom note on a desktop, a login from a country nobody in the company has ever traveled to, a folder full of files that were not there yesterday. The instinct in that moment is one of two things: panic and start deleting, or freeze and wait for someone else to act. Both cost you.

The delete instinct feels productive. It is not. Wiping the obviously-bad file, killing the process, powering the machine off — these are the moves of someone trying to make the scary thing go away, and every one of them destroys something you will wish you still had an hour later. The freeze instinct is quieter but just as expensive: nobody wants to be the one who overreacts, but the clock does not pause to be polite, and every minute of “let’s watch it a bit longer” is a minute the attacker keeps working.

Neither instinct is a plan. That is the actual subject of this article — not the technology of incident response, which is documented well elsewhere, but the fact that the technology only works if somebody decided how to use it before the day it mattered.

What the first sixty minutes actually call for

Strip out the vendor language and the first hour of a competent response is four things, done in order:

  • Detect. Something triggers the awareness — a monitoring alert, a user report, a vendor notification. How fast this happens is a different subject I have written about separately, and it matters here because everything downstream starts later when detection is slow.
  • Contain. Stop the situation from spreading without destroying what you will need later. This is the step people get wrong most often, and it gets its own section below.
  • Preserve. Capture the state of what happened before it is gone — logs, alerts, a forensic image if you have that capability, and at minimum a written timeline of what was observed and when.
  • Assess scope. What is actually affected — one workstation, one account, or something that reaches the network, the backups, and the data itself. Everything after the first hour depends on scope, and guessing wrong in either direction is expensive: overreacting shuts down a business that did not need to stop; underreacting misses the exact thing the attacker is about to use next.

None of these four steps is exotic. Any competent IT person can execute all four. What actually determines whether the first hour goes well is whether someone had already decided, on a calm afternoon months earlier, who does which of these and in what order — because on the day it happens there is no time to have that conversation, and the room usually holds more opinions than the plan has space for.

Contain, don’t destroy

This is the piece of advice that sounds obvious and still gets ignored constantly: isolate the affected system. Do not power it off.

The reasoning is mechanical, not superstitious. A running machine holds evidence in memory that a powered-off machine does not — active processes, open network connections, loaded code that never touched the disk, the specific fingerprints of how something got in. Pull the power and that evidence is gone permanently; there is no recovering it afterward. A reboot can be just as destructive, because rebooting can trigger the exact persistence mechanism — a scheduled task, a startup entry — that the intrusion planted for that purpose.

Isolating the machine gets you almost everything containment needs without that cost: disconnect it from the network — pull the cable, disable the switch port, drop it into a quarantine VLAN — and leave it running and otherwise untouched. The system can no longer talk to anything else, which stops lateral movement and command-and-control, but the evidence inside it survives for whoever investigates next, whether that is you, an outside firm, or eventually an insurer or an investigator.

The same logic applies to the instinct to manually delete the “bad” files the moment you find them. A file you found is a file you already know about. Deleting it does not make you safer — it just makes it harder to prove afterward what actually happened, which matters more than it sounds like it should. The federal section below gets into exactly why.

First, an honest correction

I want to flag something most incident-response advice glosses over, including some of what I said in the LinkedIn post this article grew out of.

The classic “detect, contain, eradicate, recover” language that nearly everyone — myself included — has used for years traces back to NIST SP 800-61, the government’s core incident-handling guide. That document was substantially rewritten in April 2025. Revision 3 retired the old four-phase lifecycle model and retitled itself entirely — Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile — and now maps incident-response activity onto the five functions of the NIST Cybersecurity Framework 2.0 (Identify, Protect, Detect, Respond, Recover) instead of a standalone phase model. The tactics have not changed; the document that organizes them has, and most of the guides still circulating online have not caught up.

The more consequential correction runs the opposite direction from what I told readers of the disaster recovery article on this site. There, the point was that NIST SP 800-171 — the standard governing anyone who handles Controlled Unclassified Information — explicitly excludes contingency planning from its scope. Incident response gets the opposite treatment. It is one of the fourteen required control families in 800-171 itself, family 3.6 under Revision 2 (renumbered 03.06 under Revision 3), and it is specific: establish an operational incident-handling capability covering preparation, detection, analysis, containment, and recovery; track, document, and report incidents to the right internal and external officials; and test the capability. If you handle CUI at all — not only if you are a DoD prime under a DFARS clause — you already carry a compliance obligation to have a tested incident-response plan, not just an operational best practice you can get to eventually.

The call list, decided in advance

Who gets called, and in what order, is a decision that needs to already exist before the incident does. Working it out on the day wastes exactly the time you do not have, and it tends to produce disagreements between people who each assumed they already knew the answer.

A workable order for a small or mid-sized organization: internal leadership first — whoever has authority to make spending and communication decisions gets pulled in immediately, not after IT has “figured out what’s going on.” IT or your MSP next, if they are not the ones who detected it. Legal counsel early rather than late, because attorney-client privilege can shape how the investigation gets documented and what becomes discoverable later — a detail that matters more than most small businesses realize until the first time it does. Cyber insurance next; most policies require notification within a specific window to preserve coverage, and many carriers maintain a panel of approved forensic and legal vendors they expect you to use, which is worth knowing before you have already hired someone else. Affected parties — customers, partners, employees — come after the picture is clear enough to say something true, not before.

Write down names, not roles. “Whoever is available in IT” is not a call list; it produces exactly the freeze-and-wait behavior the plan exists to prevent. A named person and a named alternate for each item on that list is the difference between a plan and a suggestion.

Out-of-band, because the channel might be the problem

If email is the thing that is compromised, coordinating the response over email is coordinating with the attacker in the room. The same is true of a chat platform tied to the identity provider that was just breached, or a phone system that routes through the compromised network.

This does not require anything sophisticated. It requires deciding in advance what the fallback channel is — personal cell numbers, a group text, a phone tree printed on paper and kept somewhere that is not “in a file on the server” — and making sure the people who need it have it before they need it. I made almost the identical point in the disaster recovery piece on this site, and it is worth repeating here because it applies just as directly: a contact list that lives inside the system that just went down is not a contact list you have.

The plan you rehearse before the fire

An incident-response plan nobody has run through is a plan with unknown gaps, and the day of a real incident is an expensive time to discover them.

A tabletop exercise does not require a consultant or a lost weekend. Pick a specific, plausible scenario — “a workstation in accounting started encrypting files at 8:40 a.m. Tuesday, discovered when a user called the help desk” beats “there was a cyber incident” — and walk it out loud, minute by minute, with the actual people who would be involved. Every time someone says “I think” or “we’d probably,” write it down. That is not a sign the exercise is going badly; that is the exercise working, because those are exactly the gaps you would rather find on a Tuesday afternoon in a conference room than during the real thing.

Questions worth asking out loud during that walkthrough: who has the authority to isolate a production system, and do they know it? Who calls the cyber insurer, and does anyone actually have the policy number and the carrier’s incident hotline saved somewhere reachable? If the answer to “who is our incident response point of contact” is a job title rather than a name, that is a finding, not a technicality. Run the exercise once a year, and again after any significant change to the environment — a new line-of-business application, a new remote-access method, a merger. Environments drift, and a plan built for last year’s network is a plan built for a network that no longer exists.

The federal clock: DFARS and the 72 hours

For a federal contractor, the operational advice above sits underneath a specific, contractual deadline, and it is worth knowing exactly what it says rather than the version that circulates secondhand.

DFARS 252.204-7012 requires a contractor to “rapidly report” a cyber incident that affects a covered contractor information system, or the covered defense information residing on it, and the clause defines “rapidly” with a specific number: within 72 hours of discovery. The report goes to the Department of Defense through the DIBNet portal, and submitting it requires a medium-assurance certificate obtained in advance — not something to discover you need at hour seventy.

The part that gets missed is what comes bundled with the reporting obligation, not just the deadline. The same clause requires contractors to preserve and protect images of every known affected system, along with relevant monitoring and packet-capture data, for at least 90 days from the date the report is submitted. That is a direct, contractual reason the contain-don’t-destroy advice above is not optional for a defense contractor — it is specifically the evidence you are obligated to still have three months later, and powering off the wrong machine on day one can put you in breach of a clause that has nothing to do with the original incident.

Two clarifications worth having straight, because both get muddled in secondhand advice. First, the 72-hour clock is DFARS-specific — it applies when covered defense information is involved, which in practice means Department of Defense contracts. It is not automatically the deadline for every federal engagement; other agencies carry their own incident-reporting terms, and the honest move is to read the actual contract clause rather than assume DFARS timing applies by default. Second, and this is the point from the section above worth restating here: even a contractor with no DoD-specific clause, who simply handles CUI through some other agency relationship, already carries an incident-response obligation under NIST SP 800-171 itself — the tested-capability requirement in family 3.6 does not wait for a DFARS trigger to apply. CMMC Level 2, which is built on 800-171, inherits the same requirement; CMMC Level 3 adds a 24/7 security operations capability and a requirement to deploy an incident-response team within 24 hours, which is a meaningfully different operational commitment than Level 2 and worth knowing before assuming the two levels ask for the same thing.

Where this usually goes wrong

  • Powering off instead of isolating. Feels decisive. Destroys the evidence that would have told you what actually happened.
  • No named decision-maker. Everyone waits for someone else to declare an incident, and the meter runs the whole time.
  • The call list is a list of roles, not people. “IT will handle it” is not an answer at 2 a.m.
  • Coordinating the response on the compromised channel. If email is down, the email thread about the outage is not reaching anyone.
  • Treating the plan as a document instead of a rehearsal. Written once, filed, never walked through out loud.
  • Assuming DFARS timing applies to every contract. Read the actual clause; do not assume the 72-hour number by default.
  • Deleting the “obviously bad” file. Feels like cleanup. It is destruction of the one thing an investigator needed to see.
  • No plan for how legal and insurance fit the timeline. Called too late, after decisions get made that a carrier’s panel counsel would have made differently.

You write the plan when it’s boring

The plan is not useful on the day of the incident. It is useful months before, written on an ordinary Tuesday when nothing is wrong, precisely because that is the only time anyone can think clearly about who calls whom, what gets isolated instead of destroyed, and what the business is willing to say publicly before it knows the whole story.

Small business or federal contractor, the clock starts the same way — the moment something looks wrong, whether anyone in the building is ready for it or not. The organizations that come through a bad day looking competent are rarely the ones with the best tools. They are the ones who already had the argument about who does what, on a day when the answer did not cost them anything.

Write the plan now. You do not get to write it during the fire.

Veteran Forge Strategies is an SBA-Certified Service-Disabled Veteran-Owned Small Business providing IT infrastructure, operations, and cybersecurity support to small businesses and federal clients from Northern Virginia. If your organization has never walked through what the first hour of an incident actually looks like, that conversation is worth having before you need it — get in touch. You can also read about how a fractional IT engagement works, or browse the rest of the Deck Log.

Similar Posts