A CTP Incident Comms Playbook for Firms Reliant on Hyperscalers

When a designated critical third party has a major outage, the regulators start overseeing the provider — but your own notification clock to the FCA, the PRA and your customers keeps running exactly as before. Nobody drafts good regulatory prose while a hyperscaler is down.

From Monday 13 July 2026, the Bank of England, the PRA and the FCA begin overseeing the first critical third parties (CTPs) designated by HM Treasury: Amazon Web Services, Microsoft, Google Cloud and Oracle. It is easy to read that as a transfer of responsibility — the cloud providers are supervised now, so the pressure moves to them. That reading is wrong, and the regulators have been explicit about it. Designation does not diminish the responsibilities of the firms that rely on these providers. When AWS or Azure has a bad day, your important business services degrade, and the obligation to tell your regulator and your customers is still entirely yours.

The gap most firms have is not detection. It is the twenty minutes after detection, when someone has to write to a supervisor and to a customer base under time pressure, from a blank page, while the incident bridge is still shouting. That is what a comms playbook fixes.

The clock you actually own

The CTP regime does not create your notification duties. Your existing obligations do, and they were already demanding before any hyperscaler was designated. Under the operational resilience rules the FCA and PRA expect firms to have been fully compliant with since 31 March 2025, you must stay within the impact tolerances you have set for each important business service. A CTP outage that pushes a service past its tolerance is, for supervisory purposes, your disruption — not the provider’s.

On top of that sit the general notification duties. FCA Principle 11 and SUP 15 require you to tell the FCA about anything of which it would reasonably expect notice; the PRA’s Fundamental Rule 7 requires open and cooperative disclosure. Neither has a fixed number attached — you must exercise judgement on the day — which is precisely why an improvised judgement made at 02:00 on a degraded platform is the wrong place to be making it.

And a harder clock is coming. The FCA and PRA have finalised operational incident reporting rules that apply from 18 March 2027. Enhanced firms will owe an initial report within 24 hours of judging that an incident meets the threshold (four hours for payment service providers from detection), interim updates as things change, and a final report with root-cause analysis within 30 working days. If your comms artefacts are not built and rehearsed before that regime bites, you will be building them twice.

Why improvised messaging fails

Two failure modes recur. The first is saying too much, too early: naming a root cause you do not yet understand, promising a restoration time you cannot meet, or attributing the fault to the provider in terms you later have to retract. A supervisor reads an over-confident first notification and then watches you walk it back, and the credibility cost outlasts the outage.

The second is saying too little, too slowly, because nobody is sure who has authority to send. The message sits in a review queue while the impact tolerance breach widens, and the regulator learns about your disruption from the newspapers rather than from you. Both failures come from the same root: no pre-agreed template, no pre-agreed decision rule, no pre-agreed sender. You cannot manufacture those in the middle of the incident.

The artefacts to build now

A working playbook is small and specific. It contains, at minimum:

• A regulator notification template for each supervisor you answer to, with fixed fields — which important business service is affected, current position against its impact tolerance, customer impact, the CTP involved, actions in train — and deliberately blank spaces for what you do not yet know. “Root cause under investigation” is a complete and honest answer at hour one.
• A customer holding statement that describes impact and workaround without naming a cause or a fix time. Version it for each channel: status page, in-app banner, contact-centre script, and — if you serve them — a wholesale-counterparty note.
• A decision tree that maps observed impact to a notification action, so the responder is choosing from a branch rather than composing a policy.
• A named-role sign-off matrix — who can authorise a regulator notification, who can authorise customer comms, and who deputises when they are unreachable, by role not by name.
• An out-of-band channel, because if the outage is in the same cloud that hosts your email, your status page and your comms tooling, the playbook has to assume its own primary channel is gone.

The decision tree is the piece people skip, and it is the piece that saves the incident. It should answer, in order: is an important business service degraded; is it past or trending past its impact tolerance; is customer detriment occurring now; and does the combination cross the threshold at which Principle 11 or Fundamental Rule 7 disclosure is owed. Each terminal branch names the template to send, the sender, and the target time. That last mapping is what turns a judgement call into a rehearsed action. Building it well depends on already knowing which of your services actually ride on each designated provider — the work covered in our reading of the FCA critical third party regime and its technology implications.

Rehearse it before the regime is live

A template nobody has used under time pressure is a document, not a capability. Run a tabletop against a plausible scenario — a multi-hour regional outage at one of the four designated providers, on the service you would least like to lose — and time the path from detection to a sent regulator notification and a live customer statement. The first run is always slow and reveals the sign-off ambiguities you did not know you had. That is the point of doing it before 13 July 2026 rather than after.

Firms with real concentration in one provider should stress the scenario harder, because the correlated-failure case is where a single outage takes down several important business services at once and multiplies the notification load — the dynamic examined in cloud concentration risk under DORA, SS1/21 and the CTP regimes. If you have not yet mapped which services sit on which provider, that register is the prerequisite, and it is the first thing reliant firms should have done once the designations were named.

The regulators supervising the hyperscalers will not draft your notifications, extend your impact tolerances, or explain your outage to your customers. When the provider goes down, the only messaging within your control is the messaging you wrote and rehearsed while the platform was still up.