There is a scene that plays out in financial services firms during an incident that does not appear in any SRE handbook I have read. The technology team is working the problem. The trading floor has noticed. Someone from the business has walked into the room, or sent a message, or, if it is bad enough, physically stood behind an engineer's chair. And the question they are asking is not "what happened" or "what are you doing about it." The question is "are we going to breach SLA."
That question has legal implications. It has client reporting implications. It has regulatory implications. The answer you give in that moment, even informally, can end up in an incident log that gets reviewed by compliance, or in a client communication that gets sent under a lawyer's name, or in a regulatory filing.
This is the part of incident communication that most guides skip. They were written for consumer tech companies where the blast radius of a badly worded status page is brand damage. In financial services, it can be something more concrete than that.
Who You Are Actually Talking To
When I run an incident in a consumer tech context, my audience is roughly: engineers, their managers, and end users via a status page. The communication chain is short.
In asset management, the stakeholder map looks different. There is the technology team. There is IT leadership. There is the business: trading, portfolio management, operations, client services. There is compliance. There is legal. There is, depending on the severity, risk management and the CTO or CIO. And depending on what systems are affected, there may be clients and their own legal and compliance teams on the other end of a phone call.
Each of those audiences wants different things from you, on different timescales, at different levels of technical detail. Getting this wrong (telling the trading desk something you haven't cleared with compliance, or giving the client services team a technical explanation they will relay inaccurately) creates problems that outlast the incident itself.
The first thing I do in any significant incident is answer two questions before I write a single communication: who needs to know, and what are they actually asking?
The First Five Minutes
The first communication in an incident is the most important because it sets the frame. Get it right and you establish that the situation is in hand. Get it wrong and you spend the rest of the incident correcting the impression.
My rule for the first five minutes is: communicate that you are aware of the issue, that you are investigating, and that you will give an update by a specific time. Nothing more.
This sounds obvious. It is harder than it sounds. The pressure in the first few minutes of an incident is to demonstrate that you know what is happening. That pressure pushes people toward speculating in their communications: saying "this looks like a database issue" when they don't yet know, or "we should be back up within the hour" when they have no basis for that estimate.
Speculation in incident communications causes specific problems in financial services. If you tell the business "looks like a database issue" and it turns out to be a network problem, you have created a false record and wasted time on their end while they prepared for a database-related impact. If you tell client services "we should be back up within the hour" and you are not, you have given them a commitment to a client that you then have to walk back.
The correct first message is boring: "We are aware of an issue affecting [system]. We are investigating. Next update at [specific time]." That is all. The specific time should be no more than 30 minutes away, because that forces you to actually have something to say by then.
Separating What You Know from What You Think
This is the discipline that takes practice. When you are inside an incident, your brain is pattern-matching aggressively. You have seen similar symptoms before. You have a theory. The theory feels like knowledge.
It is not knowledge. It is a hypothesis.
In incident communications, I use explicit language to separate these. "We know that X is happening" versus "we believe the cause is Y, and we are investigating." That distinction matters because the people receiving your communication will act on it. If I tell the trading desk that we know the cause is a failed index on the orders table, they will make decisions based on that. If I turn out to be wrong, those decisions were made on false information.
The format I use for mid-incident updates:
What we know: Factual observations only. Service is unavailable. Error rate is X%. This started at HH:MM.
What we believe: Current hypothesis. We believe this is related to [thing]. This is not confirmed.
What we are doing: Specific actions being taken right now. Not "investigating"; that tells people nothing. What specifically are you checking?
Next update: Time. Always a specific time.
I enforce this format in major incidents because it forces the person writing the update to actually separate fact from hypothesis in their own head before they communicate it externally.
The Things You Do Not Say
There are things you do not put in incident communications in financial services, and most of them are things that would be fine to say in a different industry.
You do not speculate about root cause until you know it. This is harder to enforce than it sounds because stakeholders push for it. The business wants to know why. Your honest answer in the first 30 minutes of a complex incident is "we don't yet know," and that is the answer you should give.
You do not give time estimates unless you have a specific basis for them. "We hope to have this resolved in an hour" is not a time estimate. It is a wish. What you can say is "we are deploying a fix now and expect it to take 20 minutes to roll out." That is a real estimate with a real basis.
You do not use language about financial impact, SLA breach status, or contractual obligations in technical communications. Those determinations belong to specific people in specific roles. If someone from the business is in your incident channel asking whether you are going to breach SLA, the correct answer is "I'll get you connected with the right people on that," not an off-the-cuff technical opinion that gets forwarded to a client.
You do not comment on whose fault it is, in any direction. Not "the vendor's API went down," not "a change made by [team] caused this." Root cause and accountability are for the post-mortem. In the incident, what matters is resolution, and blame in communications, even accurate blame, consumes energy that should be going toward resolution.
Communicating Across Technical Levels
The same incident looks completely different to an engineer and to a portfolio manager. The engineer wants to know what systems are affected, what errors are appearing, what the current hypothesis is, and what work is in progress. The portfolio manager wants to know whether they can trade, what the impact is on specific workflows, and when it will be resolved.
I maintain two communication streams in major incidents. One is the technical channel: the incident call, the engineering Slack, the internal runbook. The other is the business-facing update, which I write separately and send to a distribution list that includes business leadership, IT leadership, and client services.
The business-facing update never contains stack traces, error messages, infrastructure topology, or technical hypotheses. It contains: what is not working, who is affected, what the impact is in business terms, and what the next update time is. If I am going to say anything about cause, I wait until I am certain, and even then I keep it at the level of "a component in the [X] system failed" rather than "the Kafka consumer group lost its offset."
Writing this second communication while an incident is active is genuinely hard. It requires translating from engineering language into business language under time pressure, and it requires doing so accurately enough that the business can make real decisions from it. I have gotten better at this over time, and the thing that helped most was reading back through old incident communications and noting the places where the business-facing update was technically accurate but operationally useless.
The Compliance Dimension
Financial services firms have compliance obligations that affect incident communication in ways that are worth understanding explicitly.
Many firms are required to maintain incident logs that can be reviewed by regulators. What goes into those logs matters. Informal communications (a Slack message, a hallway conversation, an email from an engineer) can become part of the record in a regulatory inquiry if they contain information about the incident. This is not a reason to go silent during incidents. It is a reason to understand that what you write in work communications is not private and may be reviewed by people outside the firm.
Depending on the firm and the type of incident, there may be regulatory reporting obligations. A material operational incident at a regulated investment manager can trigger reporting requirements to bodies like the FCA, SEC, or FINRA depending on jurisdiction and nature of the incident. These reports go out under legal and compliance sign-off, not engineering. But the information in them comes from engineering. The incident log you maintain, the timeline you document, the cause analysis you complete: these feed directly into regulatory reporting.
The implication is that incident documentation needs to be accurate, timestamped, and complete. Not because of bureaucracy. Because it becomes the record.
The Post-Incident Communication
The incident is resolved. The all-clear goes out. Most communication stops at this point, and that is a mistake.
The post-incident communication, not the internal post-mortem but the external-facing summary, is one of the most important things you can write. Done well, it demonstrates competence and accountability. Done badly, it either sounds defensive or creates new concerns.
The structure I use:
What happened: A factual description of the incident in plain language. When it started, what the impact was, when it was resolved. No jargon, no hedging.
Why it happened: Root cause, at a level of detail appropriate for the audience. For internal distribution, this can be technical. For client-facing communication, it should be at the business system level.
What we're doing about it: Specific remediation actions. Not "we are reviewing our processes." What specifically is changing? What specific failure is being addressed? Give a timeline for those actions if you have one.
This last section is the one firms usually get wrong. The tendency is to be vague, because specific commitments create accountability. But vagueness reads as not taking the incident seriously, and stakeholders notice that. If the cause was a failed disk in a storage array that should have been flagged for replacement six months ago, the remediation is: we are replacing the disk, we are reviewing the replacement schedule for similar hardware, and we are adding an alerting rule for SMART data so this gets caught earlier. That is specific. That is what confidence looks like.
What This Has Taught Me
I have been involved in enough incidents in this industry to have learned some of this the hard way. I sent a communication early in my career that included a time estimate I had no basis for. The estimate was wrong. The client services team had already told a client. That conversation with the client services lead afterwards was not a good one.
I have also seen incident communications done well, by people who were calm under pressure, specific in their language, and honest about what they did and did not know. Those incidents, even the bad ones, ended with relationships intact and sometimes stronger. The competence demonstrated under pressure built trust.
The tooling does not really matter. Whether you use PagerDuty or Statuspage or an internal tool or a shared document, the fundamentals are the same. Know your audience. Separate fact from hypothesis. Be specific about what you know and what you don't. Give time commitments and keep them. Don't speculate about things you can't know yet.
The hardest part of all of this is not the writing. It is the discipline to slow down enough to do it right when the pressure is high and the instinct is to say everything you are thinking as fast as you can. That discipline is learnable. It just takes practice, and, unfortunately, incidents.
