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.

Regulatory and compliance framework for disaster recovery

DR is no longer solely an IT governance matter — it is a regulatory obligation for a growing range of Spanish entities:

DORA (Regulation 2022/2554 — Digital Operational Resilience Act): applicable to all EU financial sector entities (banks, insurance companies, investment firms, payment institutions, crypto-asset service providers, and their critical ICT third-party providers) from 17 January 2025. DORA mandates: documented ICT Business Continuity Policy and Disaster Recovery Plans (Articles 11–12); at least annual DR testing including scenario-based exercises; response and recovery capability testing (TLPT — Threat-Led Penetration Testing — for significant financial entities); and notification of major ICT incidents to competent authorities (BdE, CNMV, DGSFP) within defined timeframes (Art. 19-20).

NIS2 (Directive 2022/2555): requires essential entities (energy, water, transport, banking, healthcare, digital infrastructure) and important entities (postal services, waste management, manufacturing, food, chemicals, digital providers) to implement “appropriate and proportionate” security measures including business continuity management and DR (Article 21 NIS2). Spain’s transposition into national law is pending as of 2026 but the Directive has been directly effective since October 2024.

Esquema Nacional de Seguridad (ENS, Royal Decree 311/2022): mandatory for Spanish public administrations and their information system suppliers. The ENS mandates backup and recovery controls at all classification levels, with specific recovery time requirements for high-level systems. Suppliers to the public sector must comply with ENS as a condition of contract award.

ISO 22301:2019 (Business Continuity Management) and ISO 27001:2022: while not legally mandatory, ISO 22301 certification is increasingly required by enterprise clients and public procurement processes. DR capabilities are tested as part of ISO 22301 certification audits. ISO 27001 Annex A control A.8.13 (Information backup) and A.5.30 (ICT readiness for business continuity) require documented backup and recovery capabilities.

GDPR Article 32 (Security of processing): data controllers and processors must implement technical and organisational measures ensuring data availability and resilience, including backup, encryption, and recovery capability. A DR incident resulting in loss of personal data that could not be recovered may constitute a personal data breach requiring AEPD notification under Article 33 GDPR (72-hour notification). DR capabilities are therefore a GDPR compliance obligation as well as an IT governance one.

Sectors with specific DR requirements

Financial services: DORA’s mandatory DR requirements apply to all financial entities from January 2025. The most onerous requirements are for significant financial entities subject to TLPT (threat-led penetration testing, simulating advanced persistent threats on production systems). Our DR advisory for financial clients is fully aligned with the EBA, ESMA, and EIOPA DORA implementation guidelines.

Healthcare: patient care systems — electronic health records, diagnostic equipment interfaces, prescribing systems — have life-safety implications when unavailable. The Junta de Andalucía’s SALUD digital systems and equivalent regional health systems require specific recovery capabilities. Ransomware attacks on Spanish hospitals (several high-profile incidents in 2023-2024) have made healthcare DR a board-level priority.

Logistics and e-commerce: warehouse management systems (WMS), order management platforms, and last-mile delivery routing systems have direct revenue and SLA implications. DR for logistics platforms requires specific attention to API integration recovery — upstream and downstream system dependencies must be documented and tested as part of the DR plan.

Public sector and ENS-regulated entities: government agencies, public universities, and their ICT providers must comply with ENS. Category High systems (containing classified or sensitive public information) require recovery time capabilities tested annually and certified by an accredited auditor.

SMEs dependent on cloud SaaS: the majority of Spanish SMEs now operate critical business systems exclusively on SaaS platforms (Holded, Salesforce, SAP Business One, Sage, etc.). While SaaS providers maintain their own DR capabilities, the company remains responsible for: data export and backup of SaaS data (in case of provider failure or account termination), authentication continuity (what happens if the IdP is unavailable?), and integration recovery (if multiple SaaS systems are integrated, the recovery sequence matters). Our SME DR service addresses these SaaS-specific vulnerabilities.

Company size segmentation

Microenterprises and autónomos (under 10 employees): focused on the two most critical DR risks — ransomware (encrypted local data) and hardware failure (primary workstation). Solution: automated off-site backup (cloud provider with geographic redundancy, e.g., Backblaze, Wasabi, AWS S3 Glacier), 3-2-1 backup rule implementation (3 copies, 2 media types, 1 off-site), monthly restoration test. Fixed-fee DR advisory package from EUR 1,200 + IVA for initial assessment and implementation.

SMEs (10–250 employees): critical system identification and RTO/RPO definition; cloud-based DR solution (AWS/Azure/GCP or Hetzner for GDPR-compliant EU data residency); backup and recovery documentation; annual tabletop exercise and technical recovery test. Monthly DR maintenance retainer from EUR 450/month covering backup monitoring, quarterly recovery tests, and annual DR plan update.

Mid-size companies (EUR 20M–EUR 100M): Business Impact Analysis to define RTOs/RPOs; warm or hot standby architecture for mission-critical systems; full DR documentation; semi-annual failover testing; and NIS2/DORA gap assessment if applicable. Implementation project fees plus ongoing managed service retainer.

Financial entities and NIS2 essential/important entities: full DORA-compliant or NIS2-compliant DR programme including all required documentation, annual TLPT (for DORA significant entities), EBA/ESMA/EIOPA compliance readiness assessment, and supervisory authority notification procedures.

Worked example: DR implementation for a logistics SME post-ransomware

A 45-employee logistics SME with EUR 8.5M revenue suffered a ransomware attack that encrypted its on-premise Windows server (including the WMS, invoicing system, and customer database). The only backup was an external hard drive last updated 3 weeks prior. Recovery took 11 days at a total cost of approximately EUR 85,000 (4 days of partial operations, ransomware decryption service fee, forensic analysis, and system rebuild).

DR programme implemented post-incident:

1. Backup architecture redesign: 3-2-1 backup rule implemented. Veeam Backup with cloud repository (Wasabi EU-Central-1 for GDPR compliance) replacing the external hard drive. Backup schedule: every 4 hours for critical systems (WMS and invoicing), daily for others. Backup encryption enabled.
2. Network segmentation: backups isolated in a separate VLAN with no direct access from production workstations — preventing ransomware from reaching the backup repository (the attack vector in the original incident).
3. RTO/RPO targets defined: WMS: RTO 4h, RPO 4h. Invoicing: RTO 8h, RPO 24h. Email: RTO 24h. All other: RTO 72h.
4. DR site: Azure Virtual Machine configured as warm standby for the WMS — recoverable from backup within 3 hours.
5. Recovery test: 6 weeks post-implementation, full recovery test from cloud backup to Azure DR environment: 2h 48min from backup start to system operational — within the 4-hour RTO target.
6. DR documentation: step-by-step recovery procedures for each system, designated recovery team roles, external vendor contact list (Azure support, Veeam support, cyber insurance broker), and AEPD breach notification procedure.

Annual maintenance: monthly backup verification (automated alerts for failed backup jobs), quarterly partial recovery tests, and annual full DR test. Total ongoing cost: EUR 890/month (cloud storage + DR service retainer). Break-even versus the original incident: within 4 months of ongoing service.

Five common disaster recovery mistakes

1. Assuming the backup means the data is recoverable. A backup that has never been tested has an unknown recovery probability. Backup failures are common — corrupt files, incomplete datasets, misconfigured retention policies, storage space exhaustion. The only way to know backups are functional is to test a restoration regularly. Our DR service includes automated backup job monitoring and monthly restoration tests as standard.

2. Not isolating backups from the production network. Ransomware consistently attacks connected backups first. Backups stored on a network share accessible from production workstations, a NAS without network segmentation, or a cloud sync service (such as OneDrive) that is accessible from infected machines are not protected backups — they are additional attack targets. Air-gapped or network-isolated backup repositories are non-negotiable for ransomware resilience.

3. Defining RTOs without business input. IT teams frequently define RTOs based on technical capability (“we can restore in 8 hours”) without assessing whether that matches what the business can actually tolerate. A logistics company whose delivery routing system is down for 8 hours during peak season loses orders and incurs SLA penalties that may cost more than upgrading to a 2-hour RTO solution. RTOs must be defined by business impact analysis, not technical convenience.

4. Recovery documentation that only the original system administrator can follow. A DR plan whose recovery procedures require undocumented tribal knowledge — log into system X with credentials only known to the head of IT, who is currently unreachable — fails in the incident. DR procedures must be documented at a level that allows any member of the recovery team to execute them under pressure. We require all DR plans to be “stranger-executable” — tested with a person who was not involved in writing the documentation.

5. No ransomware-specific recovery strategy. Standard backup and restore is insufficient for ransomware scenarios. The critical additional elements are: backup retention depth sufficient to recover to a clean state before the initial infection (ransomware may persist for weeks before activating, infecting backups throughout); isolation of the DR environment before connecting to it (to prevent re-infection during recovery); and coordination with the incident response team to determine the safe recovery point. A DR plan that does not specifically address ransomware is incomplete for the current threat landscape.

How we work: DR advisory and managed service

DR capability assessment (2–3 weeks): current backup architecture review, RTO/RPO documentation review, recovery test results (if any), compliance requirements analysis (DORA/NIS2/ENS/GDPR), and gap analysis with prioritised recommendations.

DR programme design (4–6 weeks): RTO/RPO definition (Business Impact Analysis workshop), DR architecture design, cloud provider and tool selection, backup policy design, and DR plan documentation template.

Implementation (4–12 weeks): backup system configuration, DR site setup (cloud or physical), network segmentation for backup isolation, DR documentation completion, and initial recovery test.

Ongoing managed service: monthly backup monitoring and restoration tests; quarterly partial DR tests; annual full failover simulation; DR plan annual update; and incident response coordination (ransomware/data loss scenarios). Monthly retainer from EUR 450 to EUR 2,500 depending on company size and complexity.