Cyber Recovery Readiness Check

Question 1

Have you identified not just critical business systems, but also the identity services, admin tooling, network services, cloud platforms, and third-party dependencies required to recover them?

Think beyond the main application or server. Recovery usually depends on supporting services and trust paths as well.

No, we have not mapped this properly We know some of it, but a lot is assumed It is documented, but not strongly validated Yes, we have mapped and tested the key dependencies

Question 2

Could your team define a realistic recovery sequence if multiple interconnected systems were unavailable at the same time?

This is about the order of recovery under pressure, not just a list of systems you care about.

No, we would be working it out during the incident We have rough assumptions, but not a reliable sequence We have a defined sequence, but it is not well tested Yes, we have a realistic recovery order we trust

Question 3

Does your recovery approach cover cloud control planes and SaaS services such as Microsoft 365, Entra ID, SharePoint, Azure, AWS, or Google Workspace, rather than focusing only on servers and endpoints?

Many organisations discover too late that cloud and SaaS platforms are central to recovery, not separate from it.

No, our focus is mostly on servers and endpoints We assume some cloud and SaaS coverage, but it is patchy Cloud and SaaS are included on paper, but not well tested Yes, cloud and SaaS recovery are clearly covered

Question 4

Are backup repositories, management consoles, orchestration tools, and deletion paths protected from the same privileged access routes that could be used to compromise production systems?

If the same admin routes can reach both production and recovery tooling, recovery may fail when you need it most.

No, they are exposed through the same admin paths We have some separation, but not enough confidence Protections exist, but we have not validated them properly Yes, they are meaningfully separated and protected

Question 5

Do you have a defined way to determine whether a system, image, configuration, or dataset is actually safe to restore, rather than simply available to restore?

Availability alone is not enough if the thing you are restoring may no longer be trustworthy.

No, if it is available we would probably restore it We would make judgment calls, but nothing is clearly defined We have criteria, but they are not well exercised Yes, we have clear trust checks before restore

Question 6

Are there defined technical and business validation points for deciding when a recovered service is safe to reconnect to users, integrations, and production data flows?

Reconnection decisions matter just as much as restore decisions if you want to avoid reintroducing risk.

No, reconnection would likely happen ad hoc We have some rough checks, but not a clear decision point We have defined checks, but they are not well proven Yes, reconnection is controlled through clear validation points

Question 7

If core identity services or privileged accounts were compromised, do you have a controlled and tested method to re-establish trusted administrative access?

Recovery often depends on rebuilding trust in admin access before anything else can move.

No, that would be a major blocker for us We have ideas, but no reliable recovery path We have a defined approach, but it is not well tested Yes, we have a controlled way to re-establish trust

Question 8

Can you rebuild key services from known-good baselines, configurations, and secrets, or does recovery depend heavily on the existing environment still being trustworthy?

Strong recovery usually depends on known-good foundations, not just the hope that the current environment is still safe.

Recovery depends heavily on the existing environment still being trusted We have some clean foundations, but not enough confidence in them We have known-good rebuild paths, but they are not well tested Yes, we can rebuild from known-good foundations

Question 9

Could recovery still be coordinated if email, collaboration platforms, ticketing systems, VPN, or remote management tools were unavailable or untrusted?

Many plans assume the usual coordination tools still work. This question tests whether recovery could continue if they do not.

No, we rely heavily on those tools to coordinate We have fallback ideas, but nothing dependable We have alternative coordination methods, but they are not well tested Yes, we could coordinate recovery without our usual tools

Question 10

Have you assessed how the organisation would continue making critical decisions and operating essential processes while digital services are only partially restored?

Recovery is not just technical. It also depends on how the organisation functions while systems are degraded.

No, that has not really been thought through We have some assumptions, but no clear plan We have a defined approach, but it is not well rehearsed Yes, we have considered how the organisation would operate while recovering

Question 11

When recovery is tested, does it include cyber-specific conditions such as identity compromise, uncertain system trust, damaged management tooling, or multi-system disruption?

Traditional disaster recovery tests often miss the things that make cyber recovery harder.

No, our tests do not really cover cyber-specific conditions We touch on some of this, but only lightly Cyber-specific conditions are included, but not deeply enough Yes, our testing reflects realistic cyber recovery conditions

Question 12

Is your confidence in recovery based on recent technical validation under realistic attack conditions, rather than mainly on documentation, assumptions, or vendor assurances?

Confidence is strongest when it comes from evidence under pressure, not from paperwork alone.

No, our confidence is mostly based on documentation or assumptions We have some evidence, but confidence is still largely assumed We have useful validation, but not enough under realistic conditions Yes, our confidence is based on recent realistic validation

Can you recover safely after a cyber attack?