Phase 1
Business impact analysis (BIA)
We identify critical processes, dependencies and maximum tolerable periods of disruption, and set the recovery objectives (RTO and RPO) agreed with the business.
Information security
Business continuity and disaster recovery
Responding coherently and effectively to unforeseen events that disrupt normal operations is not something you improvise: it is designed, documented and —above all— tested.
- Typical duration
- 3 to 6 months
- Deliverables
- BIA · BCP · DRP · test report
- Framework
- ISO/IEC 27001 A.5.29–A.5.30 · ISO 22301
- Includes
- Documented testing of the plans
Objective and scope
We establish the redundancy needed in equipment and resources, develop the business impact analysis for serious incidents that take services down, and produce the business continuity plan (BCP) and the disaster recovery plan (DRP). The work closes with real tests of both plans: an untested plan is a hypothesis, not a control.
Project phases
Phase 2
Continuity strategies
We evaluate options for redundancy, backup, alternate sites and third-party agreements, weighing the cost of each strategy against the impact it avoids.
Phase 3
Plan design
We document the BCP and the DRP: roles and responsibilities, activation criteria, recovery procedures, call tree and crisis protocols.
Phase 4
Testing and improvement
We run tests —tabletop, restore or failover— document the results and adjust the plans with the lessons learned.
What the implementation includes
- Inventory of critical processes
- Business impact analysis (BIA)
- RTO and RPO defined per process
- Continuity and redundancy strategies
- Business continuity plan (BCP)
- Disaster recovery plan (DRP)
- Call tree and crisis management
- Documented restore testing
Frequently asked questions
What is the difference between a BCP and a DRP?
The BCP answers how the business keeps operating during the disruption, including manual workarounds. The DRP is narrower: how infrastructure and systems are recovered. The DRP is a part of the BCP, not a synonym for it.
Are backups enough?
No. A backup whose restore has never been tested is not a continuity control. The restore test —with times measured against the committed RTO— is what turns a backup into a real capability.
Can this be done without implementing a full ISMS?
Yes. It is a standalone project, although it fits naturally as part of the ISMS if ISO/IEC 27001 implementation is taken on later.