A P1 outage isn't a technical event. It's a trust event.

When a priority-one incident hits, most IT teams instinctively treat it as an engineering problem. Find the fault, fix the fault, close the ticket.

That instinct is understandable, and it is also why so many organisations come out of a P1 with the service restored and the relationship damaged.

From the business side, an outage is not a stack trace. It is a store that can't take payments, a vessel crew that can't reach shore systems, a leadership team that finds out from a customer before it hears from IT. What they remember afterwards is rarely the root cause. It is whether IT looked in control.

I have spent years as the escalation point for P1 and P2 incidents — most recently as the C-suite escalation lead in a multi-brand retail environment. The technical fix matters. But the incidents that build or destroy trust are decided by three other things.

1. The first fifteen minutes set the story

Before anyone knows the cause, the business needs to know three things: that IT is aware, who is in charge, and when they will hear next.

A short first message beats a perfect late one:

• What is affected, in business terms ("card payments in UAE stores"), not system names.
• Who owns the incident — one named incident lead, not a distribution list.
• When the next update is coming, and then keep that promise even if there is nothing new to say.

Silence is the most expensive thing in a major incident. People fill it with worst-case assumptions, open parallel escalations, and start calling engineers directly — which slows the fix.

2. Separate the fixers from the communicators

The engineers restoring service should not also be answering the CFO's messages.

In a well-run P1 bridge, roles are explicit:

• Incident lead — owns decisions, priorities and the timeline.
• Technical lead(s) — diagnose and restore.
• Communications lead — translates progress into business updates on a fixed cadence.
• Vendor lead — holds third parties to their contractual response times.

This is not bureaucracy. It is what lets the technical team think clearly while the business stays informed. ITIL describes these practices; the discipline is actually running them at 2 a.m.

3. Restoring service is half the job

Closing a P1 once the service is back is how the same incident comes back next month.

Trust is rebuilt in the follow-through: a clear post-incident review, a root cause the business can understand, and actions with owners and dates. This is where problem management earns its keep. Driving structured root cause analysis and problem management is how my teams cut recurring incidents by 40% — not by fixing faster, but by making sure the same failure could not happen twice.

A good post-incident summary for executives answers five questions on one page:

1. What happened, and what was the business impact?
2. How quickly did we detect, respond and restore?
3. What was the root cause?
4. What are we changing, who owns it, and by when?
5. How will we know it has worked?

What to measure

If P1s are trust events, measure them that way. Alongside mean time to restore, track:

• Time to first business update from the moment the incident is declared.
• Update cadence kept — did every promised update go out on time?
• Repeat incidents — the share of P1s with a cause you have seen before.
• Actions closed on time from post-incident reviews.

These are the numbers that tell you whether the business will trust IT during the next outage.

The standard doesn't change with the altitude

The best major-incident leaders I have worked with are calm, structured and relentlessly clear. They write short messages. They name owners. They do what they said they would do, when they said they would do it.

That is not a technical skill. It is a leadership one — and it is what turns a P1 from a crisis into proof that IT can be relied on.