Incident response readiness checklist: what to have before you need it

Almost everything that determines how an incident goes is decided before it starts. Who can authorise taking a system offline, whether logs exist, whether a forensics firm is contracted, whether anyone has the CEO's mobile number when email is down. This is the readiness list.

Plan and authority

• A written incident response plan, approved and reviewed within the last twelve months.
• Severity definitions that are observable, not adjectival — "critical" must be testable at 3am by someone who did not write it.
• Named authority to contain, including out of hours: who can take production offline, disable an account, or pull a network segment, without waiting for a committee.
• Deputies for every named role. Incidents do not wait for people to return from leave.
• A defined escalation path to executives and, where relevant, the board.

Contacts and access

• Contact list held offline and off-domain. A plan stored only in the system that is down is not a plan.
• Out-of-hours numbers for the response team, executives, legal and communications.
• Regulator notification routes, with portal accounts registered in advance — not created at hour 60 of a 72-hour clock.
• Cyber insurer notification details and policy number.
• Critical supplier emergency contacts, including your cloud provider's escalation path.
• An out-of-band communication channel, on the assumption that email and chat are compromised or unavailable.

Technical readiness

• Logging coverage you have actually verified — identity, endpoint, network, cloud control plane, and critical applications.
• Log retention long enough to investigate. Dwell times run to months; ninety days of logs frequently is not enough.
• Logs stored where an administrator who is compromised cannot delete them.
• Ability to isolate a host or account quickly, tested.
• Asset inventory good enough to answer "is this system in scope?" during the incident.
• Immutable backups and a tested restore, timed against your recovery objective.
• A clean environment to rebuild into, on the assumption production cannot be trusted.

Decisions to pre-agree

These are the ones that consume hours if left open:

• Containment versus evidence preservation — when do you pull the plug and accept losing forensic detail?
• Who decides whether to notify, and on what criteria.
• Your organisation's position on ransom payment, including the sanctions and legal analysis, agreed in principle in advance.
• When to engage law enforcement.
• Who speaks publicly, and who definitely does not.

External support

• Digital forensics and incident response retainer signed before an incident — procurement during a crisis wastes the first day.
• Legal counsel identified, including privilege considerations for investigation reports.
• Crisis communications support, internal or external.
• Confirm what your insurer requires: many policies mandate approved vendors, and using your own can prejudice the claim.

Evidence handling

• Know how to capture volatile data and take images before rebuilding.
• Maintain a timeline from the first minute — nobody reconstructs it accurately afterwards, and regulators, insurers and the post-incident review all need it.
• Record decisions and their rationale, not just actions.

Exercises

Tabletop at least annually, varying the scenario. Include the scenario organisations most often skip: an incident forcing a disclosure decision under uncertainty, with legal, finance, communications and security in the room together. Most teams have rehearsed the technical response and never the filing decision.

Key takeaways

• Containment authority, out of hours, with deputies — the most common delay.
• Keep contacts and the plan offline and off-domain.
• Register regulator portals and sign the forensics retainer in advance.
• Exercise the disclosure decision, not only the technical response.