Preparation: the phase that decides the other four

Why this matters

The previous lesson claimed preparation decides how the rest of the lifecycle goes. This one makes that concrete, because the claim is easy to agree with and hard to act on — preparation has no deadline, no incident forcing it, and no visible reward.

For the exam, preparation activities are a defined set and questions ask you to recognise them. For the job, this is where a response is actually won or lost: during an incident you do not rise to the occasion, you fall to the level of what you set up beforehand.

The lesson

The incident response plan, and who has read it

Nearly every organisation has a plan. A much smaller number have one that functions.

What a working plan contains:

• Scope and definitions. What counts as an incident, and the severity tiers with examples rather than adjectives.
• Roles and contacts, with names, deputies and out-of-hours numbers.
• Declaration and escalation criteria — the triggers from lesson 28.
• Decision authority: who may disconnect, who may take a system down, who approves notification.
• Communication protocol: who is told, by whom, on what channel, how often.
• Playbooks for the scenarios you are actually likely to meet.
• External contacts: retainer, insurer, legal, regulator, law enforcement.
• Evidence handling requirements, which lesson 31 covers.

What separates a plan that works from a document that exists:

• It is short enough to read during an incident. A 90-page plan is read by nobody at 3am. The operational part should be a few pages, with detail in appendices.
• It is available when systems are not. A plan stored only on the file server that ransomware just encrypted is not a plan. Printed copies and offline copies are unglamorous and repeatedly decisive.
• People have read it before the day. The honest test is to ask three people, without warning, who may authorise disconnecting a production database. Divergent answers mean the plan is not in force regardless of what it says.
• It is current. Plans naming people who left, systems retired and a phone bridge that no longer exists are common, and every stale entry costs minutes at the worst moment.

Roles, authority and who can unplug a server

Authority is the single most useful thing to settle in advance, because it is the thing that cannot be improvised.

The recurring scene: an analyst is confident a production server is compromised and actively being used. Isolating it stops the intrusion and stops the business. The analyst does not have that authority. The person who does is asleep, and the escalation path is undocumented. The attacker continues working for forty minutes while a group discusses who is allowed to say yes.

Preparation removes that by deciding in advance:

• Who may isolate a host, and whether an analyst may do it unilaterally when a defined threshold is met. Many mature teams grant exactly this, with an obligation to notify immediately rather than ask first.
• Who may disable an account, including an executive's or an administrator's.
• Who may take a customer-facing service down.
• Who may engage the external responder, which usually has a cost attached and therefore an approver.
• Who speaks to customers, to regulators, to the press. Never the analyst — a point from lesson 1 that becomes acute here.

Common role structures to recognise: the incident commander who runs the response and makes decisions but does not perform the technical work; the technical lead; the scribe, whose contemporaneous notes matter for lesson 38; the communications lead; and the business or system owner who carries the impact decision. On a small team one person wears several hats, and the roles still want naming, because "everyone is investigating and nobody is deciding" is the characteristic failure of a small response.

The rule underneath all of it: the person doing the analysis should not also be the person managing the response. Investigating requires depth; commanding requires breadth and a clock. Trying to do both badly is how an incident runs for six hours without anyone noticing nobody has told the business.

Retainers, escalation contacts and out-of-band comms

Three things that must exist before they are needed, because each takes days to arrange and minutes to use.

Incident response retainers. A contracted external responder with agreed rates, an agreed response time and — the part people forget — an onboarding already done. A retainer where the firm has never seen your environment, holds no access, and has to sign paperwork before starting costs you the first day. Whether one is justified is a business decision, but discovering the question during an incident guarantees the slow answer.

Escalation contacts, maintained and reachable: executives, legal, privacy, communications, HR for insider cases, the cyber insurer (many policies require notification within a short window and may require using their panel firms), law enforcement, and the regulator where a sector requires it. Contacts decay constantly, and a contact list is only real if it has been tested.

Out-of-band communications, which is the one to remember for the exam and in practice. If the corporate network, email or identity provider may be compromised, coordinating the response over them tells the attacker your plan and may not work at all. A response run over the email system the attacker is reading is a genuine and repeated failure.

Out-of-band means: a separate messaging channel not tied to corporate identity, a conference bridge that does not depend on the affected infrastructure, phone numbers on paper, and pre-agreed authentication so people can be sure who they are talking to. Set up in advance, tested occasionally, and specified in the plan — lesson 39 goes further into using it.

Tabletop exercises that find real gaps

A tabletop is a discussion-based walkthrough of a scenario: no systems touched, the team talks through what they would do while a facilitator introduces complications.

It is the cheapest way to find the gaps that only appear under pressure — and in practice, what it finds is rarely technical. It is that nobody knew who declares, that the plan is on the encrypted file server, that the only person who can restore the backups is on leave, that legal expects to be told immediately and has never been, or that nobody has the CEO's mobile number.

What makes an exercise find real gaps rather than confirm comfort:

• A realistic scenario — the incidents you are plausibly going to have, not a cinematic one.
• Injects that change the picture. The attacker still has access. A journalist calls. Backups are encrypted too. The compromised account belongs to the person in the room.
• The real participants, including legal, communications and an executive. A tabletop of only the security team tests only the security team, and the gaps are usually at the boundaries.
• A facilitator willing to push. "You say you would isolate it. Who authorised that? Call them now."
• No grading. The moment it becomes a performance, people describe the procedure instead of what they would do.
• Written findings with owners and dates, tracked like any other action. An exercise whose findings are not tracked is an afternoon out.

Escalating forms are worth knowing: a tabletop (discussion), a functional exercise (systems and tools actually used), and a full simulation or purple-team engagement where an adversary emulation runs against a live environment and the team responds for real.

Readiness you can verify before you need it

The theme of this course applied to preparation itself: a plan that exists and a plan that works look identical from outside, so preparation must be measured, not asserted.

Things you can verify now, each answering a question you will otherwise ask during an incident:

• Log retention, by source. How far back can you actually go? Compare it against realistic dwell time. Seven days of firewall logs will not answer a question about last month.
• Telemetry coverage. What proportion of hosts report to EDR, against an independent inventory. Lesson 18's point: coverage measured against your own tool's list is circular.
• Backup restore tests, with dates and durations. Not "backups ran" — a restore completed, of the thing that matters, timed.
• Backup isolation. Would the backups survive the compromise of the domain? Lesson 34's point, and it is the one that decides ransomware outcomes.
• Contact list freshness, tested rather than reviewed.
• Plan availability offline, confirmed by finding a copy without the network.
• Access for responders, including the external firm: accounts that exist, work, and are not dependent on the identity provider that may be compromised.
• Tooling readiness: forensic images can be taken, memory can be captured, someone has done it before on this platform.
• Time synchronisation, which sounds trivial until you build a timeline across systems whose clocks disagree by minutes and cannot tell what happened first.

Each of these is a number or a date, which means each can be reported, tracked and improved — and each converts a question you would otherwise discover the answer to at the worst possible moment into one you already know.

Topics this lesson owns

• [x] The incident response plan, and who has read it
• [x] Roles, authority and who can unplug a server
• [x] Retainers, escalation contacts and out-of-band comms
• [x] Tabletop exercises that find real gaps
• [x] Readiness you can verify before you need it