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 (PS21/3) and the PRA's (PS6/21 and SS1/21) 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 risks missing one under pressure. Writing down who owns each notification, and who deputises for them, removes that ambiguity before it matters.

5. Rehearsal and exercising

Documentation tells people what to do. Rehearsal shows whether they can.

• Has every person named in the plan walked through their own role in a realistic scenario, including the decisions they are expected to make?
• Have you run a realistic exercise in the last twelve months?
• Did that exercise produce findings, and were those findings acted on?
• Do your exercises reflect 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 reviewing near misses as well as full incidents?

This is the domain most commonly treated as a one-off tick. An occasional table-top exercise satisfies a regulatory minimum but rarely tests the hard parts: who has authority to isolate a system, who signs off a notification, and who decides when to call in outside help.

A useful exercise puts the real decision-makers in the room, uses a scenario built from your own environment, and records each decision, who made it, and on what information. The record matters as much as the exercise. It is what lets you show a regulator that testing happened and that its findings changed the plan.

Rotate the scenarios and the people. A team that has rehearsed the same script three times learns the script, not the response. Bringing in deputies and newer members of the team tests whether the plan still works when the usual people are unavailable.

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. 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.

A review is only as good as the record behind it. It needs to establish who had access to the affected systems, who approved each significant action, and what was known at the time. Where AI agents act on your systems, the same questions apply to them. IntelXview's AI Control Plane records the policy decision for each agent action routed through it, which gives a review a starting point for those actions; activity that does not pass through it still has to be reconstructed from other logs.

Where the gaps usually are

These are common shortfalls to look for when working through the checklist.

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.

Exercising is annual and generic. The firm has run a table-top on a standard scenario. Nobody has rehearsed a realistic scenario built around the kind of event most likely to happen to them specifically, and nobody recorded who decided what.

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 rehearse realistic scenarios tied to your specific risk profile. A cloud security incident carries different first-hour priorities than a ransomware event on on-premises infrastructure, and the access and authority decisions differ too. Generic exercises do not prepare teams for the specific conditions they face.

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.

To get a structured view of where your firm sits against these six domains, work through each question with the people named in your plan and record the answers, the owners and the dates for closing each gap.