Business Continuity
ISO 22301 Business Continuity Management: A Step-by-Step Guide
Business continuity is not a binder on a shelf. How to build an ISO 22301 management system that keeps critical services running — and proves it.
Key takeaways
- Tier applications by RTO and RPO derived from the business impact analysis.
- Match DR technology to tier — not everything needs active-active.
- DRaaS can reduce cost for many workloads but needs careful design.
- Test full failovers; partial tests hide dependency problems.
Start from business requirements
Recovery objectives should come from the business impact analysis, not from what the current platform happens to support. Group applications into tiers so that technology and cost match need.
| Tier | RTO | RPO | Typical approach |
|---|---|---|---|
| 0 | Near-zero | Near-zero | Active-active or synchronous replication |
| 1 | Under 4 hours | Under 15 minutes | Warm standby with asynchronous replication |
| 2 | Under 24 hours | Under 4 hours | Pilot light or DRaaS |
| 3 | Days | 24 hours | Restore from backup |
DR options
- Secondary data centre — full control, high cost.
- Colocation — shared facility, your equipment.
- Cloud DR — replicate to a public cloud region and start resources on demand.
- DRaaS — a provider manages replication, orchestration and failover testing.
When DRaaS makes sense
DRaaS works well for virtualised workloads with moderate RTOs, organizations without a second site, and teams lacking DR expertise. Check where replicas are stored, how failover is orchestrated, network re-addressing, licensing in the DR environment and how often the provider tests with you. Confirm that DR locations meet data residency and contractual requirements.
Don't forget the foundations
Identity services, DNS, certificates, network connectivity and privileged access tools must be recoverable first. Many DR tests fail because these shared services were assumed to be available.
Ransomware changes DR
Replication copies encryption as quickly as it copies data. Combine DR with immutable backups, isolated recovery environments and clean-room procedures to restore from a known-good point.
Testing that proves it works
Run at least one full failover test per year for critical tiers, measure actual recovery times, and update runbooks. Report results honestly to leadership, including gaps.
The DR runbook
A good runbook lists the decision criteria for invoking DR, the order of recovery, named people and alternates, technical steps with expected durations, validation checks and failback procedures. Store it where it is accessible when primary systems are down.
How NAZZTEC helps
We design DR architectures across on-premises and cloud, implement DRaaS and immutable backup, write runbooks and run failover tests with measured results.
Next step: explore Business Resilience Solutions and Data Center Services.
Frequently asked questions
What is the difference between backup and DR?
Backup preserves copies of data. DR restores complete services — infrastructure, applications and data — within defined objectives.
Is cloud always cheaper for DR?
Often, because you pay mainly for storage until failover. Costs during extended failover and egress must be modelled.
How often should DR be tested?
Critical systems at least annually with full failover, and component tests more frequently.
NAZZTEC Editorial TeamWritten and reviewed by NAZZTEC practitioners. This briefing is general guidance, not legal advice.
