A major incident in a financial firm produces two kinds of output. The first is information: alerts, updates, status messages, holding lines. The second is work, a long list of actions somebody has to carry out before customers are protected and the service is back. Most firms have become reasonably good at the first. The second is where control tends to slip.
Consider a building society whose mobile banking app stops logging customers in at 15:10 on a Friday, shortly after a change at a third-party supplier. By 15:40 the bridge call has agreed eleven actions. Brief the contact centre. Post a status message on the website. Tell branch managers what to say at the counter. Chase the supplier for a rollback time. Check whether card payments are affected. Start logging complaints. Decide whether the firm’s supervisors need to hear about it today.
At 17:00 the incident lead asks for an update, and the people on the call have questions of their own. Has the contact centre script gone out, or was it only drafted? Who was chasing the supplier, operations or IT? Did anyone check the card platform, or did everyone assume someone else had? And if the website message is live, does it still say what it said at 15:45?
This is where tracking critical actions during an incident becomes the difference between a response that is running and one that only sounds as if it is. Every action on that list was agreed on the call. Not every action was owned, and nobody on the line can say which is which.
An action that has been agreed is not an action that has been done. The gap between the two is where a response quietly loses its grip.
What Is Tracking Critical Actions During An Incident?
Tracking critical actions during an incident is the practice of giving every response action a named owner, a deadline and a visible status from the moment it is agreed until it is confirmed complete. It turns a list of decisions into accountable work that anyone leading the response can check without having to ask.
The principle underneath is simple. Status should come from the person doing the work, recorded where others can see it, and not from the memory of whoever was on the last call. If the incident lead has to ring round to find out whether something happened, the action is being remembered rather than tracked.
Why Do Actions Get Lost After The Bridge Call?
Actions get lost after a bridge call because the call records decisions, and a decision has no owner until someone is given it. “Can someone pick up the supplier?” gets a murmur of agreement from three people. Each of them assumes one of the other two has it.
On the building society’s call, actions were agreed in bulk while the technical diagnosis was still being argued over. Some had a person’s name beside them, some a team name, and two had nothing at all.
The common ways an agreed action disappears:
- It is assigned to a team rather than a person, so nobody in the team treats it as theirs
- It is assigned to someone who had already dropped off the call
- It depends on another action that has not happened yet, so it stalls without anyone noticing
- It is completed but never reported back, so a second person does it again
- It is overtaken by events and nobody updates or closes it
None of these is a failure of competence. They are failures of structure, and from the incident lead’s seat they all look identical. They look like silence.
Email, Chat And Spreadsheets Do Not Know A Task Is Late
Email, chat channels and shared spreadsheets struggle during an incident because none of them notices when an action runs late. A spreadsheet row marked “In progress” at 15:45 still says it at 17:30, and a chat message confirming the supplier call sits forty messages up a thread that later joiners never read.
These tools are fine at what they were built for. What they don’t supply is something that reacts when a deadline passes, so an overdue action only surfaces when somebody happens to ask.
Tasks Need An Owner, A Deadline And A Status
A critical action can only be tracked if it has an owner, a deadline and a status that the owner keeps current. Take away any one of the three and the action drifts back into the category of things people believe are happening.
- The owner is a person, not a team. “IT” cannot accept a task. The on-call infrastructure lead can
- The deadline is a time, not a priority. “Urgent” means something different to everyone who reads it. “By 16:15” does not
- The status moves through assigned, accepted, in progress and complete. Acceptance matters most, because it is the first point at which the firm knows the owner has seen the task
For the building society the difference is concrete. “Contact centre script. Owner: head of customer operations. Due 15:55. Accepted 15:43. Complete 15:58.” is an action. “Contact centre to be briefed” is an intention written down.
Who Owns An Action That Crosses Team Boundaries?
An action that crosses team boundaries should still be owned by one named person, even when several teams contribute to it. Chasing a supplier touches IT, procurement and vendor management, which is exactly why it so often belongs to nobody.
Incident task ownership works best when the response plan names the owner by role before anything goes wrong. The plan might say that supplier escalation during a live incident sits with the supplier relationship manager, deputised by the head of IT service management. On the day, the incident lead confirms a name rather than negotiating one.
The same applies to the actions regulators care about. Deciding whether to contact the firm’s supervisors is a judgement, and it needs an owner senior enough to make it. The FCA’s operational resilience rules require firms to identify their important business services and set impact tolerances for them, so the clock on a customer-facing outage keeps running whether or not anyone has picked up that conversation. The Crises Control article on operational resilience during a live incident looks at why that clock often starts earlier than the declaration.
What Should Happen When An Action Goes Overdue?
An overdue action during an incident should escalate automatically to someone who can act on it, in a defined order. Overdue incident actions are one of the most useful signals an incident lead can get, because each one points straight at the place where the response has stalled.
A sensible escalation path has stages. First a reminder to the owner. Then a notification to their supervisor or deputy. Then, if the action is still open, reassignment or a flag to the incident lead. Each step gives the owner a fair chance before the problem moves up a level.
Take the card platform check at the building society. Nobody accepted it. Under a simple escalation rule, that task would have reached the head of payments within fifteen minutes instead of surfacing at 17:00. The alternative is escalation by memory, which relies on the incident lead noticing an absence, and absences are hard to notice under pressure.
Leadership Needs Status, Not Reassurance
Senior leaders in a financial firm need to know which critical actions are complete, which are late and which are blocked. What they often get instead is reassurance: “the team is on it”, “we’re making good progress”.
A COO deciding whether to extend branch opening hours, or whether to brief the board tonight, needs something closer to a count. Eleven actions agreed, eight complete, two in progress, one overdue and sitting with the supplier. That picture takes seconds to read, and it tells leadership exactly where to push.
Regulators Will Ask What Was Done
After an incident, a regulator, an auditor or a board rarely asks whether the firm communicated. They ask what was done, when, and who decided. The answer has to come from a record, and the record is only as good as the tracking behind it.
That scrutiny is becoming more structured. The FCA’s policy statement PS26/2 on operational incident and third party reporting, published in March 2026, creates single FCA, PRA and Bank of England regimes for operational incident and third party reporting, which apply from 18 March 2027. The rules define what an operational incident is and set thresholds for when one must be reported. For EU-regulated entities, a separate Crises Control article covers DORA major incident reporting timelines.
The FCA’s published lessons from the CrowdStrike outage of July 2024 point the same way. Firms that had mapped their important business services were able to prioritise getting key services back online (FCA 2024). Prioritising recovery only works if someone can see which recovery actions are finished and which have not started.
Challenging The Assumption That A Good Bridge Call Means A Good Response
A well-run bridge call feels like control. People speak in turn, decisions get made, actions are read back. But the call is only where the response gets planned. The response itself happens afterwards, in dozens of separate places, carried out by people who are no longer on the line, and a firm can run an excellent call and still discover at 17:00 that several actions never started.
The better measure is less comfortable. Once the call ends, how long would it take the incident lead to state, accurately, the status of every critical action? If the honest answer involves ringing round, the call produced a plan and the response is still an unknown.
A Practical Decision Framework For Tracking Critical Actions
Step 1: Define The Critical Actions For Each Service
List the actions that must happen when each important business service is disrupted: customer communication, supplier escalation, the regulatory judgement, workaround invocation. These become the standard tasks inside each response plan.
Step 2: Assign Owners By Role, With Deputies
Name a role and a deputy for every standard action. Roles survive staff turnover. Named deputies survive annual leave and 03:00 call-outs.
Step 3: Set Deadlines Against The Impact Tolerance
Work back from the impact tolerance for the service. The PRA’s supervisory statement SS1/21 on impact tolerances for important business services is the reference point for UK banks, building societies and insurers. If the tolerance is four hours, a supplier escalation due at hour three is too late to change anything.
Step 4: Require Acceptance, Not Just Assignment
Treat an assigned task that has not been accepted as unowned. Acceptance is the first moment the firm knows the owner has seen the task and taken it on.
Step 5: Write The Escalation Rules Down
Decide how long an unaccepted or overdue task waits before it escalates, and to whom. Agree the stages in advance so nobody has to judge them in the moment.
Step 6: Record Completion As It Happens
Capture who completed each action and when, at the time it happens. A record rebuilt from memory the following week is an account of the incident. A record captured live is evidence.
How Crises Control Supports Tracking Critical Actions
Communication tools send notifications, but they don’t coordinate the ongoing updates, acknowledgements and response activities that follow. Email, spreadsheets and manual processes fill that gap, and they tend to create delays and reduce visibility.
Crises Control’s Task Manager extends Incident Manager by turning coordinated response plans into assigned, tracked and completed actions. When a response plan is activated, tasks go to named owners or teams, who can accept them and update their status from any device. Authorised users can assign owners, monitor deadlines, track progress and manage workflow dependencies, so a task that relies on another only unlocks once the first is complete.
Escalation rules are configurable. A task that is overdue or unclaimed can notify a supervisor, be reassigned or alert the incident manager, which is the building society’s missing card platform check handled by rule rather than by luck. Task status and ownership also feed live operational visibility through the Control Centre, so leadership can see what is done without calling the people doing it.
Task Manager records task ownership, acceptance times, status changes, escalation activity and completion updates. Those records form part of the wider operational incident record, alongside the communications and decisions held in Incident Manager, and support post-incident review, governance and audit. The page on operational resilience software for financial services shows how this fits with incident coordination and communications for banks and insurers.
The software does not decide which actions matter, who is best placed to own them or how long each should take. Those remain judgements for the plan owners and the incident lead. Its role is to make sure that once those judgements are made, nobody has to remember whether they were carried out.
Control Means Knowing What Is Done
Alerting gets people onto the call. Coordination turns the call into decisions. Control is the next step: knowing, at any moment, which of those decisions have become finished work and which have stalled somewhere between the call and the person meant to do them.
For a regulated firm, control is also what makes the next step possible. A response in which every critical action has an owner, a deadline and a timestamped completion produces its own evidence. The incident reporting that follows then becomes a read of something that already exists, rather than an attempt to reconstruct a Friday afternoon nobody wrote down.
Frequently Asked Questions
What does tracking critical actions during an incident involve in practice?
Tracking critical actions during an incident involves giving every response action a named owner, a deadline and a status that is updated as the work progresses. It lets the incident lead see which actions are complete, in progress or overdue without asking around. It also produces a timestamped record of who did what and when.
Who should own an incident action that involves several teams?
One named person should own it, even when several teams contribute to the work. Shared ownership tends to become no ownership once pressure rises. The response plan should name the owning role and a deputy in advance, so the incident lead confirms a name rather than negotiating one.
What should happen to overdue incident actions?
Overdue actions should escalate automatically through defined stages, for example a reminder to the owner, then a notification to a supervisor, then reassignment or a flag to the incident lead. The rules should be agreed before the incident. Relying on the incident lead to notice a missing update is the least reliable form of escalation.
How do you know an incident action is complete?
An incident action is complete when its owner has marked it complete in a shared record, with a timestamp. A verbal assurance on a call that something is in hand is useful, but it leaves no evidence. The completion record is what leadership, auditors and regulators rely on afterwards.
Why does action tracking matter for regulated financial firms?
Tracking critical actions during an incident matters because regulators, auditors and boards ask what was done, when and by whom. UK firms in scope must be able to operate their important business services within impact tolerances, and the new FCA, PRA and Bank of England operational incident reporting regimes apply from 18 March 2027. A live record of completed actions supports both the response and the evidence that follows.
This article was drafted with AI assistance and reviewed by the Crises Control team. Featured image: AI-generated.
