Disaster Recovery & Business Continuity

A business impact analysis works out what each system is actually worth to you when it is down, measured in lost revenue, stalled operations, regulatory exposure and reputational harm. It is the analysis that tells you which systems justify expensive fast recovery and which can wait. Without it, every system looks equally critical, which means none of them get the right level of protection.

Your RTO is how long a system can be down before the impact becomes unacceptable. A payment platform might have an RTO of minutes; an internal reporting tool might tolerate a day. The RTO drives the architecture: hitting a fifteen-minute target needs warm failover, while a next-day target can rely on restoring from backup.

Your RPO is how much data you can afford to lose, measured in time. An RPO of one hour means your backups and replication must be no more than an hour behind, or you accept losing up to an hour of work. RTO and RPO together set the cost of your recovery, because tighter targets always mean more infrastructure.

Setting targets the business will accept

We set these numbers with your leadership, not in a vacuum, because they are business decisions dressed as technical ones. A one-minute RTO sounds appealing until you see the bill for it. The right target is the honest balance between what downtime costs and what protection costs.

The baseline is 3-2-1: three copies of your data, on two different media, with one kept off-site. Against modern ransomware we push further, to copies that are offline or immutable, so that even an attacker with domain administrator rights cannot alter them. An air-gapped or write-once copy is what stands between you and a total loss.

An untested backup is a guess. We restore from your backups on a schedule and time how long it takes, so your RTO is a measured number rather than an assumption. This is also where you find out that a backup silently stopped working three months ago, while there is still time to fix it.

After a cyber attack, restoring blindly can reinfect you from a backup that already contained the attacker’s foothold. We help you identify a recovery point from before the compromise and rebuild to a state you can trust, so you are not encrypting your systems a second time a week later.

We run the business impact analysis, map dependencies between systems, and identify the scenarios most likely to hurt you, from ransomware to hardware failure to a cloud region going dark. This is the evidence the whole plan is built on.

We set RTO and RPO per system and design the backup, replication and failover to meet them. Where a target is expensive, we show you the trade-off so the business can decide with open eyes.

We put the backup strategy, failover arrangements and monitoring in place, and write the runbooks that turn the design into steps a stressed engineer can follow at 4am without improvising.

We prove it works with tabletop exercises and, where it matters, live failover tests. A plan that has never been rehearsed is a document, not a capability.

We keep the plan aligned with your changing estate and re-test on a cadence. New systems, new dependencies and staff turnover all erode a plan that is left alone, so maintenance is where continuity stays real.

Because ransomware seeks out and destroys online backups, a continuity plan that assumes clean, available backups can fail exactly when invoked. Designing for a cyber disaster means offline copies, tested clean-state recovery and a rebuild path for your identity systems, not just spare disk in another building.

A serious intrusion can compromise your directory services, which are the keys to everything else. Real continuity planning includes how you rebuild trusted identity and access, because restoring the file server is meaningless if the attacker still controls the accounts that reach it.

We establish what is actually down, what is at risk, and which business processes are affected, then match that to the recovery priorities set in your business impact analysis. Guessing at scope wastes the very hours your RTO is measured in.

Before restoring anything, we stop the damage from spreading. For a destructive attack that means isolating affected segments and protecting the backups the attacker has not reached yet, so recovery does not simply re-infect a clean environment.

Where the disaster is an intrusion, we remove the attacker’s foothold and any persistence before failover. Restoring onto a compromised platform hands the environment straight back, which is how organisations end up recovering twice.

We bring systems back in the order your business impact analysis dictates, from validated clean restore points or a failover site, and verify each service works before the next one depends on it. This is where tested restores and a written runbook turn a long outage into a short one.

Once you are trading again, we close the gap that caused the disruption and feed the lessons back into the plan. A recovery that changes nothing invites the same failure, so this phase updates runbooks, backup design and monitoring.

Article 32 of the GDPR requires the ability to restore the availability and access to personal data in a timely manner after an incident, and to regularly test that ability. A tested recovery plan is part of meeting that obligation, not a nice-to-have.

For financial entities under DORA, and for the wider set of essential and important entities under NIS2, operational resilience and continuity are explicit expectations, with testing and documentation to match. We build and evidence plans that speak to those requirements so your continuity work supports your compliance rather than duplicating it.

Some incidents that take you offline also expose personal data, and that carries a legal clock your continuity plan should account for. Where a breach is likely to risk people’s rights and freedoms, GDPR Article 33 requires notifying the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, and Article 34 adds a duty to inform affected individuals when the risk to them is high. We write those notification steps into the runbook itself, so the deadline is met by people following the plan rather than recalled in a panic.

A prioritised recovery plan with per-system RTO and RPO targets, plus step-by-step runbooks for your most likely scenarios. The runbooks are written for a tired engineer under pressure, not for an auditor, so they are concrete and ordered.

Documented restore and failover test results, including how long recovery actually took against your targets. That record is what proves to a board, an insurer or a regulator that your plan is real and not aspirational.