Cyber resilience is more than disaster recovery
Cyber disruption creates continuity problems that ordinary infrastructure recovery plans may not solve. A ransomware event can make the fastest backup unsafe to restore, identity services may be unavailable, trusted administrator devices may be compromised and business data may require integrity validation before operations resume. BCM therefore needs explicit links to cyber incident response and ICT readiness.
Translate business tolerance into ICT requirements
Start with critical products and services, then trace the applications, data, identity, network, cloud, endpoint, integration and supplier dependencies required to deliver them. RTO and RPO should be accompanied by minimum capacity, data-integrity criteria, security prerequisites and business acceptance criteria. A technical restore that cannot safely support the business process is not recovery.
| Continuity question | Cyber/ICT evidence | Acceptance test |
|---|---|---|
| How fast? | service recovery target and dependency sequence | service usable within agreed elapsed time |
| How much data? | backup frequency, replication and restore points | loss is within approved RPO |
| Is it trustworthy? | malware scan, integrity checks, credential reset | security authority approves restored environment |
| Is capacity enough? | minimum compute, network, licenses and support | critical workload performs at minimum level |
| Can business resume? | process validation and reconciliation | business owner signs operational acceptance |
Design clean-recovery decisions
Document who can declare a recovery environment trustworthy, which credentials must be rotated, how immutable or offline backups are selected, and what happens if the most recent restore point is suspect. Include evidence preservation requirements so continuity actions do not unintentionally destroy forensic material. Pre-agree trade-offs between speed, integrity and investigation with security, technology, legal and business owners.
Scenario: ransomware with identity compromise
A critical service has a four-hour business RTO, but the cyber team finds that privileged identities were compromised two days earlier. Restoring yesterday’s system image would satisfy the nominal RTO but could reintroduce attacker persistence. The organization activates a clean environment, restores an older verified dataset, reconciles priority transactions manually and communicates a controlled service level to customers. The event demonstrates why recovery objectives need security and business acceptance conditions.
Exercise the seams
- loss of identity and privileged-access services
- cloud or SaaS provider outage with limited tenant control
- backup corruption or suspected compromise
- network segmentation during containment
- manual processing with later transaction reconciliation
- third-party API failure during recovery
- business acceptance after technical restoration
Recovery architecture and evidence
For each critical ICT service, document recovery pattern, backup location, restoration authority, infrastructure prerequisites, key-management dependency, identity dependency, network path, external integrations, monitoring and business validation. Evidence should show the arrangement works at the required scale. A screenshot of a backup job proves that a job ran; it does not prove that data can be restored, reconciled and used by the business within its tolerance.
Exercise destructive scenarios that invalidate normal assumptions. Examples include unavailable cloud control plane, compromised administrator credentials, corrupted configuration repositories, loss of DNS, inaccessible secrets vault, damaged integration certificates and simultaneous supplier outage. Measure elapsed recovery time by dependency stage so bottlenecks are visible.
Connect incident command to recovery command
Cyber containment and continuity recovery can conflict. Security may want systems isolated while business leaders need service restored. Predefine decision rights for containment exceptions, clean-room recovery, customer communication and acceptance of older data. Maintain a common incident timeline and explicit handoff criteria. When emergency changes are made, capture them for later reconciliation so the recovered environment does not become an undocumented production baseline.
Practitioner FAQ
How does ISO/IEC 27031 relate to BCM?
ISO/IEC 27031 provides guidance for ICT readiness for business continuity. It helps connect technology readiness and recovery to broader continuity objectives.
What is the practical meaning of ICT readiness?
The organization should be able to demonstrate that required ICT services, dependencies, people and recovery arrangements can support agreed business continuity needs.
Should cyber exercises include business teams?
Yes when business decisions, customer impact, manual workarounds, recovery prioritization or acceptance are in scope. Purely technical exercises cannot validate the full continuity outcome.
Plan for containment versus recovery tension
Cyber response may intentionally keep systems offline while evidence is preserved or compromised identities are investigated. Business continuity planning should identify how priority services operate during that delay and who can approve temporary workarounds. The recovery objective remains important, but it cannot override security conditions required for safe restoration.
Define clean recovery criteria
Before reconnecting restored systems, agree what “clean” means: trusted backups, patched vulnerabilities, credential resets, malware scanning, configuration validation, logging enabled and business data reconciled. These criteria should be designed jointly by security, infrastructure, application and business owners.
Protect the recovery environment
Alternate infrastructure can fail if it shares the same administrative accounts, network paths or management plane as production. Review segregation, privileged-access controls, immutable or protected backups, alternate communications and the ability to operate when identity services are unavailable.
Measure end-to-end restoration
A technical restore is not complete until users can perform priority transactions and the business accepts data integrity. Record achieved restoration time, recovered data point, exceptions and manual reconciliation effort. Feed these results back into BIA objectives and technology architecture decisions.
Business workaround security
Manual or alternate processes introduced during a cyber event can create new fraud, privacy or integrity risks. Define which controls may be relaxed, who can approve the relaxation, transaction limits, additional review and how temporary records will be reconciled. Continuity should preserve essential service without creating an uncontrolled second incident.
Plan for recovery when systems cannot be trusted
Cyber disruption differs from many availability incidents because restoring service quickly may conflict with containment, evidence preservation and confidence in data integrity. Business continuity, incident response, disaster recovery and security therefore need a shared decision model. Define who can authorize restoration, what security conditions must be met, how clean systems and identities will be established, and which business services receive priority when recovery capacity is constrained.
BIA and service mapping should identify not only applications but also identity, privileged access, network, DNS, certificates, security tooling, integrations, data stores and third-party platforms required for recovery. RTO and RPO remain useful, but they should be interpreted alongside the time needed to investigate compromise, validate backups, rebuild trust and reconcile transactions. A technically restored system is not a recovered business service if users cannot authenticate or if data accuracy is uncertain.
Exercise the decisions that are unique to cyber recovery
- When is a backup considered clean enough to restore, and who makes that decision?
- How will privileged access work if the normal identity platform is unavailable or suspected compromised?
- Which services must remain offline until forensic or legal requirements are satisfied?
- How will manual workarounds capture transactions for later reconciliation without creating a second integrity problem?
- What customer, regulator, insurer, law-enforcement or supplier communications require coordinated approval?
Exercises should include imperfect information and competing objectives, not only a clean technical failover. The strongest evidence is an integrated record showing security containment, business priorities, restoration sequencing, data validation and executive risk decisions working as one recovery process.