Resilience

What still works when something fails?

An organisation does everything resilience planning asks for. Two data centres. Two network providers. A tested backup. A continuity plan signed off by the board.

Then an incident arrives. Both network links turn out to run through the same duct under the same road. Both data centres rely on the same identity service, which goes down with the primary. The backup is intact, but the procedure to activate it assumes a communications channel that has failed with everything else. Every component was duplicated. Nothing was independent.

Most organisations we speak with are not short of resilience measures. What they often lack is a clear answer to a narrower question: when a specific dependency disappears, which essential function still works, for how long, at what level, under whose authority, and with what path back to normal?

That is where resilience stops being a checklist and becomes an engineering property.

Our position is simple to state. Resilience is a property of an essential function under a named failure condition. “Resilient”, on its own, is not a claim anyone can test. “This function continues at this level for this long when that dependency is lost” is.

Start with the function, not the inventory

Resilience work often begins with an inventory: systems, sites, links, backups, suppliers. The inventory is useful. It does not tell you what the organisation is trying to preserve.

We start with the function that must continue. Issuing payments. Coordinating an emergency response. Keeping a public information service available. Operating a water treatment process. Each of these depends on many things at once: power, communications, identity, data, physical access, people, logistics, specialist knowledge and external services.

Only when the function is named does it become possible to ask which of those dependencies matter, which can be lost for a while, and which cannot be lost at all.

The difference is practical. An inventory can show that every system has a backup. Only a function-first view can show that the backups all depend on the same thing.

Duplication is not independence

Redundancy is easy to draw and easy to overstate. A system can contain many copies and still have one point at which they all fail together.

We call the set of things that can be removed by the same event a failure domain. The first question we ask of any resilience design is: what single event could remove both the primary and the fallback? If the answer is the same event, the organisation has duplication, not independence.

Failure domains take different forms, and the most dangerous ones are the least visible.

Physical. Two fibre routes in one trench. Two facilities fed by one transformer. Two sites reached by one bridge. Redundant servers sharing one cooling system.

Digital. One identity provider behind every application. One DNS authority. One cloud account holding production and backup. One deployment pipeline that every recovery depends on.

Operational. One team that knows how to restore the system. One supplier authorised to repair it. One administrator who can recover the keys.

Institutional. One authority whose approval is needed before anyone can act. One handover between organisations with no fallback if it fails. One procurement rule that makes emergency substitution impossible.

Redundancy without separated failure domains is not resilience. The work is not to count copies but to find out which apparently independent paths can still fail together.

A deliberate way to degrade

Continuity does not always mean full service. Sometimes the right outcome is a reduced service that keeps the essential function alive while the rest waits.

That only works if the reduced state has been designed in advance. For each essential function, a resilient organisation knows:

which capability must remain available and which can be suspended;
how long the degraded state must be sustainable;
which decisions can still be made, and by whom;
which data must remain trustworthy;
which safety or security conditions cannot be relaxed;
who has the authority to enter and leave the degraded state.

Without these boundaries, a system can be reported as “available” while no longer performing the function that matters.

Resilience is not the absence of degradation. It is the ability to degrade deliberately without losing the essential function.

Every resilience claim has a boundary

A resilience test that succeeds proves something. It rarely proves as much as it is later taken to prove.

A service that survives the loss of one network path has not shown that it survives a power failure. A site that runs for one hour on backup power has not shown it can run for three days. A recovery exercise carried out with normal communications and identity services available has not shown that recovery works when those services are part of the incident.

We therefore attach to every resilience claim the conditions under which it holds. We call this the failure envelope: what was available at the start, what was removed, for how long, what minimum service was expected, what actually happened, what the result still depended on, and how normal operation was restored.

A successful result inside one envelope does not prove resilience outside it. We prefer a narrow claim that can be reproduced to a broad label that cannot.

This is also where resilience depends on judgement. Test reports, supplier assurances and certifications all make claims about resilience. An organisation able to judge them asks the right question each time: under which conditions was this shown, and are those the conditions we actually face? An organisation that cannot ask that question is relying on a label, however detailed the report behind it.

Planned, tested and proven are different things

Not all resilience evidence carries the same weight. We distinguish four kinds.

Design describes what is intended: architecture diagrams, route plans, recovery procedures. It is necessary, because it tells you what to test. It is not proof that the system behaves that way.

Configuration describes how the system is actually connected and set up. It can diverge from design, and that divergence is itself a risk.

Exercise records what happened when a real dependency was deliberately removed or degraded. This is where a claim begins to move from intent to demonstration.

Incident evidence shows what happened when something failed for real. It often reveals dependencies no exercise anticipated, but conditions are uncontrolled and records may be incomplete.

European regulation is moving in the same direction. DORA requires financial entities to test their digital operational resilience, including through scenario-based testing, rather than rely on documented plans alone. The principle applies well beyond finance: planned capability is not demonstrated capability.

The test ends when normal operation returns

A system that survives the first phase of a failure but cannot return cleanly to normal has not completed the resilience cycle. Recovery has its own dependencies, and they are often the ones nobody examined.

How is the failure detected? Who has the authority to act? Which service comes back first? Which data is authoritative after a period of split or degraded operation, and how is it reconciled? Which credentials and keys are needed, and are they reachable? Does recovery depend on the same path that failed?

A backup that starts but cannot reconcile its data may preserve availability and damage integrity. A site that can operate in isolation but cannot reconnect safely has only postponed the failure.

The test ends when the essential function has returned to its defined normal state, not when the fallback starts.

Failures do not respect organisational charts

The most consequential failures cross boundaries that organisations draw between their departments, their systems and their responsibilities.

A power failure becomes a communications failure. A communications failure becomes an identity failure. An identity failure prevents operators from reaching the tools they need to recover. The large-scale blackout on the Iberian Peninsula in April 2025 showed how quickly a failure in one system reaches transport, telecommunications and retail payments, each of which is planned for separately.

This is why a dependency map that stops at IT systems is incomplete. It needs to include the people, authority, energy, communications, logistics and physical access required to keep a function running and to bring it back.

Two consequences follow for the way we work.

Correlation matters more than any single signal. A communications anomaly, a power irregularity or a logistics disruption may each be routine on its own. The same three appearing around the same function at the same time are not. Resilience depends less on collecting more signals than on seeing when weaknesses in different domains begin to align.

Direction matters as much as position. A static score can hide whether a system is improving or deteriorating. An organisation in reasonable shape but steadily weakening may be at greater risk than one in poor shape but improving quickly.

The same logic applies to functions that cross national borders. Authority changes at the boundary, procedures differ, and equipment or data can cross faster than legal responsibility. Cross-border resilience cannot be shown entirely inside one administration. The exercise has to include the boundary itself.

Knowledge can be a single point of failure

Resilience is not only about assets. A function can become fragile because the ability to restore it sits with one person, one contractor or one team.

Nothing visibly changes when that person retires or that contract ends. The first sign is usually the next incident, when nobody left knows why the system was configured the way it was.

We therefore include knowledge, specialist capability and institutional memory in resilience work wherever they are essential to continuity or recovery. Who knows how to restore this function? Has that knowledge been exercised by more than one person? Could the organisation rebuild it if it were lost?

This is where resilience meets our work on Capability transfer. A system that survives a technical failure but not the departure of one specialist is not resilient. It is lucky.

How we work on it together

Our approach to resilience follows the same sequence as the rest of our work: understand first, then design, then test under conditions that matter.

Name the function. Agree what must continue, and at what minimum level.

Map the dependencies. Across physical, digital, operational, institutional and human layers, and find the failure domains they share.

Design the degraded state and the recovery path. Decide in advance what may be suspended, what must hold, who decides, and how normal operation returns.

Test inside a stated envelope. Remove or degrade a real dependency, record what happens, and state precisely what the result does and does not show.

Leave the ability to judge. The organisation should end with people able to assess the next test report, supplier assurance or incident on its own.

When we look at an essential function together with a partner, these are the questions we typically record:

Question	What it reveals
Which function must continue, and at what minimum level?	What resilience is actually for.
What does it depend on across every layer?	The full dependency graph, not only IT.
Which of those can fail together?	The real failure domains.
Which scenario are we testing, and for how long?	The envelope of the claim.
Who can act during the failure?	Whether authority survives the incident.
What actually happened when we tested it?	The difference between design and behaviour.
How was normal operation restored?	Whether the cycle was completed.
Which change would make this result invalid?	When the evidence expires.

The last question matters more than it seems. A changed route, identity provider, power arrangement, supplier or procedure can invalidate an earlier result without changing the name of the service. Resilience evidence has a lifecycle, and it should be reviewed when the system beneath it changes.

Where we are careful

We hold ourselves to a few commitments about what we claim.

We do not call a system resilient because it has a backup, and we do not call two systems independent until we understand what they share.

We do not generalise from a successful component test to a claim about the whole system, and we do not treat a simulation as proof of physical behaviour.

We do not present planned capability as achieved capability. Where something has been designed but not yet tested, we say so.

We do not treat recovery as an afterthought, and we do not replace a sense of direction with a single score.

And we do not describe anything as resilient without naming the function, the failure condition, the boundary and the evidence.

Changes to this position

24 September 2026 — First published.

Material changes are listed here with their date. Corrections of wording or links are not.