Incident communication: who is told, what they are told, and when

A payment system goes down at 10:14 on a Monday morning, and 2,000 salary payments are stuck. The operations team is fixing the problem, but the customers, the regulators, the scheme and the senior management all need to know what is happening. Incident communication is the discipline of telling the right people the right thing at the right time, while the incident is still happening. It is not an afterthought, and it is not a press release. It is part of the incident response, and a bank that communicates badly during an incident loses trust faster than a bank that has a longer outage but communicates well. Incidents are graded by severity, and the severity decides who is told and how fast. A severity one incident stops payments for many customers, and it triggers an immediate notification to senior management, to the operations leadership, and to the regulator if the rules require it. A severity two incident degrades payments, for example a delay of more than an hour, and it triggers a notification to the affected customers and to the operations team. A severity three incident is a minor fault that does not affect customers, and it is logged and fixed without a customer notification. The severity must be set in the first fifteen minutes, because everything else, the notifications, the escalation, and the regulatory reporting, depends on it. Every communication must answer four questions. What happened, in one sentence, without jargon. What is affected, naming the payment types, the channels, and the number of customers. What is being done, naming the fix and the team working on it. And when the next update will come, with a specific time. A good first update is: At 10:14, our Faster Payments service stopped processing new payments. About 2,000 salary payments are delayed. Our engineering team is restarting the service and we expect it to be back by 11:00. We will update you again at 10:45, or sooner if the situation changes. That update is short, specific, and honest, and it gives the customer something to plan around. There are three things an incident communication must never do. It must never blame a person, a team, or a vendor, because blame does not help the customer and it poisons the investigation. It must never speculate about the cause before the cause is known, because a wrong guess will be quoted back later. And it must never give a number that is not confirmed, because a customer who is told 2,000 payments are affected and later learns it was 20,000 will not trust the next update. If the number is not known yet, the update says so: we are still establishing how many payments are affected, and we will confirm the number in the next update. Honesty about uncertainty builds more trust than a confident guess. After the incident is resolved, the bank writes a post-incident report. It states what happened, why it happened, how long it lasted, how many payments were affected, and what will change so it does not happen again. The report goes to the regulator if the rules require it, to senior management, and to the teams that must make the fix. The report is not a punishment; it is how the bank learns. For a business analyst, the incident communication requirements are therefore about severity levels, notification lists, message templates, update timing, and the post-incident report. A BA who designs those well gives the operations team a playbook to follow at 10:14 on a Monday morning, when nobody has time to invent one.