A spare tire is the only thing you buy hoping never to use it, and the only thing whose absence you discover at the worst possible moment. Organizations treat their suppliers the same way: they buy capacity, uptime and support, and they never buy the hour after the failure. The failure itself is not the expensive part, because the failure belongs to the vendor. The expensive part is the stretch of time in which the organization has no options, no fallback and no one authorized to improvise. That stretch of time is an executive decision, and almost nobody makes it.
Every organization already knows its suppliers will fail
Ask any executive whether their telecom operator could go down for a full day. They will say yes. Ask whether their core SaaS could be unavailable for an afternoon. Yes. Ask whether a critical security patch could force an emergency maintenance window on a Tuesday morning. Yes again.
Nobody argues with the premise. The belief is not that failure is impossible. The belief is that failure is somebody else’s problem, and that it will be short.
Autumn 2026 made the point with unusual density. On 21 October, a French mobile operator lost voice, SMS and mobile data for close to ten hours, from roughly 11:30 to 21:00, attributed to a faulty piece of core network equipment. It was the third national outage at the same operator that year, after 30 January and 29 June. In the same week, two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were disclosed: unauthenticated remote code execution against essentially any PHP installation serving web requests, with an exploitation attempt observed in the wild on 17 October, before public disclosure. GitLab shipped a fix for CVE-2026-110264, rated CVSS 10.0, affecting every self-managed release since 2014, with no workaround available. A Fortinet flaw tracked as CVE-2025-61624 was flagged by Hong Kong’s GovCERT on 21 October as actively exploited across FortiOS, FortiProxy, FortiPAM and FortiSwitchManager.
None of these events are related. That is the point. They are not a crisis, they are the normal background rate of a connected organization, compressed into one readable week.
An executive reading that list correctly concludes two things. First, that none of it was preventable from a board room. Second, and this is the part that usually goes missing, that the only variable under their control was what their own company did between the moment something stopped and the moment it came back.
The spare tire is the only purchase whose value never shows up at the moment you make it
A spare tire weighs around fifteen kilos. You carry those fifteen kilos every single day, for years, at a measurable cost in fuel and cargo space. Car manufacturers know this, which is why more and more vehicles ship with a sealant kit instead, or with nothing at all.
The economics look terrible right up until the evening they do not.
This is the structural problem with every fallback ever designed. Its cost is continuous, visible and attributable to a budget line. Its value is discrete, invisible and only realized once. Worse, when it works, it produces no evidence at all: the evening where you change the tire in twenty minutes and drive home is an evening nobody remembers, because nothing happened.
Organizations are not built to reward that shape of value. Every management system rewards the visible: revenue, throughput, utilization, cost per unit. A capability whose entire output is the non-occurrence of a bad day has nothing to report into those systems. It shows up as a cost with no line in the result.
So it gets deferred. Not denied, deferred. The tire pressure check slides a quarter. The restore test slides a quarter. The second SIM card never gets ordered because the person who would order it is also the person running the quarter.
And this is the honest version of how organizations end up with no fallback. Nobody ever decided to drive without a spare. The decision was never taken at all. It accumulated out of a sequence of individually reasonable postponements, each of which was correct in isolation and catastrophic in aggregate.
Organizations optimize the nominal path because the nominal path is the only one that generates evidence
There is a deeper reason, and it has nothing to do with discipline.
An organization learns from the things it does repeatedly. Every process you run a hundred times a week gets faster, cheaper and more robust, because a hundred repetitions per week generate a hundred signals per week. That is how operational excellence actually happens: not through intention, through volume.
Degraded mode has a repetition rate of roughly zero.
It is run once every few years, usually under stress, usually by whoever happens to be in the building, usually without anyone having read the plan in the previous eighteen months. It gets no repetitions, so it accumulates no learning, so it stays amateur forever while everything around it gets professional.
This asymmetry explains something that otherwise looks like negligence. The same company that can route a thousand orders a day with four percent error will, on the day its ordering system is unavailable, lose an entire afternoon arguing about whether anyone is allowed to take an order on paper. It is not that they are bad at operations. They are excellent at the operations they practice, and they have never practiced this one.
Business continuity literature has named this for decades. NIST’s SP 800-34 Rev. 1, the federal contingency planning guide, is built around exactly that insight: continuity only exists as a tested capability, tied to an impact analysis and exercised on a schedule, and a document on its own buys nothing. The vocabulary of recovery time objective and recovery point objective exists precisely so that an organization is forced to put a number on something it will almost never experience. Most mid-size organizations have never written either number down. Not because they rejected the idea, because nobody ever asked them the question in a form they could answer.
A composite case: two days a distributor never got back
What follows is a composite. It assembles patterns observed across several organizations into one narrative, with identifying details removed. No single client is described, and no figure is attributed to a real company.
A regional distributor, roughly eighty people, three warehouses, a catalogue of several thousand references. Classic profile: not a tech company, deeply dependent on tech. Orders arrive by phone, by email and through a customer portal. Everything lands in a single ERP, hosted by the vendor, accessed over the internet. Stock levels, pricing, picking lists, delivery notes, invoicing, all of it.
The ERP contract is solid. There is an availability commitment. There is a support line. There is, somewhere in a shared drive, a continuity annex that nobody has opened since signature.
One Tuesday, the hosting region serving that ERP becomes unreachable. Not destroyed, not breached, simply unreachable. The vendor’s status page acknowledges it within the hour and promises an update in sixty minutes. It will take until Wednesday afternoon for service to fully return.
Here is what the first hour looks like inside the distributor.
The warehouse supervisors realize they cannot print picking lists. The morning wave is already picked, so nothing stops immediately. The afternoon wave is the problem. Nobody knows what is in it, because the list lives in the ERP.
The sales desk keeps answering the phone, which is the good news, and keeps taking orders on sticky notes, which is the bad news. Three people are taking orders on three different sticky-note systems. Nobody is checking stock, because stock is in the ERP. By eleven, the desk has committed to several deliveries that it will turn out cannot be fulfilled, and committed them at prices read from memory, some of which have changed since the last tariff revision.
The delivery drivers come back at noon with signed delivery notes and no way to close them out.
By early afternoon, the general manager asks the obvious question: do we have a copy of the stock file. The answer is yes, there is a nightly export. This is the moment the day turns.
The nightly export exists. It has been running faithfully for four years. It is written to a folder on the same hosted environment, because that is where the integration was easiest to set up. It is, at this precise moment, exactly as unreachable as the ERP it was supposed to protect.
Someone remembers that finance pulls a monthly extract for the accountant, and that extract lives locally. It does. It is five weeks old. It contains stock as of the first of the previous month, which for a distributor is roughly the same as containing nothing.
So the afternoon is spent reconstructing, by hand, an approximate picture of what is in three warehouses, from paper delivery notes and the memory of four supervisors.
Wednesday morning, the service is still down. The company makes its first genuinely consequential decision of the incident: it stops taking new orders, because it has concluded that taking orders it cannot price or fulfil is worse than taking none. That is probably the right call. It is also a call that was made twenty-six hours into the incident, by exhausted people, with no prior framework.
Service returns Wednesday afternoon. And now the second cost arrives, the one nobody budgets for.
Two days of orders have to be entered into the ERP by hand, from sticky notes, in parallel with the current day’s normal volume. That takes the rest of the week, in overtime. Several of the committed prices were wrong and have to be either honoured at a loss or renegotiated with customers who are already annoyed. Stock levels are wrong for a fortnight, because physical movements happened without system entries, and the discrepancies only surface as picking errors over the following two weeks. One large customer, who called twice on Tuesday and got a sales desk that could not confirm anything, places their next quarter’s order elsewhere. Nobody ever connects that loss to the outage, because by the time it shows up in the pipeline, the outage is a month old and has been filed as resolved.
Add it up and the incident is not thirty hours long. It is roughly three weeks long, and only the first thirty hours are visible as an incident.
Now look at what would have changed it. Not a second ERP. Not a disaster recovery site. A weekly stock and price export, in a plain format, stored somewhere other than the system it is protecting. A pre-printed order form with a sequential number. One sentence of written policy saying who is allowed to commit a price when the system is unavailable, and up to what amount. A rule that says orders taken on paper are entered within four hours of restoration, by a named person, before anything else.
None of that is sophisticated. None of it requires a project. All of it had to exist before Tuesday, and none of it did, because on Monday it was worth nothing.
Recovery time is a number the executive owns, not the vendor
The most useful thing an executive can take from all this is that there are two numbers, and only one of them is for sale.
The first number is how long the supplier takes to come back. That one belongs to the supplier. You can negotiate it, you can pay more for a better commitment, you can read the status page. You cannot influence it on the day.
The second number is how long your organization takes to resume useful work once the supplier is back, and how much useful work it managed to do while the supplier was away. That number belongs entirely to you. It is set months in advance, by whether a fallback exists, whether anyone has opened it, and whether anyone is authorized to use it without asking.
Most organizations spend their attention on the first number and discover the second one live, under pressure. In the distributor’s case, the vendor’s number was about thirty hours, which is bad but not unusual. The company’s own number was closer to three weeks. The second number was four times worse than the first, and it was the only one they controlled.
This reframing matters because it moves the problem from procurement to management. As long as continuity is understood as something you buy from a vendor, it stays in a contract annex and nobody reads it. The moment it is understood as a property of your own organization, it becomes a management question with a familiar shape: what must keep running, who decides, and what are they allowed to do.
Degraded mode is a decision, and decisions require someone to make them
There is a specific piece of work here, and it is short.
It begins by naming what must continue no matter what. Not everything. Three or four things. For most organizations the list is some combination of: get paid, deliver, stay reachable, meet a regulatory obligation with a deadline. Saying out loud that everything else can stop for two days is, for a lot of executives, the most relieving sentence of the exercise.
Then, for each of those three or four things, you walk the chain backwards. Which supplier, which access, which network, which single person. And for each link, the question that is never asked: what happens when this one is gone for a day.
Then you write the fallback. It should be embarrassingly unsophisticated, because sophisticated fallbacks fail for the same reasons the primary system failed. A SIM card from a different operator in a drawer. Numbered paper order forms. A contact address outside the main domain. A weekly export in a format anyone can open without a licence, stored somewhere unrelated to the system it protects.
Then, and this is the part that separates a plan from a capability, you run it. A chosen Tuesday morning, you cut for real and you time it. You find out that the export is on the wrong server. You find out that the one person who knows the decryption key left last year. You find out that restoration takes thirty hours and not two. You find all of it out on a calm morning, at a cost of half a day, instead of during an incident, at a cost of three weeks.
Nobody does this step alone, and the reason is not technical. It is that running the test means accepting in advance that it will fail, in front of your own teams. That is much easier with a third party in the room whose job is to find the failure rather than to have prevented it.
Someone has to open the trunk
The uncomfortable conclusion is that resilience is not a property of good systems. Plenty of organizations with excellent systems are one supplier outage away from a lost fortnight, and some organizations with mediocre systems recover in an afternoon because somebody, once, thought about it.
What separates them is not budget and not maturity. It is whether a single decision was ever taken, in calm conditions, by someone with the authority to take it.
Nobody checks the spare tire on the hard shoulder. By then, the only thing left to find out is whether it is there.
Sources
- Panne Orange du 21 octobre 2026 et récapitulatif des trois coupures nationales de l’année: stephanelarue.com
- PHP2Shell, CVE-2026-109618 and CVE-2026-109619, disclosure and patched versions: Help Net Security
- GitLab CVE-2026-110264, CVSS 10.0, self-managed releases since 2014: The Hacker News
- Fortinet CVE-2025-61624, actively exploited, GovCERT.HK alert A26-10-30: GovCERT.HK
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems: NIST CSRC
FAQ
Why do organizations lack a fallback plan even though they know their suppliers will eventually fail?
Because a fallback’s cost is continuous, visible and attributable to a budget line, while its value is discrete, invisible and only realized once — and when it works, it produces no evidence at all. Nobody decides to drive without a spare tire; the decision accumulates from a sequence of individually reasonable postponements. An organization also learns only from what it repeats: degraded mode has a repetition rate of roughly zero, so it stays amateur while everything around it gets professional.
What are the two recovery numbers an executive needs to distinguish after a supplier outage?
The first is how long the supplier takes to come back — it belongs to the supplier and you can only negotiate it in advance. The second is how long your own organization takes to resume useful work once the supplier is back, and how much it managed to do in the meantime — that number belongs entirely to you, and is set months in advance by whether a fallback exists, whether anyone has opened it, and whether anyone is authorized to use it without asking. In the composite case here, the vendor’s number was about thirty hours and the company’s own was closer to three weeks.
