An Incident Response Readiness Checklist for Regulated Firms

Most regulated firms have an incident response plan somewhere. A document that covers escalation paths, notification duties, and the steps to take after a breach. The plan is rarely the problem. What happens when someone has to follow it under real-world pressure, often with partial information and a clock running, is where the gaps appear.

This checklist is not another template to add to the folder. It is a way to test whether the things your plan describes are genuinely in place.

Why a plan is not the same as readiness

Writing down what to do in an incident is the work of an afternoon. Having people who can execute that plan, under pressure, in sequence, without losing time to confusion or disagreement, is the work of sustained preparation.

The FCA's operational resilience rules and the PRA's requirements under PS21/3 make this distinction explicit. Firms are expected not only to document their arrangements but to test whether they can stay within their impact tolerances when things go wrong. A binder on a shelf does not satisfy that expectation. Neither does a table-top exercise that runs through a scripted scenario your team has seen three times before.

Regulators want evidence that the preparation is real. Documented, tested, and updated arrangements, with records to show the testing happened and findings from it were acted on.

What the checklist covers

Readiness has six domains. The questions below treat each one as a set of tests. Where your honest answer is anything other than yes, you have found something worth fixing before an incident finds it for you.

1. Governance and ownership

A plan with no clear owner fails at the first handoff.

• Is there a named Incident Response Manager with decision-making authority during a live incident?
• Does your board or equivalent governing body have a defined role, even if that role is limited to receiving a briefing?
• Are legal, HR, communications, and senior management contacts documented and kept current?
• Is there a process to activate the plan outside business hours?
• Do your supplier and outsourced provider contracts include security incident notification obligations?

Governance gaps surface in two ways. Either no one is sure who makes the decision to notify a regulator, so it gets delayed. Or the plan names people who have changed roles, and the first hour of a real incident is spent working out who is actually in charge.

2. Detection and reporting

An incident you cannot detect is an incident you cannot manage.

• Do you have monitoring in place for the systems that process regulated or client data?
• Is there a clear process for staff to report a suspected security incident, including a route that bypasses normal channels if those might be compromised?
• Are detection alerts reviewed, triaged, and escalated, or do they queue in a system nobody has time to examine?
• Do you log enough to reconstruct what happened, who accessed what, and when?
• Is your logging coverage consistent across cloud, on-premises, and remote work environments?

Logging gaps are one of the most consistent findings in any incident response review. Most firms do not lack detection tools. They lack confidence that those tools cover the environments where sensitive data actually lives. Cloud adoption and remote work have extended the surface faster than logging practices have kept up.

3. Containment and evidence

Early decisions about containment determine how much of the incident you can investigate afterwards.

• Do the people expected to lead containment know what steps to take and in what order?
• Is there guidance on which actions preserve forensic evidence and which destroy it?
• Can you isolate a compromised system without taking down a service your clients depend on?
• Do you have a process for deciding when to bring in external incident response support, and relationships in place before you need them?
• Are there documented legal privilege considerations for written communications during a live incident?

This is the domain where preparation is hardest to fake. A team that has never worked through a containment scenario will lose time to coordination problems. External support can be brought in, but they take time to onboard, and the first hour is gone before they arrive. Firms with rehearsed containment procedures move considerably faster through those early stages.

4. Regulatory and client communication

Notification duties have deadlines. Missing them compounds the original incident.

• Are your ICO, FCA, and sector-specific notification thresholds documented and accessible during an incident?
• Is there a named person responsible for making regulatory notifications?
• Do you have template communications for clients affected by a breach, reviewed by legal in advance rather than drafted under pressure?
• Is your communications channel secure? An incident that compromises your email environment also compromises a response plan that coordinates through email.
• Do you know whether your professional indemnity or cyber insurance policy requires notification at a particular point?

The ICO expects notification within 72 hours of a personal data breach where there is a risk to individuals. The FCA's timelines depend on the nature of the event and the firm type. These are firm deadlines. A firm that has never mapped its notification obligations clearly is almost guaranteed to miss at least one of them under pressure. An incident response readiness assessment consistently flags notification ownership as the highest-priority gap in smaller regulated firms.

5. Training and exercising

Documentation tells people what to do. Training is what lets them do it.

• Has every person named in the plan received training specific to their role in a security incident?
• Have you run a realistic exercise in the last twelve months?
• Did that exercise produce findings, and were those findings acted on?
• Does your training account for the scenarios most likely to affect your sector, such as business email compromise for financial firms or ransomware for firms with large data holdings?
• Is there a process for learning from near misses as well as from full incidents?

This is the domain most commonly treated as a one-off tick. Annual compliance training and occasional table-top exercises address a regulatory minimum. They rarely produce the behavioural change that a real incident demands.

Research IntelXview has compiled across hundreds of organisations and hundreds of thousands of employees consistently shows that people learn most effectively when training is grounded in real events and delivered close to the moment when the risk is most salient. Our piece on what incident-timed behaviour support is covers the evidence base for this approach in detail.

The decay problem compounds the issue. The evidence behind incident-triggered learning shows that standard annual training retains around low of knowledge after ninety days. Structured, repeated exposure to realistic scenarios produces retention closer to substantially higher. For incident response, the gap between those two figures is the gap between a team that executes well under pressure and one that reverts to guesswork when it matters most.

6. Post-incident review

Every incident, handled well or badly, is a source of information you cannot get any other way.

• Is there a formal post-incident review process, separate from the immediate debrief in the days after the event?
• Does the review capture what worked, what failed, and what the early indicators were that something had started?
• Are findings tracked against remediation actions with owners and deadlines?
• Is the incident response plan updated after each real incident or significant exercise?
• Do you analyse patterns across incidents to identify systemic weaknesses, rather than treating each event in isolation?

Firms that skip post-incident review see the same mistakes in the next event. The 48-hour paradox explores why decisions made early in an incident often define the outcome long after the initial event has closed. Structured review is how you learn from those decisions rather than repeating them.

Where the gaps usually are

Running this checklist with regulated firms consistently turns up the same shortfalls.

Notification ownership is unclear. Everyone assumes someone else knows when to call the regulator, and under pressure the decision gets delayed until the clock has run down.

Containment has never been practised. The plan says what to do, and the people who would do it have never walked through the steps together. The first time the team coordinates on containment is during a live incident.

Training is annual and generic. The firm has completed compliance training covering data protection and phishing awareness. Nobody has rehearsed a realistic scenario built around the kind of event most likely to happen to them specifically.

Communication channels are unprotected. A cloud-based incident that takes out Microsoft 365 also removes the email and Teams environment the response plan relies on for coordination.

Post-incident review happens once and is never followed up. Findings are circulated, nobody is accountable for closing the actions, and the same gaps surface in the next review.

None of these are unusual findings. They reflect the reality that incident response preparation is low priority until it is urgent, and what gets deprioritised in planning is precisely what you need when the plan has to work.

Turning the checklist into a programme

A checklist tells you what you have and what is missing. Closing the gaps is a separate programme of work, and the sequencing matters.

Fix governance and ownership first. If nobody knows who decides, nothing else in the plan can execute reliably.

Fix notification thresholds second. These carry the most immediate regulatory consequence and the tightest deadlines.

Then train the team on realistic scenarios tied to your specific risk profile. Cloud security incident response carries different first-hour priorities than a ransomware event on on-premises infrastructure. Generic training does not prepare teams for the specific conditions they face. Our training readiness programme builds scenarios around what has actually happened to firms in your sector, so the practice is as close to the real thing as possible.

Then test, review, and update. The point of exercising is to find gaps before an incident does.

A regulated firm that can answer yes to every question in this checklist is in a meaningfully different position from one that cannot. The document is not the difference. The people and processes behind it have been tested, and have held up under that testing. That is what readiness actually means.

For a structured view of where your firm sits against these six domains, the incident response readiness assessment is the starting point.