When you have to switch everything off, how do people reach you?

On 21 October, PHP released emergency fixes for two critical vulnerabilities, now known as PHP2Shell, that let an attacker run code on a web server without logging in. The NCSC warned more than 50,000 UK organisations that they were exposed, and its advice was to patch or, if you couldn't patch straight away, take the system offline.

So a lot of organisations did. 32 UK government services went offline. Oxford City Council and the City of Edinburgh Council took their websites down. On 26 October, CISA in the US confirmed that both flaws were being exploited.

That was the right call, and most of those sites came back quickly. But it got me thinking about the phones.

The outage you choose

Most disaster recovery plans I've seen are written around things that happen to you: a fire, a flood, a power cut, a cloud region going down. Those are still real. But a cyber incident increasingly involves a different kind of outage, which is the one you choose. When something is compromised, or might be, the safe thing to do is switch it off and contain it.

We saw this in 2025. Co-op shut down parts of its back office and call centre operations to contain an attack, and told staff that their usual communication channels might be monitored. That was a sensible thing to do, and it's a very hard position to be in.

In most organisations, almost everything hangs off one sign-in. Email, Teams or Slack, the intranet, the VPN and very often the contact centre too. If you have to stop trusting that sign-in, all of them go dark together, and the people who most need to hear from you are left guessing.

Your contact centre belongs in your minimum viable company

Incident plans usually define a minimum viable company: the smallest set of systems and people you need to keep operating while everything else is rebuilt. I think customer contact belongs in it, and in most plans I've read it isn't there.

Two groups of people still need to reach you. The first is obvious. Customers, patients, residents and citizens keep calling, and some of them are vulnerable or have something genuinely urgent. If your website is offline, the phone is all they have left.

The second group gets missed, and it's your own colleagues. If nobody can log in, how do you tell everyone not to log in? How do they find out whether to come into the office tomorrow, whether they can use their laptop, or whether that text from "IT" asking them to approve a sign-in is genuine? In most plans, the answer is an email or a Teams or Slack message, which is exactly what you've just switched off.

A standby contact centre, independent of your sign-in

This is where Amazon Connect Customer is a particularly good fit, because of how it's priced. There are no seat licences and no monthly minimums. You pay for what you use, plus telephony. That means you can build a complete standby contact centre in advance and leave it ready for a small running cost.

I want to be honest about that cost. "You only pay when you use it" is nearly true, but not exactly. Phone numbers carry a small daily charge, and you'll want to test the standby every quarter, which uses some minutes. It isn't free. It is small next to the cost of a day when nobody can reach you.

Because it runs in a browser, agents can work from home on any device, and if laptops have been quarantined, calls can go to people's mobile phones instead. You can also put an AI agent on the front of it, loaded in advance with the answers your website would normally give, so the people you do have can focus on the callers who need a person.

The part most backup plans get wrong

A standby only helps if it doesn't fail at the same time as everything else. This is where I'd spend most of the design effort.

That means a separate AWS account, with its own users and its own sign-in, not connected to the identity provider you might have to stop trusting. It means the account's recovery email addresses live on a domain outside your main Microsoft 365 or Google tenant. And it means the people who can get in during an incident hold their break-glass credentials and hardware security keys somewhere that doesn't need the corporate network.

Moving the phone numbers

The next question is how calls to your normal numbers reach the standby. The instinctive answer is to port the numbers, but porting isn't a crisis tool. UK ports can take days, sometimes weeks.

What works is diversion you've agreed in advance. Ask your carrier now whether your numbers support a pre-agreed disaster recovery routing plan, how quickly it can be switched on, and how they'll verify the person asking.

That last part is a trap worth checking. Think about how you log in to your carrier's portal, and how you'd recover that login. For most organisations it's a corporate email address, which is the thing you won't have. Write down the account details, the support number and who is authorised to request a diversion, and keep them somewhere that doesn't need your corporate systems.

What the staff line looks like

The internal line is the part I find most interesting, and it's what I've built for the demo in this video. The company, Fenmoor Group, is made up. The calls are dramatised by CloudInteract colleagues on a real Amazon Connect Customer instance, and the AI agent and narrator voices are AI-generated.

The number is published before you need it. It goes on the emergency contact card, the back of the ID badge and the induction pack, and gets reshared every quarter, so it's already in people's phones on the day.

When the incident starts, an admin calls the line from a phone, enters a PIN and records the update: don't use any work computer, don't log in to any work system, don't use the VPN. No console, no laptop. Every colleague gets a text to say there's a new update, from a contact list synced regularly to somewhere outside the corporate estate. When they call, they hear the update, and an AI agent answers the questions everyone asks.

When the facts change, the answers change. In the demo, a colleague asks whether she can use her laptop and is told to keep it switched off. Later the admin calls in again to say the laptops have been checked, and the same question gets a new answer. The latest update always wins over the pre-written guidance.

Don't create a new way in

There's one warning I'd add. Contact centres and helpdesks are themselves a way into organisations. Helpdesks were reported as a way in during some of the 2025 retail attacks, with someone phoning up and talking their way into a password reset.

So the emergency line gives information, and that's all it does. It never resets passwords, never changes account details, never approves access and never shares anyone's contact details, whoever the caller says they are. In the demo the caller tries three times: locked out, then "I'm an IT director", then "the CEO has authorised it". The answer doesn't change. When she mentions a text asking her to approve a sign-in, the agent tells her not to approve it and passes it to the incident team. We've made that a hard rule for the AI agent, and it belongs in the human script too.

Where to start

None of this needs a big project. Most of the work is deciding what the lines should do, setting up the standby account properly, agreeing the diversion with your carrier and publishing the staff number. We've written it up as two short playbooks: Prepare now, and The first 72 hours. You can download both, or book a readiness review and we'll walk through them against your setup.