When the phone company goes down: continuity lessons from October 2023

In October 2023, TSTT, the national telecommunications provider of Trinidad and Tobago, was hit by ransomware. The attackers published a sample of what they'd taken, and the company's first public account of the incident had to be corrected days later. For businesses on the islands it was the moment cyber risk stopped being abstract. If it can happen to the phone company, the useful question for an owner isn't “are we a target?” but “what happens to us when something we depend on goes down?”

That question has two halves, and most continuity plans only answer one. The first is your own recovery: what you do when your systems are the ones encrypted. The second is dependency: what you do when your systems are fine and the outside world isn't. October 2023 was a lesson about the second half that most people filed under the first.

Are your backups worth anything? Three questions

Almost every business we meet has backups. Very few can answer the three questions that decide whether those backups are worth anything.

• When did someone last restore from them? Not check that the job ran, but bring a file, a database or a whole server back and use it.
• How long did that restore take, measured with a clock rather than estimated?
• Is at least one copy somewhere an attacker can't reach from your network, offline or in storage that can't be overwritten?

A backup that has never been restored is a hypothesis. Ransomware crews know this. The usual playbook finds and encrypts or deletes the backups first and the production systems second, because a business with no way back pays. The copy that saves you is the one your own administrator credentials can't delete.

What makes a continuity plan real rather than a document?

The second part of recovery is a plan, and the test of a plan is simple. Print it and hand it to the people who'd execute it at two in the morning. If they've never seen it, you have a document, and a document isn't yet a plan.

The plan needs to settle a few things in advance, because during the incident nobody has the calm to settle them. Who declares the incident, and who's allowed to decide to pay, to shut down, to call the insurer or the regulator. How the team talks to each other when email and the phone system are the things that are down. And the order in which systems come back. That order is a business decision, not a technical one. Invoicing before the intranet. The warehouse scanner before the reporting dashboard. Write it down while nobody is shouting.

What happens when your systems are fine and the outside world is not?

Here's what October 2023 taught, and what it didn't. Most businesses in Trinidad and Tobago weren't attacked. Their systems worked. What failed, for some, was the link between them and their customers, their bank, their cloud software, their card terminals. Nothing in their backup policy covered that, because nothing was lost. The business simply stopped.

Connectivity in Trinidad and Tobago is a design constraint, not a footnote, and the same is true of any single provider your operation sits on. The exercise is a dependency map, and it fits on one page. For each thing you don't control, three answers:

• What stops when it's gone? Not “the internet”, but “we can't take card payments, release orders or see stock”.
• How long can that be tolerated? An hour, a day, a week. Answer honestly and write the number down.
• What's the fallback, and does anyone know how to run it? Paper order sheets, a phone hotspot, a second carrier, a local copy of the price list.

An operation that survives an outage is one that was designed for it. Some functions must run locally, on a machine in the building, and sync when the link returns. Some work can queue. Some decisions need a named person who can act during the gap without asking permission from a system that isn't answering.

How do you rehearse an outage in one afternoon?

None of this needs a consultant to run it, and it doesn't need software. It needs an afternoon. Pick an ordinary Tuesday, gather the five or six people who run the operation, and read out a scenario: “the server is encrypted and the ransom note asks for payment in 72 hours” or “the fibre is down and the provider says two days”. Then walk through it, hour by hour. Who notices first? Who do they call, on what phone? What does the shop floor do at nine? What does finance tell customers who already paid?

The first rehearsal is always uncomfortable, and that's the point. It surfaces the shared password, the backup nobody has restored, the supplier contract with no contact number, the fact that only one person knows how the point of sale falls back to offline mode. Fix those, write a one-page version of what you learned, and do it again in six months. We've watched this exercise change more than most security purchases do.

What does continuity actually cost?

Most of continuity is decisions, and decisions are cheap. The order of recovery, the person who declares, the fallback for card payments, the phone tree on paper: none of it appears on an invoice. Where money is needed, it's specific. A backup copy that's offline or immutable. A restore that has been timed. A second connection, even a modest one over mobile data, for the functions that can't stop. A password manager and a second factor, so the credentials that protect the backups aren't the same ones an attacker finds on a laptop.

What doesn't help is buying a tool first. A continuity product bought before the map exists protects the things the vendor thought of, in the order the vendor chose. The map has to come from the business.

Neither half of the question requires guessing the next incident. Both require deciding, in advance and in writing, what the business does when, not if, something it depends on fails. October 2023 gave every owner on the islands a reason to have that conversation. The businesses that had it are the ones that will describe the next outage as an inconvenience.