What Is Cyber Resilience?

Cyber resilience is the ability to keep delivering intended outcomes despite adverse cyber events. It differs from conventional security in its starting assumption: that prevention will fail, and the question is what happens next.

The framing matters because it changes where investment goes. A prevention-centred programme buys controls; a resilience-centred one also buys detection, response capability, recovery capability and the ability to operate degraded.

Why the framing emerged

Because the evidence stopped supporting the alternative. Well-resourced organisations with mature control environments are compromised regularly, which makes a strategy premised on not being compromised unfalsifiable and unhelpful.

Accepting that compromise will occur permits a different set of questions: how quickly would we know, how far would it spread, how long would recovery take, and could we keep operating meanwhile.

The components

Anticipate — understand what threatens you and prepare. Withstand — controls that limit initial success and segmentation that limits spread. Recover — tested restoration and documented procedures.

Adapt — change something as a result, which is the component most consistently skipped. An organisation that experiences the same incident twice has demonstrated the absence of this one.

What it looks like in practice

Segmentation, so one compromise is not all of them. Immutable, tested backups. Documented manual procedures. Pre-authorised containment decisions. Out-of-band communications. An incident response plan that has been exercised.

None of these prevent an attack. All of them determine the consequence, which is the measure resilience uses.

Regulators have adopted the language

Operational resilience requirements in financial services, and equivalent expectations in several other regulated sectors, now require identification of important business services, stated impact tolerances, mapping of dependencies and evidence of testing.

That is resilience expressed as a compliance obligation, and it raises the bar considerably above holding a plan — the requirement is to demonstrate you can stay within a tolerance.

Measuring it honestly

Recovery time actually achieved in tests. Proportion of critical systems with tested restores. Detection and containment times. Whether exercises produced changes. Whether incident findings were implemented.

These are harder to present than a count of blocked attacks and they describe something real, which is why they belong in board reporting rather than alongside it.

Degraded operation is the capability nobody builds

Between fully working and fully down there is a middle state that most organisations have never designed for: core functions available, non-essential ones suspended, some data unavailable, manual steps filling gaps.

Designing for that deliberately — knowing which functions are shed first, which data can be stale, what runs without the central system — converts a binary outage into a manageable reduction in service. It is architecture and process work rather than a purchase, which is why it is consistently deferred.

Supply chain resilience belongs in the same assessment. Where a critical service depends on a provider, your ability to operate through their incident is part of your resilience and is frequently unexamined beyond a contractual availability figure. The questions worth answering in advance are whether an alternative exists, how long switching takes, and how many of your critical services rest on the same supplier.

Where to start

Ask what would happen if your most important system were unavailable and untrusted for two weeks. The completeness of the answer is your current resilience.

See operational resilience requirements. GuardsArm delivers security strategy.