Most organizations that struggle through a security incident do not struggle because the intrusion was technically advanced. They struggle because nobody knew who could approve taking a server offline, the logs that would have answered the first question had expired, and the insurer's hotline number sat in a document on the encrypted file share.
These are preparation problems, and they are far easier to fix on a quiet week than during an incident. This article sets out what a security or IT leader should have in place beforehand, and how to tell whether it would hold.
Where the first hours go
Early in an incident, the team needs to answer a small set of questions. What is affected, how did the intruder get in, are they still active, and what must be contained now. None of these is unusually hard when the data and the authority exist.
The time goes elsewhere. Typical delays include:
- waiting for someone senior enough to approve isolating a production system
- finding out that VPN or identity logs cover only the last few days
- searching for a contact at the hosting provider, the insurer or outside counsel
- discussing the incident over the same email or chat tenant the intruder may be reading
- discovering that the one administrator who understands the backup system is on leave
NIST SP 800-61, the public incident response guidance from the US National Institute of Standards and Technology, treats preparation as part of incident response for this reason. Revision 2 describes a life cycle of preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. Revision 3, published in 2025, supersedes it and organizes its recommendations around the six functions of the NIST Cybersecurity Framework 2.0. In both, the work done beforehand sets the limits of what responders can do.
The minimum plan
A usable plan is short. It is a few pages that people can follow under stress, not a policy document written for an auditor. It needs to settle three things.
Roles and decision authority
Name an incident lead, a technical lead, a communications owner and an executive sponsor, each with a deputy. Then write down who may authorize specific actions without calling a meeting: isolating a host, disabling any user account including an executive's, blocking a business application, and shutting down a production service or a site.
Pre-authorize the low-regret actions. If the on-call analyst can isolate a workstation or revoke a session on their own judgment, containment starts at once. Reserve escalation for actions with real business cost, and state who decides when the named person cannot be reached.
Out-of-band communications
Assume that corporate email, chat and the identity provider may be unavailable or monitored by the intruder. Set up a separate channel in advance, with accounts that do not depend on corporate single sign-on. Include a conference bridge and a place to keep notes, and test that every responder can reach them.
The contact list
Keep the list printed or stored offline, and review it on a schedule. It should include:
- internal responders and deputies, with personal phone numbers
- outside legal counsel, ideally with incident experience
- the cyber insurer's claims hotline, the policy number and any conditions on notification or approved vendors
- regulators and national reporting bodies that apply to you, with their deadlines, since several regimes set deadlines measured in hours
- main suppliers: cloud and hosting providers, managed service providers, payment processor, telecom
- a retained or named external responder
The last item deserves attention. Negotiating a contract and a non-disclosure agreement with an incident response firm while systems are down uses up the hours that matter most. A retainer, or at least a named firm with the paperwork already signed, removes that delay.
Logs and evidence an investigation can use
Log sources and retention
Investigators reconstruct a timeline from logs. If a source was never collected, or was kept for a week, that part of the timeline stays blank. The scope of the incident then has to be assumed instead of shown, which usually means a wider response and a harder conversation with regulators and customers.
| Log source | What it answers |
|---|---|
| Identity provider and directory | Which accounts signed in, from where, with which factor, and which privileges changed |
| Endpoint telemetry (EDR, process and command-line events) | What ran, on which host, under which user, and what it touched |
| Email (message trace, mailbox audit, rule changes) | Which messages arrived, what was accessed, which forwarding rules or delegates were added |
| Cloud control plane | Which API calls created, changed or deleted resources, keys and roles |
| VPN and remote access | Which external addresses connected, as which user, and for how long |
| DNS and web proxy | Which hosts contacted the intruder's infrastructure, and when that began |
Default retention is often too short. Many platforms keep sign-in, audit or control plane events for a period measured in days or a few months unless you export them, and the period can depend on license tier. AWS CloudTrail event history, for example, covers only the last 90 days of management events unless a trail delivers them to storage. Initial access often precedes detection by a long way, so the oldest events are the ones most needed.
Check each platform you depend on, send its logs to storage you control, and set retention by how far back an investigation would need to look. Store them where an administrator of the source system cannot delete them, and keep clocks synchronized so events from different systems can be ordered. A managed SOC or internal detection team uses the same data, so the cost serves two purposes.
Evidence preservation basics
The first people to touch an affected system are usually IT staff, not forensic specialists. A few rules, taught in advance, protect the evidence.
- Isolate, do not power off. Disconnect the host from the network or use the EDR isolation function. Powering off destroys memory contents, which may hold the intruder's tooling, active network connections and credentials in use.
- Do not reimage before imaging. Rebuilding a machine to get a user working again erases the record of how it was compromised. Capture memory and a disk image first, or a snapshot for virtual machines and cloud instances.
- Record timestamps in UTC. Note who did what and when, in one time zone. Mixed local times are a common source of timeline errors.
- Maintain chain of custody. For each item, record who collected it, how, its hash, where it is stored and who has accessed it. This matters if the case reaches litigation, an insurance claim or law enforcement.
- Avoid privileged logins to suspect hosts. Signing in with a domain administrator account can expose that credential to the intruder.
There is one exception to the first rule. Where encryption is visibly in progress and network isolation is not possible, shutting down may limit the damage at the cost of memory evidence. Decide in advance who makes that call.
Scenario playbooks and tabletop exercises
Playbooks for likely scenarios
A general plan does not tell an analyst what to do at the second step. Write short playbooks for the scenarios most likely to affect your organization. Four cover most needs.
- Ransomware. Isolation at scale, protecting backups and the identity system, assessing data theft as well as encryption, the restore order for business services, and who handles legal advice, the insurer and any contact with the extortionist.
- Business email compromise. Revoking sessions and tokens as well as resetting passwords, removing malicious inbox rules, OAuth grants and added authentication methods, reviewing what the mailbox exposed, and contacting the bank quickly where a payment was redirected.
- Cloud account compromise. Rotating access keys, reviewing new users, roles, federation settings and resources in unused regions, and preserving control plane logs and snapshots before deleting anything.
- Insider. Involving HR and legal from the start, collecting evidence lawfully and quietly, and limiting knowledge of the case.
Each playbook should state the trigger, the first actions, the evidence to collect, the decisions that need escalation and the conditions for closing. Incident readiness work typically produces these alongside the plan. Revise them after every exercise and every real incident.
What a useful tabletop tests
A useful tabletop tests decisions, not knowledge of the plan. Present a realistic scenario in stages, with incomplete information, and make participants decide. Do we shut down the ordering system now, do we notify the regulator with what we know, who speaks to customers. Include executives, legal and communications, since their decisions are the slow ones.
Add practical injects. Ask someone to produce the insurer's number, to join the out-of-band channel, or to pull identity logs for a given date. Record every gap as an action with an owner and a due date. An exercise that produces no findings was probably too easy.
Backups an attacker cannot delete
Ransomware operators look for backups before they encrypt anything. If the backup console accepts the same domain administrator credentials as everything else, assume the backups will be deleted. Keep at least one copy that is immutable or offline, administered through separate credentials with multifactor authentication, outside the production identity domain.
Then test restores. A backup job that reports success says nothing about whether a full service can be rebuilt. Restore a complete system to a clean environment, including dependencies such as the directory, DNS and secrets, and time it. Compare the result with what the business assumes it will get.
Measuring readiness without inventing numbers
Readiness measures should come from your own tests, not from industry figures. The useful ones are observable facts.
- For each critical log source: whether it is collected, how far back it goes, and whether the team can query it today.
- The time taken in the last exercise to reach a decision maker and obtain an isolation decision.
- The date of the last full restore test, what was restored and how long it took.
- The date the contact list was last verified by calling the numbers.
- Open actions from the last exercise, and how many are overdue.
- Whether each playbook has been exercised since it was last changed.
Track these over time. The trend tells leadership more than a maturity score does, and each item points to a specific fix.
Where to start
- Write down who can authorize isolation and shutdown, with deputies, and get executive sign-off.
- Build the offline contact list, confirm the insurer's notification conditions and name your external responder.
- Check the actual retention of identity, endpoint, email, cloud control plane, VPN and DNS logs, and extend the short ones.
- Confirm that one backup copy is immutable or offline under separate credentials, and schedule a full restore test.
- Run a short ransomware tabletop with executives present, and turn each gap into an owned action.