In short
Business continuity keeps an organisation's critical activities running during and after a disruption — covering people, premises, suppliers, processes and technology. Disaster recovery is the technology part: restoring IT systems and data to agreed targets after an outage. A business impact analysis links the two by setting how long each activity can be down and the recovery time and data-loss targets IT must meet.
Business continuity in brief
Business continuity asks how the organisation will keep delivering its most important services when something goes wrong — a power cut, a flood, a pandemic, a supplier failure or a cyber-attack. The answer covers people (who does what, and who deputises), premises (where they work), suppliers (what alternatives exist), communication (who is told what, and when) and technology.
Disaster recovery in brief
Disaster recovery is narrower. It covers the backups, infrastructure and documented procedures that restore IT systems and data after a disruption. Its success is measured against two targets for each system: the recovery time objective (how quickly it must be back) and the recovery point objective (how much data loss is tolerable).
The business impact analysis connects them
A business impact analysis (BIA) identifies critical activities and how the impact of their disruption grows over time. From it comes the maximum tolerable downtime (MTD) for each activity — the point beyond which the damage becomes unacceptable.
The MTD then drives technology targets. The systems supporting an activity need a recovery time objective shorter than its MTD, leaving time for the business to resume work once systems are back. The recovery point objective reflects how much data the activity could afford to re-create or lose.
What goes into each plan
A business continuity plan typically includes invocation criteria, roles and deputies, contact and escalation lists, alternative working arrangements, supplier contingencies, communication templates and the steps to resume each critical activity. A disaster recovery plan contains system recovery priorities, backup and restore procedures, infrastructure and access details, the order of recovery, and the checks that confirm a system is working before users return.
Testing both
Plans that have never been exercised tend to fail when needed. Exercises range from tabletop discussions, where a team talks through a scenario, to walkthroughs of procedures, technical restores of individual systems and full failover tests. Each exercise should record the target and actual recovery times and data loss, what went wrong and the actions agreed.
Common gaps
The same weaknesses appear repeatedly:
- Backups that run every night but have never been restored.
- Plans written once and not updated after systems, staff or suppliers change.
- Recovery depending on one person who knows the procedure.
- No alternative for a critical supplier or connectivity provider.
- Recovery targets set by IT without agreement from the business.
How Ontech ICTM supports this
Ontech ICTM covers both disciplines in one module:
- Business impact analyses recording maximum tolerable downtime and RTO and RPO targets.
- Continuity and recovery plans with versions, approval and review dates, and recovery steps; AI can draft a plan for review using a locally hosted language model.
- Scheduled backups that actually run — database dumps (PostgreSQL, MySQL, MongoDB), file archives and rsync, locally or over SSH — with expiry clean-up.
- A scheduled backup-compliance check that scores each system against its expected backup frequency and raises alerts.
- Disaster recovery exercise records capturing target and actual RTO and RPO, findings and a score.
- Records of escalation chains and key personnel for continuity planning.
Business continuity and disaster recovery compared
| Business continuity | Disaster recovery | |
|---|---|---|
| Scope | The whole organisation: people, premises, suppliers, processes and technology | IT systems, infrastructure and data |
| Core question | How do we keep critical activities running? | How do we restore systems and data? |
| Key inputs | Business impact analysis, maximum tolerable downtime | RTO and RPO for each system |
| Main outputs | Continuity plans, roles, communication and workarounds | Backups, recovery procedures, recovery order |
| Usual owner | Business leadership, often with a continuity manager | ICT, with system and application owners |
| Testing | Tabletop and walkthrough exercises | Technical restores and failover tests |
Key takeaways
- Business continuity covers the whole organisation; disaster recovery covers technology.
- A business impact analysis sets maximum tolerable downtime, which drives RTO and RPO.
- Each system's RTO must be shorter than the MTD of the activities it supports.
- Both plans need regular exercises that compare actual results with targets.
- Untested backups and outdated plans are the most common failures.
Frequently asked questions
Is disaster recovery part of business continuity?
Yes. Disaster recovery is usually treated as the technology component of business continuity. A continuity plan depends on IT systems being restored in time, and disaster recovery planning depends on the business priorities set in the business impact analysis.
What is a business impact analysis?
A business impact analysis identifies an organisation's critical activities, the resources they depend on and how the impact of disruption grows over time. It sets recovery priorities and targets — maximum tolerable downtime for activities, and recovery time and recovery point objectives for the systems that support them.
What is the difference between RTO and MTD?
Maximum tolerable downtime (MTD) is a business measure: how long an activity can be unavailable before the impact becomes unacceptable. The recovery time objective (RTO) is a technology target for restoring a system. The RTO must be shorter than the MTD so the business has time to resume work once systems return.
How often should continuity and recovery plans be tested?
At least once a year for each critical service, and after significant changes to systems, suppliers or staff. Many organisations run tabletop exercises more often and technical restore tests for their most critical systems on a regular schedule.
Do small organisations need both?
Yes, scaled to size. Even a small organisation needs to know which activities matter most, how staff would keep working, and how its data and key systems would be restored. A short, tested plan is more valuable than a long one that has never been used.