Business Resilience Insight

How Do You Build a Business Continuity and Disaster Recovery Plan?

Learn how to build a practical business continuity and disaster recovery plan, including BIA, risks, RTO, RPO, recovery strategies, testing and maintenance.

By Fedelta Consulting Updated July 2026 Estimated reading time: 14 minutes

What should a BCDR plan achieve?

A business continuity and disaster recovery plan should keep critical operations running, define recovery priorities, assign responsibilities and provide tested procedures for restoring systems, data and services after disruption.

What Is a Business Continuity and Disaster Recovery Plan?

A business continuity and disaster recovery plan explains how an organisation will continue critical operations during disruption and restore technology, data and services to an acceptable level.

Business continuity covers people, premises, suppliers, communications and operational workarounds. Disaster recovery is the technology-focused part of the plan, covering systems, infrastructure, applications, data and restoration.

Protect critical workIdentify the activities that must continue first.

Set recovery targetsDefine acceptable downtime and data loss.

Assign responsibilityGive each recovery decision and action a clear owner.

Test the planProve that procedures work before a real disruption.

Why Every Business Needs a BCDR Plan

Disruption can result from cyber incidents, hardware failure, cloud outages, natural hazards, utility loss, supplier failure, human error or the sudden unavailability of key staff. A written and tested plan reduces uncertainty when normal processes are unavailable.

The purpose is not to predict every possible event. It is to create a repeatable decision framework, protect the most important services and make recovery priorities clear before pressure is high.

Step 1: Complete a Business Impact Analysis

A business impact analysis identifies critical activities and measures the consequences if they stop. It should consider financial loss, customer impact, safety, legal obligations, contractual penalties, reputation and operational dependencies.

Business activity	Maximum tolerable disruption	Dependencies	Workaround
Customer support	Four hours	Phones, ticketing, staff, internet	Emergency phone and shared register
Payroll	Two business days	Payroll system, banking, employee data	Manual priority payment process
Order processing	Eight hours	CRM, inventory, email, suppliers	Offline order capture form

Step 2: Assess Risks and Single Points of Failure

Review threats, vulnerabilities and dependencies that could interrupt each critical activity. Include technology, people, premises, suppliers, telecommunications and access to information.

Unsupported or unpatched systems.
Single internet links, power sources or hosting locations.
One person holding essential knowledge or credentials.
Backups stored in the same failure domain as production data.
Critical suppliers without tested continuity arrangements.
Recovery procedures that rely on unavailable systems.

Step 3: Define RTO, RPO and Recovery Priorities

Recovery objectives convert business requirements into measurable technology targets. They should be realistic, funded and agreed by business owners.

Term	Meaning	Example
RTO	Target time to restore a service after disruption.	Email restored within four hours.
RPO	Maximum acceptable data loss measured in time.	No more than one hour of transaction data lost.
Maximum tolerable downtime	Longest disruption the business can accept before consequences become unacceptable.	Order processing cannot be unavailable for more than one day.

Faster recovery costs more

Very short RTOs and RPOs normally require replication, automation, redundant infrastructure and specialised support. Targets should reflect genuine business impact rather than an ideal outcome with no budget.

Step 4: Choose Continuity and Recovery Strategies

People and workplace strategies

Remote-work arrangements and alternate work locations.
Cross-training for critical roles.
Emergency contact and escalation processes.
Manual workarounds for essential activities.

Technology strategies

Independent, protected and monitored backups.
Cloud or secondary-site recovery capability.
Redundant connectivity and power where justified.
Documented rebuild and restoration procedures.
Alternative communication channels.

Supplier strategies

Alternative suppliers for critical goods and services.
Contractual continuity and notification requirements.
Current vendor escalation contacts.
Understanding of supplier recovery commitments and limitations.

Step 5: Write the BCDR Plan

The plan should be usable during an incident, not written only for audit. Keep instructions concise, assign owners and store accessible copies outside systems that may be unavailable.

Activation criteria and decision authority.
Incident leadership and recovery roles.
Contact details and escalation paths.
Critical activity and system priorities.
Technical recovery procedures and credentials process.
Internal, customer, supplier and regulatory communications.
Manual workarounds and alternate locations.
Return-to-normal and post-incident review procedures.

Step 6: Test the Plan

A plan is only credible when tested. Use several test types because a discussion exercise cannot prove that data restores successfully, and a technical restore does not prove that leaders can coordinate decisions.

Test type	Purpose	Example
Document review	Check accuracy and ownership.	Verify contacts, suppliers and system inventory.
Tabletop exercise	Practise decisions and coordination.	Work through a ransomware scenario.
Technical recovery test	Validate restoration procedures.	Restore a server or dataset in an isolated environment.
Operational exercise	Test end-to-end continuity.	Operate a critical process using the documented workaround.

Step 7: Maintain and Improve the Plan

Update the plan after tests, incidents, technology changes, office moves, supplier changes and major staffing changes. Review critical contacts and dependencies on a scheduled basis.

Track actions from every test and assign due dates. An unresolved testing issue is a known recovery risk and should be managed like any other business risk.

Common BCDR Planning Mistakes

Focusing only on IT and ignoring people, suppliers and premises.
Assuming that a successful backup automatically means recovery will work.
Setting recovery targets without business approval or funding.
Keeping the only plan copy inside the affected environment.
Using outdated contact details and undocumented credentials.
Testing individual systems but not complete business processes.
Failing to record lessons and close corrective actions.

Useful Official References

Need Help Building a Practical BCDR Plan?

Fedelta helps Australian businesses identify critical services, set recovery priorities, document procedures and test business continuity and disaster recovery arrangements.

Book a consultation

Frequently Asked Questions

What is the difference between business continuity and disaster recovery?

Business continuity keeps critical operations running during disruption, while disaster recovery focuses on restoring technology, systems and data after an incident.

What are RTO and RPO?

Recovery Time Objective is the target time for restoring a service. Recovery Point Objective is the maximum acceptable amount of data loss measured in time.

How often should a BCDR plan be tested?

Testing should occur at least annually and after significant changes, with higher-risk systems and critical recovery procedures tested more frequently.

Does Microsoft 365 backup remove the need for a BCDR plan?

No. Microsoft service resilience and retention features do not replace an organisation-wide continuity plan, independent recovery decisions, tested procedures and coverage of non-Microsoft systems.