Creating a Business Continuity Plan: Guide for IT Leaders

The BCM Framework #

A complete Business Continuity Management (BCM) program, as structured for example by ISO 22301, has four building blocks:

1. Business Impact Analysis (BIA)

• Identify critical processes
• Define RTO (Recovery Time Objective)
• Define RPO (Recovery Point Objective)
• Map dependencies

2. Business Continuity Plan (BCP)

• Strategy per process
• Alternative work locations
• Communications plan
• Roles and responsibilities

3. Disaster Recovery Plan (DR Plan)

• Technical restoration steps
• Recovery runbooks
• Test procedures

4. BCM Governance and Testing

• Annual BIA updates
• Regular DR tests
• Lessons learned

The BCP builds on the BIA. Without a BIA, the BCP is pure speculation.

Step 1: Business Impact Analysis (BIA) #

The BIA is the foundation. It identifies:

• Which business processes are critical?
• How long can they be down without unacceptable impact? (RTO)
• How much data loss is acceptable? (RPO)
• Which systems support these processes?

BIA workshop methodology:

Invite a group: executive management, department heads, finance director, IT leader.

Walk through each business process:

1. Sales: ​“Our sales team can work at most 4 hours without the CRM before deals are lost.”
2. Accounting: ​“Our accounting processes can be down at most 1 week before we have difficulties with stakeholders.”
3. Production: ​“Our manufacturing can be down 2 hours; after that we lose customers.”
4. Email: ​“Email can be down 24 hours; business is impaired but not fatally.”

The result is an RTO/RPO overview per process, for example:

• Sales (CRM, email): RTO 4 hours, RPO 1 hour, critical
• Production (ERP, PLC control): RTO 2 hours, RPO 15 minutes, critical
• Accounting (ERP, file server): RTO 24 hours, RPO 1 day, important
• HR (HRIS, email): RTO 48 hours, RPO 1 day, important
• Development (Git, Jira, email): RTO 7 days, RPO 1 day, low

This is the BIA. Without it, you cannot write a meaningful BCP.

Step 2: Business Continuity Plan (BCP), 8 Sections #

1. Executive Summary #

• Purpose of the plan
• Scope (which business units, which processes)
• Critical processes (short list)
• Authorization and approvals

2. Organization and Roles #

• Incident Commander: leads the BC response.
• BC Team Lead: one per business unit.
• Recovery Manager: coordinates restoration.
• Communications Manager: internal and external communications.
• Finance: budget for recovery.

For each role: name, backup person, contact numbers.

3. Critical Business Functions and Recovery Strategies #

For each critical process:

“Sales Process, RTO 4 Hours”

• Scenario 1 (minor failure): ​“If CRM is down for 4 hours…”
  • Strategy: manual sales process, email-based, interim logging in local spreadsheets
  • Recovery: recovery runbook for CRM, estimated 2 hours
• Scenario 2 (major failure, building inaccessible): ​“If the office is not reachable…”
  • Strategy: remote work from home, VPN access, laptops with local sales tools
  • Recovery: return to normal office, new schedule (2 to 3 days)

“Production, RTO 2 Hours”

• Scenario 1 (software failure): ​“If the ERP system is down…”
  • Strategy: manual production, emergency schedule, pause on new orders
  • Recovery: ERP from backup, estimated 1.5 hours
• Scenario 2 (hardware failure): ​“If the production server is damaged…”
  • Strategy: failover to a backup server, manual process in parallel
  • Recovery: new server plus ERP plus database, approx. 2 hours

4. Alternative Work Locations #

Where does your team work if the office is unavailable?

• Home office: for sales, admin, development; works well
• Customer site: for on-site technicians; acceptable, but limited
• Co-working space: rentable for 50 people, cost per day
• Public-sector fallback location: for critical public organizations

For each location: capacity, internet quality, availability, costs.

5. Communications Plan #

Internal:

• How is the team notified that a BC event is running? (alarm, telephone, email)
• How often are updates provided? (hourly for critical, daily for others)
• Who communicates? (one spokesperson, not ten)

External:

• How are customers notified? (template, prepared)
• When are customers notified? (immediately when service is impacted)
• Who signs off? (CEO or COO, not IT)
• Regulatory notifications: for entities in scope of NIS2, an early warning to the national CSIRT or competent authority is due within 24 hours of becoming aware of a significant incident, the incident notification within 72 hours, and a final report within one month. Build these deadlines into the plan, with named owners.

Sample statements:

• “We have a technical issue with our sales system. We are working on it. Service will be restored in 2 to 4 hours.”
• “Due to a cyberattack we are shutting down our systems to minimize damage. We will provide updates every 4 hours.”

6. Resource Requirements #

What do you need for recovery?

• Hardware: backup servers, failover hardware, an isolated recovery zone, and an air-gapped secondary storage tier for the backup copies an attacker cannot reach
• Software: backup tools, recovery software, restoration utilities
• People: how many technicians are available around the clock?
• External services: forensics, incident response retainers, repair services
• Budgets: recovery can be expensive. Pre-approve emergency spending authority.

7. Testing and Maintenance #

• Tabletop exercise: twice per year, simulate a BC event, all roles walk through it. Non-technical.
• Partial DR test: quarterly, one system actually recovered (with backup data, not production).
• Full DR test: annual, all systems in the recovery environment.

This is not optional. A BCP that has never been tested is fiction, and for financial entities, DORA (Regulation (EU) ²⁰²²⁄₂₅₅₄) makes resilience testing a legal requirement.

8. Maintenance and Update #

• Annual review: the BCP must be updated based on test findings.
• Change triggers: after major IT changes (new systems, new sites, new partnerships).
• Role updates: when a key person leaves, a backup is trained.

Business Continuity as an EU Legal Requirement #

Business continuity is no longer optional for large parts of the European economy:

NIS2 (Directive (EU) ²⁰²²⁄₂₅₅₅): Requires essential and important entities to implement business continuity measures, explicitly including backup management, disaster recovery, and crisis management. Management bodies must approve and oversee these measures and can be held personally accountable. In Germany, the directive is implemented through the NIS2UmsuCG, in force since 6 December 2025.

DORA (Regulation (EU) ²⁰²²⁄₂₅₅₄): Requires financial entities to maintain an ICT business continuity policy and to test response and recovery plans. Applicable since 17 January 2025.

GDPR Art. 32: Requires the ability to restore the availability of and access to personal data in a timely manner after an incident. A working BCP with tested recovery is how you demonstrate this.

ISO 22301: The certifiable international standard for BCM, and the common structure auditors expect.

In practice this means: conduct and document the BIA, define and test RTOs (not just estimate them), implement recovery measures including an isolated backup tier, and build a crisis management structure with documented roles.

Frequently Asked Questions #

Difference between BCP and DR Plan? BCP: business-oriented (which processes are critical, how long can they be down). DR Plan: technical (how do we bring systems back up).

Who writes the BCP? The business side (executive management, department heads) for the BIA and strategy. IT writes the DR Plan and the technical details.

How long does a complete BCP build take? For a mid-sized organization: 3 to 6 months (BIA workshop, writing the plan, first test, then iteration).

---

Further Resources #

→ IT Resilience Guide (/en/blog/it-resilienz-leitfaden/) → Defining RTO and RPO Correctly (/en/blog/rto-rpo-definieren/) → Disaster Recovery Test (/en/blog/disaster-recovery-test/)