Business continuity (BCP/DRP)

Business continuity ensures the organization keeps operating (or recovers quickly) in a severe disruption: cyberattack, disaster, provider outage. The BCP covers the whole business; the DRP (disaster recovery plan) focuses on technical/IT recovery.

BCP vs DRP

BCP  Business Continuity Plan: how THE BUSINESS keeps operating (processes, people, sites)
DRP  Disaster Recovery Plan: how SYSTEMS/IT recover (the technical part of the BCP)
# the DRP is a subset of the BCP focused on technology (see def-backup)

BIA (Business Impact Analysis)

- identify the CRITICAL business PROCESSES and the impact if they stop
- define per process: RTO (how long recovery may take) and RPO (how much data to lose)
- MTD/MTPD: maximum tolerable downtime before serious damage
- dependencies: which systems/providers/people sustain each critical process
# the BIA PRIORITIZES what to recover first and with what objectives (aligns with def-backup)

RTO and RPO

RTO   Recovery Time Objective: target time to restore a process/system
RPO   Recovery Point Objective: acceptable data loss (backup frequency)
# they define the strategy: high availability vs recovery from backup (def-backup)

Recovery strategies

- redundancy/high availability (active-active, failover) for very low RTOs
- alternate sites: hot (ready), warm (partial), cold (infra without data)
- resilient, immutable backups (def-backup) as the basis of recovery
- provider agreements (SLA) and a crisis communication plan

Testing the plan (what makes it real)

- tabletop, drills, full failover/restore tests
- "an untested plan is a hypothesis": test real RTO/RPO, not the desired ones
- lessons learned -> update the plan; link with IR (dfir-incidentes)

Blue Team / GRC

Start with the BIA: identify critical processes and set RTO/RPO per process.
Design recovery (HA/sites/immutable backups, Backups & recovery) to match those objectives.
Test the plan (tabletop + drills + real restore); an untested plan doesn’t count.
Integrate with IR (Incident response) and regulatory continuity (DORA resilience, NIS2 & DORA).

Real cases and fines

NotPetya/Maersk (2017): recovery depended on a domain controller that survived by luck; a BCP/DRP case study.
Ransomware that halted entire organizations: the BCP and immutable backups decided downtime.
DORA (NIS2 & DORA) elevates ICT continuity to a regulatory obligation in the financial sector.

Testing checklist

BIA: critical processes, impact, dependencies
RTO/RPO defined per critical process
Recovery strategy to match (HA/sites/immutable backups)
Technical DRP aligned with the BCP (Backups & recovery)
Crisis communication plan and roles
Tests: tabletop, drills, and a real restore
Lessons learned → update; link with IR