When an IT system fails in a bank, the service desk is usually first to know what has broken. It is rarely first to know who that is hurting. That answer sits with the contact centre, payments operations and the complaints team, and it reaches the incident call only if somebody asks for it.
Consider a retail bank on a payday morning. At 08:05, monitoring picks up intermittent timeouts between the card authorisation platform and a fraud-screening service run by a third party. Most card payments still go through, so the service desk logs a priority three ticket: one component, intermittent, no outage.
By 08:45 the view from outside IT is different. The contact centre queue has doubled, with callers saying their cards were declined at fuel stations and supermarkets. Card operations can see decline rates climbing, and the social media team has spotted a cluster of complaints. None of it has reached the incident call.
The incident manager has questions a priority three rating cannot answer. Is this a few hundred customers or tens of thousands? Is it getting worse? Are people with no other way to pay among them? Does it meet a reporting threshold?
This is where IT incident impact assessment decides the shape of the whole response. Finding the fault is IT’s job. Whether the bank escalates, what it tells customers and whether it reports to the regulator all depend on answers that sit with the business.
During an IT incident, impact is found by asking. The question needs as much design as the monitoring.
What Is IT Incident Impact Assessment?
IT incident impact assessment is the work of establishing, while an IT incident is still running, which business services, customers and obligations are affected, how badly, and whether that is changing. It combines what IT can see in its monitoring with what business teams can see at the front line.
A live assessment is different from a business impact analysis, the planning exercise that maps which services depend on which systems. The analysis says what could be affected if the card platform degrades. The live assessment says what is affected at 08:45, for how many customers, and whether that number is rising.
Why Monitoring Cannot Show Who Is Affected
IT monitoring measures systems. The business impact of an IT incident is measured in customers, transactions, complaints and time, and most of those numbers are counted outside IT. A rising timeout rate is a technical fact. How many customers it is hurting, and whether they have another way to pay, are business facts.
The FCA’s finalised guidance on operational incident reporting, FG26/3, points the same way. Its worked examples measure an impact tolerance in hours, and also in complaints and failed transactions: a tolerance of 500 complaints with 150 received is 30% used (FCA 2026). Complaints are counted by the complaints team, well away from any screen IT is watching.
An earlier article on IT alerting and incident coordination sets out the business questions worth asking at this point. Getting reliable answers quickly is the harder part.
Where Does Customer Impact Show Up First?
Customer impact during an outage shows up first wherever customers touch the firm. In a bank or insurer, that usually means a handful of teams who see the effect before anyone explains the cause:
- The contact centre, through call volumes, call reasons and wait times
- Card and payments operations, through decline rates and exception queues
- Branches, once customers raise it at the counter
- Complaints, social media and the press office, as customers take it public
- Relationship managers, when business clients ring about payroll
Each team holds part of the answer. None of them is on the incident call IT has just opened.
A Question In The Incident Channel Gets A Poor Answer
The most common impact assessment is a single message in the incident chat: is anyone seeing customer impact? It feels quick. It produces a poor answer, because every team reads the question differently and replies, or doesn’t, in its own time.
At the bank, three replies arrive over twenty minutes. The contact centre says “a few more calls than usual”. Digital banking says “no problems showing here”. The social media team posts a screenshot. Card operations, the team seeing the most, says nothing at all.
The weaknesses are the same every time:
- Nobody has agreed what impact means, so “a few more calls” and “significant” can describe the same queue
- Replies describe different moments, anywhere from 08:50 to 09:10
- The loudest team shapes the view, and the busiest team is missing from it
- Nothing is captured in a form that can be counted later
Ask A Structured Question With Fixed Answers
An impact check works better as one short question with fixed answers, sent to named people with a time to reply by. Fixed answers from six teams can be compared in a minute. Six paragraphs of free text in a chat thread can’t.
The message can be plain. For example:
“Card payments incident, impact check 1, 08:45. Some card payments have been declining since about 08:05. Reply with the number that best describes what your team sees now. 1: no customer impact seen. 2: some customers affected, service still usable. 3: customers unable to pay or use the service. 4: not known yet. Reply by 08:55. Next check 09:15.”
“Not known yet” is a legitimate answer, and very different from silence. The next check time matters too, because it tells a team that can’t answer by 08:55 when it will be asked again.
Send The Check To Service Owners, Not To A Channel
An impact check should go to the people accountable for each affected service, and to the teams that see customers directly. Posting it into a channel of forty people spreads the question so thinly that nobody feels it is theirs.
For the card incident, that might mean the heads of card operations and digital banking, the contact centre and branch network duty managers, the complaints lead and the press office, each with a named deputy. The list is short enough to chase every missing reply by name.
Firms that have mapped their important business services under the FCA’s operational resilience rules have a head start, because the map already shows which services depend on the card platform. The check adds the people who can say how each one is doing.
How Often Should Impact Be Reassessed?
Business impact should be reassessed at a fixed interval agreed in advance, and again whenever something significant changes. A single assessment describes one moment, and IT incidents rarely hold still.
At the bank, the first round puts the contact centre and card operations at level 3. At 09:15 the branch network, now open, reports level 3 too. A fix at 09:40 brings card operations down to level 2 by the 10:15 check. Without repeat checks, decisions at 10:00 would rest on a picture from 08:45.
A short interval in the first hours, for example every 30 minutes, keeps the picture close to the truth. The article on operational resilience during a live incident explains why the tolerance clock starts when a service degrades rather than when someone declares.
Challenging The Assumption That No News Means No Impact
Incident leads often read silence from the business as reassurance. If card operations had a serious problem, the thinking goes, they would have said so. The assumption holds on most days and fails in exactly the incidents where it matters.
The teams absorbing the worst of an incident have the least time to report on it. At 08:50, card operations was quiet because its people were working through a queue of declined payments. When the structured check also went unanswered, a two-minute call at 08:57 turned silence into level 3.
So a missing reply is a gap to close. The incident lead needs to know who has replied, who has only acknowledged and who has said nothing, and the third group gets a phone call.
Reporting Thresholds Turn The Assessment Into An Obligation
From 18 March 2027, the FCA, PRA and Bank of England run a single regime for operational incident reporting, with the FCA’s rules set out in policy statement PS26/2. A firm must report an operational incident it reasonably believes poses a risk of intolerable harm to consumers from which they cannot easily recover, to the safety and soundness of the firm or other market participants, or to market stability, integrity or confidence in the UK financial system.
Every one of those tests is a question about impact. Reports are due as soon as practicable and within 24 hours of determining that a threshold is met, or within four hours of first detecting the incident for payment service providers. Where impact tolerances apply, the FCA expects a report before they are breached. Firms under DORA make a parallel judgement when they classify a major ICT-related incident, covered in the article on DORA major incident reporting timelines.
The FCA’s lessons from the CrowdStrike outage of 19 July 2024 found that the timing and completeness of incident notifications varied widely, and that effective engagement was timely and clearly set out the impact on important business services. The same review found third-party issues were the leading cause of operational incidents reported to the FCA between 2022 and 2023 (FCA 2024).
A Practical Decision Framework For Impact Checks
The framework has seven steps. Most of them happen well before an incident, when there is time to think.
Step 1: Agree What Each Impact Level Means
Write down what each answer means in customer terms. “Some customers affected” should mean the same to every team.
Step 2: Name Who Answers For Each Service
List an owner and a deputy for each important business service, plus the customer-facing teams. Keep the list short enough to chase by name.
Step 3: Pre-Write The Impact Check
Draft the message now, with gaps for the service, start time and reply-by time. Nobody writes a clear question at 08:45 with a queue building.
Step 4: Send It When Customer Impact Is Plausible
Send the first check when there is a credible route from the fault to customers. Waiting for proof means waiting for the contact centre to raise it.
Step 5: Chase Every Missing Reply
Treat silence as unknown. Someone named in the plan calls each owner who has not replied by the deadline.
Step 6: Repeat On A Fixed Cadence
Set the interval in advance, and add a check after any fix or new symptom. Keep the answer levels identical between rounds.
Step 7: Keep The Answers With The Incident Record
Store each round of answers, with times, alongside the incident timeline. The article on tracking critical actions during an incident covers what happens when those answers become tasks.
How Crises Control Supports Business Impact Assessment
Communication tools send notifications, but they don’t coordinate the ongoing updates, acknowledgements and response activities that follow. That gap is where impact questions get answered in fragments.
Crises Control’s mass notification software, Ping, reaches the right people in seconds through SMS, voice calls, email, push notifications, Microsoft Teams and web alerts. An impact check can go to a defined group, such as the owners of every service connected to card payments. Recipients acknowledge with one tap and can reply by SMS, email, push notification or voice call, and Ping shows who has acknowledged and who still needs to respond.
Silence is handled by rule rather than memory. Ping can cascade an alert across channels until recipients acknowledge, and escalation keeps a critical alert going until the right people respond. Every delivery, acknowledgement and response is recorded, and the history can be exported for audit and post-incident review.
When the answers show customers are being harmed, Incident Manager activates predefined response plans with saved message templates, recipient groups and critical documents, and keeps an incident timeline of communications, updates and decisions. The IT incident response software page shows how this works alongside existing monitoring tools, and the operational resilience software for financial services page covers banks, insurers and payment providers.
The software does not decide what counts as customer harm, or whether a reporting threshold has been met. Those remain judgements for the incident lead and the firm’s risk and compliance owners. Its role is to make sure the people who can see the impact are asked, and that every answer and every silence is recorded with a time.
Alerting The Business Is Only Half The Conversation
Telling the business that IT has a problem is the part of an incident firms tend to have practised. Fewer have a reliable way for the business to tell the incident lead what that problem is doing to customers.
That return path is where coordination starts. With the answers in, the incident lead can decide whether to escalate, which plan to activate and what customers should be told. Without them, the firm coordinates around a priority three ticket while its contact centre has been handling something bigger since before nine.
Frequently Asked Questions
What is IT incident impact assessment?
IT incident impact assessment is the work of establishing, while an incident is still running, which business services, customers and obligations are affected, how badly, and whether that is changing. It combines monitoring data from IT with what business teams can see, such as call volumes, complaints and failed payments. It is repeated as the incident develops, because impact rarely stays the same for long.
Who should assess business impact during an IT incident?
The incident lead should own the assessment, with the answers supplied by the named owners of each affected service and by the teams that face customers. IT supplies the technical picture, but call volumes, complaints and customer contact sit outside its monitoring tools. Naming these people in the response plan means the incident lead confirms a list on the day rather than building one.
What should you ask business teams during an outage?
Ask one structured question with fixed answers, for example no customer impact seen, some customers affected, customers unable to use the service, or not known yet. Include a time to reply by and the time of the next check. Fixed answers can be compared across teams in minutes, where free text in a chat channel usually cannot.
How often should an impact check be repeated?
An impact check should be repeated at a fixed interval agreed before the incident, for example every 30 minutes in the first hours, and again after any fix, workaround or new symptom. The answer levels should stay the same each round so the results can be compared. A single check only describes the moment it was sent.
How does impact assessment relate to FCA incident reporting?
Under FCA, PRA and Bank of England rules that apply from 18 March 2027, a firm must report an operational incident that poses a risk of intolerable consumer harm, to safety and soundness, or to market stability, integrity or confidence. Each of those tests depends on IT incident impact assessment rather than on a technical severity rating. Reports are due as soon as practicable and within 24 hours of determining that a threshold is met, or within four hours of first detection for payment service providers.
This article was drafted with AI assistance and reviewed by the Crises Control team. Featured image: AI-generated.
