Getting incident response right the first time

An incident response plan is not a document. It is a set of decisions made in advance, so that the people involved are executing choices rather than making them at three in the morning with a customer on the phone.

That is the real purpose of this article. Almost every expensive mistake made during a security incident is a decision that was taken under pressure, by whoever happened to be present, that should have been settled months earlier by someone calm. What follows is a plan small enough to actually keep and specific enough to actually follow.

What to take away

Part one: decide these things now

Write the answers on one page. Print it. Keep a copy somewhere that does not depend on the systems it describes.

Two more things belong in the drawer with the printed page: current contact details for staff, and the recovery codes or break-glass credentials for your critical accounts. Both are useless stored only in the systems you may have lost.

Part two: the first hour

The goal of the first hour is not to fix anything. It is to stop the situation getting worse while preserving your ability to understand it. Work in this order.

1. Start writing things down, with times. One person, one document, from the first minute: what was observed, when, who did what, what was decided. This record is what your insurer, your lawyer, and any investigator will need, and reconstructing it later from memory is impossible. Note the time zone.

2. Contain by isolating, not by deleting. Disconnect the affected machine from the network: unplug the cable, turn off the wifi. Do not power it down if you can avoid it, because shutting down destroys evidence held in memory. Do not reimage it. Do not run cleanup tools. The compromised machine is the primary source of information about what happened and whether it happened elsewhere.

3. Cut off the account, properly. If credentials are implicated: reset the password, then revoke active sessions and tokens, then check registered MFA methods for anything the user does not recognize, then check mailbox rules, forwarding, delegated access, and connected applications. A password reset alone frequently leaves the intruder signed in.

4. Protect the backups. Verify that your offline or immutable copy is intact and unreachable from the affected environment. If a backup drive is connected, disconnect it. Do not let recovery capability be the next thing lost.

5. Stop the money. If any payment may have been redirected, call the bank immediately on a number you already had. Speed matters more here than in any other part of the response, and it degrades by the hour. Freeze pending payments and flag the account. A payment freeze announced before the migration starts is the cheapest business email compromise migration control.

6. Establish scope, roughly. Which systems, which accounts, which data, and when did it start? Rough answers are enough to decide the next step. Precision comes later.

7. Decide whether you are out of your depth. Read the next section and answer honestly.

Part three: when to call for help

There is no prize for handling this alone, and the cost of calling too early is a modest invoice. The cost of calling too late is usually evidence that has been destroyed and an intruder who is still inside.

Call a professional incident responder when any of the following is true: you find signs of someone with administrative access who is not you; ransomware has encrypted anything; you cannot determine how they got in; the intrusion appears to reach across more than one system; personal or regulated data may have left the business; or you have looked at the situation for an hour and cannot describe it clearly. Firms of this kind can be engaged at short notice, and your insurer or IT provider can usually point you at one.

Call your insurer immediately if you hold a cyber policy: before engaging anyone else. Many policies require notification within a defined period, some require you to use responders from an approved panel, and costs incurred before notifying may not be covered. Read your policy now rather than during the incident, and put the claims number on the printed page.

Call your lawyer early, especially if personal data, regulated data, or a payment fraud is involved. Notification obligations to regulators, customers, and partners vary enormously by jurisdiction, industry, and contract; they can be time-limited; and nothing in a general article can tell you which apply to you. This is the single most important thing to get from a professional rather than from the internet.

Report to law enforcement. For fraud and cybercrime, this is worth doing and is regularly skipped out of embarrassment. In the United States, the Cybersecurity and Infrastructure Security Agency and the FBI's Internet Crime Complaint Center accept reports from businesses; elsewhere, your national cybercrime reporting body or police service is the equivalent. Report promptly, particularly where funds have been transferred, because recovery efforts on redirected payments depend heavily on how quickly the banks and authorities are notified. A report also creates a record that insurers and regulators may expect to see. Involving law enforcement does not oblige you to stop your own recovery.

Part four: what not to do

Do not wipe the first machine. It is the only place the answer lives.

Do not tell staff to "keep quiet about it". You need reports from everyone who saw something odd, and silence guarantees you will miss half the picture.

Do not pay a ransom as a first move. It is a decision with legal, insurance, and practical dimensions: payment may be restricted depending on who is on the other end, and it does not reliably produce working decryption or prevent publication of stolen data. Involve your lawyer, your insurer, and a professional responder before this is even discussed.

Do not communicate externally before you know what is true. A statement that turns out to be wrong is harder to recover from than a short statement saying you are investigating and will update by a stated time.

Do not restore into an environment you have not cleaned. Restoring the same systems to the same conditions with the same credentials reinstates the intrusion, sometimes within days.

Part five: recovery

Recovery is where the preparation pays or does not.

Change credentials before you restore, not after: starting with administrators, the mail platform, the domain registrar, remote access, and anything reused. Assume every password held in the compromised environment is known.

Rebuild rather than clean where you reasonably can. Restore from a copy that predates the earliest evidence of compromise, which is why retention that reaches back matters.

Bring systems back in the order you wrote down, verifying each before the next. Watch closely for a period afterwards; re-entry attempts through a path you did not close are common, and the days after recovery are when they show up.

Tell affected people what you know, when you know it, in plain language, on the advice of your lawyer as to what must be said and to whom.

Part six: the review that is worth doing

Hold it within a fortnight, while memory is fresh, and hold it blamelessly. If people fear the review, you will get a sanitised account and learn nothing.

Four questions are enough. How did they get in? What let it spread? What slowed us down? What would we change? Then convert the answers into three specific, assigned, dated tasks, not fifteen aspirations. A review that produces a long list produces nothing.

Update the printed page. Almost every incident reveals that a phone number was wrong, a contact had left, or a decision had no owner. Fixing those takes ten minutes and is the highest-return work in the whole exercise.

A note on rehearsing

You do not need a formal exercise. Sit four people around a table for forty minutes and read out a scenario: the finance manager's mailbox is sending invoices to customers with different bank details. Then work through it aloud. Who declares? Who calls the bank? Who tells the customers? Who has the insurer's number? Where are the recovery codes?

You will find two or three broken assumptions in the first half hour, which is the entire point. Do it once a year, and after any significant change to your systems or your staff. The related training practices are covered in security compliance training.

The United States Federal Trade Commission publishes general data security guidance for businesses. It is not a substitute for advice on what your particular business must do after an incident, which should come from a lawyer in your jurisdiction.

Common questions

We are eight people. Is a plan really worth writing?

The page is worth an hour precisely because there are eight of you. A large organization has people whose job is to work this out at midnight; a small one has whoever is awake, and the page is what stands in for the missing expertise.

How do we know whether something is an incident at all?

You often cannot, which is why the declaring threshold should be deliberately low. Declaring and standing down costs almost nothing. Waiting for certainty costs the hours that decide how far something spreads.

Should we tell customers straight away?

Tell them something true and small, and take advice on what you are obliged to say and by when, because that depends on your jurisdiction, your industry and your contracts. Saying you are investigating and will update by a stated time is almost always available; saying what happened before you know is what causes lasting damage.

Do we need a retainer with a response firm?

Not necessarily. Check what your insurer already provides before buying one separately. Many policies name responders and require notification first.

What every business needs regardless is the printed page, the account controls in identity and access that make cutting somebody off a five-minute job, and the ability to isolate a machine without wiping it. That ability is part of the tooling discussed in endpoint security.

How do we rehearse without disrupting the business?

Forty minutes, four people, one scenario, once a year. The Cybersecurity and Infrastructure Security Agency publishes tabletop exercise packages with the scenarios already written, which removes the usual reason this never happens. Most of what you find will be a wrong phone number or a decision with no owner, and both are ten-minute fixes.

Does any of this reduce how often we need it?

Not directly. What reduces the frequency is the account and mail work in phishing defense and the ordering of controls in security foundations. This page is about the day those fail.