Services / Resilience
Business Continuity, DR & BIA
BCP, disaster recovery and BIA plans, with recovery targets you have tested and measured.
The problem
The continuity plan promises a four-hour recovery time. Nobody has ever tried to restore the production database, and the person who set it up has left. A customer contract now carries an availability commitment, and someone will have to sign against it.
The method.
Business Impact Analysis by process, not by server
For each critical business process (serve the product, take payment, support customers, pay staff), establish the maximum tolerable outage, the financial and contractual impact per hour, and the dependencies: systems, suppliers, key people, data. This drives RTO and RPO from the business rather than from what the infrastructure happens to be capable of.
Set RTO and RPO, then test whether they are achievable
A four-hour RTO with an eight-hour restore time is not a target, it is a fiction. We measure the actual restore path (including image build, data restore, DNS and certificate propagation, and dependency startup order) and either meet the target or change the architecture, and say which.
Write recovery procedures someone else can execute
Runbooks written for the on-call engineer at 3am, not for the architect who built the system: exact commands, exact console paths, credential locations and break-glass access, dependency startup order, and the point at which you stop trying and fail over. Assume the person who built it is unavailable, because in a real event they often are.
Test the restore, for real
Restore the production database into an isolated environment and verify the data: row counts, most recent transaction, application boot. Record the wall-clock time. This one exercise finds more genuine problems than the rest of the programme combined, and it produces the single artifact auditors and insurers most want to see.
Cover the non-technical failure modes
Loss of a critical supplier, loss of office access, loss of key personnel, and, for Israeli companies specifically, extended reservist call-up and regional disruption. These are planned for with named deputies, documented alternatives, and remote-work continuity, because they are the events that actually occur.
Review on a cycle and after every real event
Annual review, plus an after-action update following any genuine outage. A continuity plan that is not updated after a real incident is a plan that has already been proven wrong once.
What is the difference between RTO and RPO?
RTO (Recovery Time Objective) is how long a process may remain unavailable before the impact becomes unacceptable, a target for how fast you must recover. RPO (Recovery Point Objective) is how much data you can afford to lose, measured backwards from the moment of failure, a target for backup frequency. RTO drives your recovery architecture; RPO drives your backup schedule.
What is a Business Impact Analysis?
A Business Impact Analysis identifies the organisation's critical business processes and quantifies what an outage of each one costs per hour (financially, contractually and reputationally), together with the systems, suppliers, data and people each process depends on. It is the input that determines recovery priorities and targets; without it, RTO and RPO are guesses.
How often should disaster recovery be tested?
At least annually, and after any significant architectural change. The test must be a real restore into an isolated environment, with the wall-clock time measured and the restored data verified, not a tabletop discussion of what would happen. Untested backups are the most common cause of a failed ransomware recovery.