60% of DR plans fail their first real test — is yours one of them?

IT disaster recovery (DR) is the technical discipline focused on restoring critical information systems and data after a failure event such as ransomware, hardware failure, or data corruption. A disaster recovery plan defines the Recovery Point Objective (RPO) — the maximum data loss the organisation can tolerate — and the Recovery Time Objective (RTO) — the maximum time a system can be down before causing unacceptable business impact. In Spain, regulations including DORA (for financial entities), NIS2 (for essential and important sector entities), ISO 27001, and the GDPR all require organisations to implement and test formal disaster recovery measures.

Our disaster recovery team combines systems architecture expertise with incident management experience, coordinating the technical recovery dimension with the operational and regulatory requirements of each organisation.

Why disaster recovery plans fail — and the cost of finding out too late

Sixty per cent of DR plans fail on their first real test because they were never validated. Many companies have daily backups on a NAS or in a cloud service but have never verified that those backups are actually restorable, nor measured how long a full restoration would take. When the incident occurs — ransomware, critical hardware failure, database corruption — they discover that the restoration process takes three times longer than expected, that some data is not in the backup, or that the cloud provider has restoration speed limits that no documentation mentioned. Each hour of ERP or CRM downtime has a direct cost in halted operations, unmanaged orders, and customers without support that can exceed EUR 10,000 in mid-sized companies.

IT disaster recovery is the technical component of business continuity: while the BCP defines how the company continues operating through any type of disruption, DR specifically defines how IT systems are restored when they fail. This distinction matters because IT systems are now the operational backbone of most organisations, and their failure has immediate consequences that extend well beyond technology.

Our RPO/RTO and DR architecture process

Our professionals begin with the critical IT systems inventory and RPO and RTO definition for each — a business decision that the management team makes with our technical support. On that basis we design the optimal DR architecture: backup strategy (local, cloud AWS/Azure/GCP, or hybrid), DR site type (hot, warm, or cold depending on the required RTO), retention policy with sufficient historical depth for ransomware scenarios, and step-by-step documented failover procedures by system. We implement the solution, coordinate with cloud providers, and execute recovery tests to validate that the plan works as expected before there is any need to activate it. The DR plan integrates with the ERM corporate framework so that technology risks have visibility at the management and board level.

What our disaster recovery service includes

The service covers the critical IT systems inventory with RPO and RTO definition by system, gap analysis between current recovery capabilities and required objectives, DR architecture design (backup, DR site, replication), complete DR plan documentation with step-by-step procedures, coordination with cloud providers (AWS, Azure, GCP) for implementation, and a recovery testing programme (backup verification, partial and full failover tests). Annual plan maintenance is included.

Real results in disaster recovery planning

In one hundred per cent of first recovery tests conducted with new clients, our team identifies between two and four critical vulnerabilities in existing backup systems that would have compromised recovery in a real incident. After DR plan implementation, average RTO for critical systems falls from days to hours. Companies with correctly configured cloud DR achieve RTOs of 2 to 4 hours for ERP and critical business systems. And the assurance of having a plan that is tested and validated annually is measurable in the ability to respond to an incident with methodology and calm rather than improvisation under pressure.

Frequently asked questions about disaster recovery planning

Coordination with cybersecurity incident response is especially critical in the ransomware context, today the most frequent DR threat. The DR strategy for ransomware requires backup retention policies with sufficient historical depth, isolation of backups from the production network, and coordination between the recovery team and the incident response team to determine when it is safe to begin restoration. This connects directly with the business continuity framework to ensure that degraded-mode operations during recovery are planned, not improvised.

IT disaster recovery: the business case and regulatory context

Disaster recovery (DR) — the capability to restore IT systems, data, and operational infrastructure after a disruptive event — has become a regulatory and contractual requirement for Spanish businesses across multiple sectors. The EU NIS2 Directive (transposed into Spanish law via the Esquema Nacional de Seguridad framework and sector-specific regulations) requires essential and important entities to implement incident response and recovery capabilities. DORA (Digital Operational Resilience Act) imposes detailed IT recovery requirements on financial sector entities from January 2025.

Beyond regulation, the business case for DR investment is compelling: the average cost of IT downtime in European businesses has increased dramatically with the shift to cloud-based operations, and ransomware incidents — the primary cause of unplanned IT outages in Spain in 2024-2025 — consistently result in data loss and operational disruption that exceeds the cost of adequate DR protection by a factor of 10 or more.

Recovery time and recovery point objectives

The foundation of any DR programme is the definition of Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for each IT system and business process:

RTO: the maximum acceptable time for an IT system to be restored after a disruption. RTOs vary by system criticality — a core ERP system may have an RTO of 4 hours while an archiving system may have an RTO of 48 hours.

RPO: the maximum acceptable data loss in time — i.e., how old can the recovered data be? An RPO of 15 minutes requires near-real-time replication; an RPO of 24 hours requires daily backups at minimum.

Defining RTOs and RPOs is not a technical exercise — it is a business decision that must involve management and, where applicable, clients whose service continuity depends on the IT systems in question. Our business continuity team facilitates the Business Impact Analysis process that produces defensible RTO/RPO definitions.

DR architecture options for Spanish businesses

The appropriate DR architecture depends on the criticality of the systems, the RTOs/RPOs required, and the available budget:

Backup and restore: the simplest DR approach — regular backups stored off-site (cloud or physical media) and restored to replacement hardware on demand. Appropriate for non-critical systems with RPOs of 24+ hours and RTOs of several hours to days.

Warm standby: secondary environment maintained in a reduced-capacity but ready state, with data replication at defined intervals. Can achieve RTOs of 1-4 hours and RPOs of minutes to hours. Appropriate for important but not mission-critical systems.

Hot standby / active-active: full secondary environment maintained in a live state with real-time data synchronisation. Can achieve near-zero RTOs and RPOs for mission-critical systems. Highest cost but justified for core banking, ERP, and e-commerce platforms.

Cloud DR: leveraging cloud provider DR services (AWS, Azure, GCP) for Spanish data residency-compliant recovery. Cloud DR can provide very low RTOs/RPOs at a fraction of the cost of equivalent physical infrastructure for most workloads.

DR testing and validation

A DR plan that has not been tested should be treated as untested — not as a functioning recovery capability. Our DR testing programme includes:

• Tabletop exercises: structured walkthroughs of the recovery process without activating systems — identifying gaps in documentation, dependencies, and decision-making authority.
• Technical failover tests: activation of the secondary environment and testing of recovery from backup, without impact on the primary production environment.
• Full failover simulation: complete switch to the secondary environment for a defined period, including application testing, user acceptance, and controlled failback.

Contact our IT resilience team for a DR capability assessment and architecture recommendation.