When Cyber Attacks Stop the Business: Can You Prove What Must Be Restored First?

Cyber resilience is easy to discuss when everything is working.

There are business continuity plans, disaster recovery procedures, backup schedules, incident response playbooks and lists of supposedly critical systems. Recovery time objectives are recorded. Responsibilities are assigned. Exercises may even have been conducted.

Then the organisation suffers a major cyber attack.

Identity services are unavailable. Laptops cannot authenticate. Cloud applications depend on credentials nobody can validate. Backups exist, but nobody is yet certain they can be trusted. Key suppliers are also needed to recover systems. Staff start creating manual workarounds. Customers want to know when services will return. Regulators want information. Senior management needs to decide what should be restored first.

At that moment, the question is no longer:

“Do we have a recovery plan?”

It becomes:

“Can we prove what the organisation must recover, what it depends upon, and whether we can restore it safely?”

That distinction sits at the heart of new guidance published by the UK National Cyber Security Centre on 28 July 2026 for organisations recovering from highly disruptive cyber attacks. The NCSC divides recovery into immediate response, recovery to minimum viable operations, and the longer-term organisational rebuild.

It is a useful change in emphasis.

Cyber recovery is not fundamentally about restoring computers.

It is about restoring the organisation.

Minimum Viable Operations Changes the Question

The NCSC defines Minimum Viable Operations, or MVO, as the lowest level of operational capability at which an organisation can continue to operate safely, meet legal and regulatory obligations, and maintain trust with customers, partners and employees.

That sounds straightforward until an organisation attempts to define what its own MVO actually is.

Does the payroll system need to operate?

What about customer billing?

Can orders be accepted without the main ERP platform?

Can a hospital deliver safe services without access to every clinical system?

Could a managed service provider continue supporting customers if its primary remote-management environment were unavailable?

How long could the organisation operate without email?

What if Microsoft Entra ID, Active Directory or another central identity service were unavailable?

Which regulatory reports would still have to be submitted?

Which suppliers would have to be functioning before internal systems could recover?

And critically:

Which losses would become unacceptable first?

These are business questions before they are technology questions.

The NCSC makes that explicit. During initial incident triage, organisations are advised to identify critical business functions and assess how they have been affected. It states that the needs of the business should drive recovery prioritisation rather than IT considerations alone. Organisations should then identify the systems—and the systems on which those systems themselves depend—that underpin those critical functions.

That creates an important chain:

Business outcome → critical function → service → system → dependency → recovery capability

If any part of that chain is missing, recovery planning is based partly on assumption.

The Problem with “Critical Systems”

Many organisations maintain a list of critical IT systems.

That is useful, but it can also create false confidence.

A CRM platform may be labelled critical because large numbers of employees use it. A relatively obscure identity service may receive a lower classification despite being necessary before dozens of other systems can operate.

A financial application may have excellent backups but depend on a database, network segment, encryption key, cloud tenant, privileged account and specialist supplier that do not share the same recovery capability.

A SaaS platform may appear highly resilient while access to it depends entirely on a compromised corporate identity platform.

The NCSC specifically identifies trusted identity as a critical recovery dependency. If attackers have compromised existing accounts, created new accounts or damaged confidence in the organisation’s identity infrastructure, other recovery activities may have to wait until a trusted source of identity can be re-established.

This illustrates why resilience cannot be understood by assessing individual systems independently.

A system can be resilient in isolation and still be unavailable because something beneath, beside or outside it has failed.

The Dependency Problem

Modern organisations are built from dependencies.

Applications depend on identity.

Identity depends on networks, directories, certificates and privileged administration.

Business processes depend on applications.

Applications depend on cloud services, APIs, databases and third-party components.

Recovery may depend on backup infrastructure.

Backup infrastructure may depend on the same identities that were compromised.

External suppliers may need privileged access before systems can be restored.

Connectivity to partners may remain disabled until those partners receive assurance that the compromise has been contained.

The NCSC consequently advises organisations to identify common infrastructure supporting multiple business services, understand dependencies between infrastructure and business systems, and plan recovery sequencing around them. It also warns organisations to assume backups may have been targeted and to obtain appropriate assurance that they remain trustworthy.

This creates a problem for conventional business continuity documentation.

A diagram or spreadsheet can record that one system depends on another. It does not necessarily demonstrate:

whether the dependency is complete;

who verified it;

whether it remains current;

whether the supporting control has been tested;

whether the supplier can meet the assumed recovery time;

whether a backup has actually been restored;

whether credentials required for restoration would remain available;

whether alternative operating procedures work;

whether the recovery sequence has ever been exercised.

The difference is the difference between information and assurance.

A Backup Is Not Evidence of Recoverability

Perhaps the most common example concerns backups.

An organisation may report:

“Our critical systems are backed up every night.”

That sounds reassuring.

But assurance requires deeper questions.

When was the last successful restoration test?

Was the complete service recovered, or only the underlying data?

How long did it take?

Were identities, certificates, configuration, applications and dependencies included?

Could the restoration be performed if the production administration environment were compromised?

Are backups immutable?

Could an attacker delete or encrypt them?

Are the credentials required to access them protected independently?

Would restored systems still contain the vulnerability through which the attacker originally gained access?

The NCSC specifically cautions that backups may not cover the entire operating environment, including applications, identity systems and sources of trust. It advises organisations to assess their availability, completeness and reliability rather than simply assuming that their presence guarantees recovery.

That is an assurance problem.

Evidence that a backup job completed is not equivalent to evidence that an essential business service can be restored.

Recovery Plans Need Evidence Before the Incident

The worst time to discover that a recovery assumption is unsupported is during the recovery itself.

The NCSC Cyber Assessment Framework already reflects this principle. CAF Objective D states that response and recovery plans should be grounded in comprehensive risk assessment, prioritise essential functions and the assets needed to support them, and be auditable and testable using realistic exercises.

This means a mature organisation should be able to demonstrate before an incident:

What matters.

Which organisational outcomes, services and obligations cannot be allowed to fail beyond an acceptable level.

What they depend upon.

The people, information, applications, infrastructure, identities, suppliers and other services necessary to deliver them.

What controls protect them.

Preventative, detective, response and recovery controls.

What evidence demonstrates those controls work.

Test results, exercises, restoration records, configuration evidence, supplier assurance, technical assessments and operational records.

What remains uncertain.

Assumptions, missing evidence, weaknesses and accepted risks.

That creates something much more valuable than a business continuity document.

It creates a defensible resilience position.

This Is Increasingly a Board-Level Responsibility

The direction of UK cyber governance is also changing.

The government’s Cyber Governance Code of Practice explicitly asks boards to gain assurance that the technology, processes, information and services critical to organisational objectives have been identified and prioritised. It also expects boards to define cyber risk appetite, integrate cyber risk with wider enterprise risk management and gain assurance over important suppliers.

The government’s Cyber Resilience Pledge reinforces this direction, asking organisations to make cyber security a board responsibility and implement the Cyber Governance Code. More than 60 organisations were announced as early participants in July 2026.

The threat environment provides good reason.

Government figures published alongside the pledge state that the NCSC handled 204 nationally significant incidents in the year to September 2025, compared with 89 in the previous year. Government-commissioned research estimates the annual cost of cyber attacks to UK organisations at approximately £14.7 billion.

For boards, therefore, asking whether backups exist is no longer sufficient.

A stronger question is:

“Show me the evidence that we can continue operating when the systems supporting our most important business outcomes are unavailable.”

Where CyConex Changes the Assurance Model

This is precisely the kind of problem CyConex is designed to address.

Traditional cyber assessments begin with a framework and ask whether individual controls have been achieved.

CyConex can go further by bringing the assessment into the context of the organisation itself.

Start with What the Business Cannot Afford to Lose

CyConex allows organisational and project context to be captured alongside the assessment, including risk appetite and unacceptable losses.

That is important because not every control has equal business significance.

A weakness affecting an isolated internal application is different from the same weakness affecting the identity platform supporting every operational service.

By connecting assurance to organisational context, findings can be considered according to the outcomes they could affect rather than simply the control number against which they were identified.

The conversation changes from:

“Control D1 is partially achieved.”

to:

“The evidence does not yet demonstrate that the organisation can restore the identity capability required to recover three critical services within its stated tolerance.”

That is much more useful information.

Turn Recovery Assumptions into Evidence Questions

CyConex can ingest and analyse the artefacts organisations already maintain:

business continuity plans;

disaster recovery procedures;

business impact assessments;

architecture documentation;

asset information;

backup policies;

restoration-test results;

incident response procedures;

exercise reports;

supplier assurance evidence;

risk registers;

technical configurations;

policies and standards.

Instead of treating the existence of those documents as proof, CyConex assesses the relevant content against the obligations being examined.

A policy might prove that restoration testing is required.

A recovery procedure might demonstrate how restoration should occur.

A completed test report provides stronger evidence that it actually works.

An exercise demonstrating recovery of the complete business service provides stronger evidence again.

CyConex can distinguish between policy, process, design and test evidence, allowing assurance conclusions to reflect the strength of what has actually been demonstrated.

Expose Missing Evidence Before It Becomes a Crisis

One of the most valuable outcomes of assurance is discovering what is not known.

CyConex can identify where available evidence only partially supports a recovery claim.

Perhaps the organisation has:

a documented recovery time but no recent restoration evidence;

tested database recovery but not application recovery;

tested an application but excluded identity failure;

supplier recovery commitments without independent evidence;

business continuity procedures that assume corporate email remains available;

backup evidence without evidence of immutability;

incident exercises that never tested loss of administrative access.

These are precisely the assumptions that can turn a manageable incident into a prolonged operational crisis.

Finding them during an assessment creates an opportunity for remediation.

Finding them during ransomware recovery creates pressure, delay and potentially serious business harm.

Create Traceability from Requirement to Evidence

CyConex provides traceability between:

Framework requirement → obligation → evidence → assessment rationale → conclusion

That matters because resilience claims must withstand challenge.

A board, assessor, regulator or customer should be able to ask:

“Why do we believe this control is effective?”

and receive an answer supported by identifiable evidence rather than an assertion buried in a spreadsheet.

CyConex’s evidence-assessment approach also enables the same artefacts to support multiple assurance requirements.

A successful recovery exercise may provide evidence for CAF, ISO 27001, organisational risk management, customer assurance and internal governance simultaneously.

The evidence is not recreated for every framework.

It is reused intelligently.

From Periodic Assessment to Living Resilience

Recovery capability also changes.

Infrastructure changes.

Cloud services are migrated.

Suppliers change.

Applications are replaced.

New dependencies appear.

People leave.

Recovery procedures become stale.

A successful test performed two years ago may no longer provide strong assurance about today’s environment.

CyConex can help identify evidence that requires reassessment as organisational circumstances and source artefacts change.

This shifts resilience assurance away from periodic exercises in document collection and towards a continually maintained understanding of what is supported by current evidence.

The NCSC’s Most Important Lesson May Be the Simplest

The NCSC’s new recovery guidance acknowledges that full recovery from serious cyber incidents can take months and that organisations may have to operate with severely reduced IT capability for weeks. It also notes that existing continuity plans can prove only partially effective because assumptions, systems and dependencies have changed.

The answer is not simply a larger recovery plan.

It is better knowledge of the organisation.

What must continue?

What can temporarily stop?

What would cause unacceptable harm?

What does each critical function depend upon?

Which controls protect those dependencies?

What evidence demonstrates that recovery will work?

Where are we relying on assumptions?

Those questions bring cyber resilience, business continuity, risk management and assurance together.

And that is where CyConex provides its greatest value.

CyConex does not simply tell organisations whether they have a recovery policy.

It helps them determine whether the available evidence supports the resilience they believe they have, identify where confidence is unjustified and provide a traceable rationale for the resulting assurance position.

Because when a serious cyber attack stops the business, there will be little value in discovering that the recovery plan looked convincing on paper.

The organisation needs to know what must come back first.

It needs to understand everything that outcome depends upon.

And, before the attack happens, it needs to be able to prove that it can recover it.