Continuity, backup and technical recovery
Business Continuity
This domain tests continuity planning: how an organisation keeps critical services running during disruption and how it recovers afterwards. Distinguish the continuity plan from the disaster recovery plan and know the time-based metrics precisely.
BIA and the time metrics
A Business Impact Analysis identifies critical processes, their dependencies (people, systems, suppliers, facilities) and the impact of downtime as time passes. From it come:
- RTO - target time to restore a service after disruption.
- RPO - maximum acceptable data loss expressed as time, which drives backup and replication frequency.
- MTD/MAO - maximum tolerable downtime before unacceptable harm; RTO must be shorter than MTD.
- WRT - work recovery time, the part of MTD reserved for verification and catch-up.
BCP and DRP
The BCP is business-owned and covers people, premises, suppliers and communications as well as IT. The DRP is the technical recovery plan for systems and data: alternate sites (hot, warm, cold), failover sequence, dependency order and recovery runbooks. Crisis management covers command structure, escalation and communication with regulators and customers.
Testing and standards
Plans decay silently if they are never tested. Test types, from low to high impact: document review, tabletop exercise, simulation, component test, full failover. Each test produces findings and corrective actions. ISO 22301 expects exercising at planned intervals and management review of results.
Worked example
An online payment service has an MTD of 6 hours and can tolerate 15 minutes of lost transactions. If the exercise separately reserves two hours for work recovery, the technical restoration target is at most four hours, and RPO ≤ 15 minutes. Nightly tape backup cannot meet the RPO; continuous asynchronous replication to a warm standby site can, supported by a documented failover runbook and a semi-annual failover test.
Traps
- Swapping RTO and RPO.
- Assuming a hot site removes the need for runbooks and trained staff.
- Writing a plan only IT knows about, with no business sign-off.
- Treating a tabletop exercise as proof that technical failover works.
Backup and Disaster Recovery
This domain narrows to data protection and technical recovery: backup design, restore confidence and disaster recovery arrangements for infrastructure.
Backup fundamentals
- Full - everything copied; slow, simplest restore.
- Incremental - changes since the last backup of any type; small and fast, but restore needs the full chain.
- Differential - changes since the last full; restore needs the full plus the latest differential.
- Snapshots preserve a point-in-time state, but their independence depends on where and how they are stored. A same-array snapshot alone does not protect against loss of that array; exported or independently retained snapshots can form part of a backup design.
The 3-2-1 rule: three copies, on two media types, one offsite. Modern practice extends it to 3-2-1-1-0: one copy offline or immutable, and zero errors verified by restore testing. Encrypt backups, protect backup credentials, and use immutability or air gaps against ransomware, which targets backup infrastructure early.
DR arrangements
Replication may be synchronous (acknowledged writes under a stated model, with latency and failure constraints) or asynchronous (a lag-dependent recovery point, constrained by capacity, latency and operating design). DR tiers run from backup-and-restore through pilot light and warm standby to active-active. Every failover needs a documented and tested failback. DR testing ranges from restoring a sample to a full site switchover.
Worked example
A database needs RPO 15 minutes and RTO 2 hours. Nightly full backups plus hourly log shipping alone do not meet a 15 minute RPO; recovery points must meet the stated 15 minute target through a suitable verified method. automated provisioning can support recovery, but the complete restoration procedure must be tested within the RTO. Prove it by restoring a random table from last month and by performing a full failover twice a year - the restore test is what shows the backup is usable.
Traps
- Treating RAID or replication as a backup; both faithfully replicate corruption and deletion.
- Never testing restores, leaving the backup an untested hypothesis.
- Keeping the only copy online and domain-joined, where ransomware can encrypt it.
- Forgetting configuration files and encryption keys, so restored data cannot be opened.