A disaster recovery plan answers a very concrete question: if tomorrow your servers are encrypted, your cloud provider fails or your office is unavailable, what do you do in the first hour, the first day and the first week to keep serving customers? We help companies in Spain build that answer with data: which processes are critical, how long they can be down, what it takes to recover them and who decides what.
We are an IT services company with 26 years in the field, so the technical side of the plan (backups, systems, communications, access) is not left as a generic recommendation: we design it, implement it and test it. We work on site in Madrid and remotely, with local technicians and partners, for sites elsewhere in Spain and Portugal.
Disaster recovery plan, continuity plan and backups: what each one is
| Document | Question it answers | Scope |
|---|---|---|
| Business continuity plan (BCP) | How do we keep operating during a disruption? | Processes, people, sites, suppliers, communication and technology |
| Disaster recovery plan (DRP) | How do we recover IT systems, and in what order? | Servers, applications, data, network and communications |
| Backup policy | What do we back up, how often and where? | Data and configurations |
Backups are part of the DRP, and the DRP is part of the continuity plan. We build them together, from the objectives the impact analysis sets. If you need a refresher on the concept, see our disaster recovery glossary entry.
What a disaster recovery plan contains
For each critical system, the DRP documents where its backups and replicas are, the order in which it is recovered (identity, network and communications first, then business applications), who does it, how long it takes according to the last test and how to check that the recovered data is correct. It also includes supplier and vendor contacts, emergency credentials kept outside the affected systems and the criteria for returning to normal operations.
How we build the plan
We work in five phases. For an SME with few critical processes, the first usable plan usually takes weeks, not months; multi-site organisations or those with many suppliers are handled area by area.
1. Business impact analysis (BIA)
We interview the people responsible for each area to inventory processes and measure what happens if they stop: financial loss, contractual or legal breaches, harm to customers and to reputation. The result, for each process, is the maximum tolerable downtime and its dependencies: people, applications, data, suppliers and locations.
2. Risk assessment
We identify what could disrupt those processes and how likely it is: ransomware, a cloud provider outage, a power or connectivity failure, the office becoming unavailable, or the absence of the one person who holds the knowledge. We prioritise by impact and likelihood, not by what is in the news.
3. Recovery and continuity strategies
For each critical process we define how it will be kept running or recovered: secure remote work, an alternative site, a backup supplier, temporary manual procedures, system replication or restore from backup. Each strategy comes with its cost so management can choose with numbers.
4. Response plan and crisis communication
We write the operational plan: who declares the crisis, who sits on the crisis committee, the call tree, prepared messages for staff, customers and suppliers, and step-by-step procedures for each scenario. Technical recovery procedures are written as runbooks a technician can follow under pressure.
5. Testing and maintenance
We test the plan with tabletop exercises and, where appropriate, real restores and failovers. Each test produces a report of what worked, what did not and the actions pending. We review the plan at least once a year and whenever systems, suppliers or the organisation change.
RTO, RPO and maximum tolerable downtime
- Maximum tolerable period of disruption (MTPD): the point after which a process being down causes unacceptable harm.
- RTO (recovery time objective): how quickly it must be running again, always below the MTPD.
- RPO (recovery point objective): how much data you can afford to lose, measured in time since the last good backup.
An illustrative table for a services company (your real values come from your BIA):
| Process | MTPD | RTO | RPO |
|---|---|---|---|
| Customer service and email | 1 day | 4 hours | 1 hour |
| Invoicing and ERP | 3 days | 1 day | 4 hours |
| Payroll | 1 week | 3 days | 1 day |
| Corporate website | 2 days | 1 day | 1 day |
These objectives have direct consequences for the technology: a one-hour RPO cannot be met with a nightly backup. We explain it in more detail in RPO and RTO for businesses.
The technology side: what usually fails
- Backups that have never been restored. Without a tested restore, the RTO is a wish.
- Backups the attacker can reach. If the backup sits on the same network with the same credentials, ransomware encrypts it with everything else. You need an isolated or immutable copy; see our guide to cloud backups for business.
- Cloud services without a plan B. Microsoft 365, the cloud ERP or the hosted phone system also fail; you need to know what happens meanwhile and whether the data is backed up outside the provider.
- Access that depends on one person. Admin passwords, MFA on one employee's phone, a domain registrar account in the name of someone who has left.
- Communications. Without a backup line or call diversion, the company is cut off even if the systems work.
We fix these gaps within the project or through our managed IT services and cybersecurity services, so the plan and the infrastructure say the same thing.
Regulation and customers that ask for it
- NIS2: the directive lists business continuity, backup management and crisis management among its risk-management measures. Spain has not yet published its transposition law; Portugal already applies it. See our guides to NIS2 in Spain and NIS2 in Portugal.
- Spain's National Security Framework (ENS): suppliers to the public sector must show continuity measures proportionate to the system category.
- Financial-sector customers: the DORA regulation requires financial entities to manage the risk of their ICT suppliers, and those requirements reach suppliers through contracts.
- ISO 22301: the international standard for business continuity management. We use its structure as a framework; if you want to certify, the plan leaves you ready for it.
This is general information and not legal advice: if a regulation may apply to you, confirm it with your legal or compliance adviser.
What you get
- Process inventory and documented impact analysis, with MTPD, RTO and RPO per process.
- Dependency map: people, applications, data, suppliers and locations.
- Prioritised risk assessment.
- Recovery and continuity strategies with estimated costs, for management to decide.
- Continuity plan with roles, contacts, activation criteria and crisis communication.
- Technical recovery runbooks for critical systems: the disaster recovery plan itself.
- Test calendar and the report of the first exercise.
If you already have a plan, we start by reviewing it: whether it still reflects your processes and technology and whether it has ever been tested. Often the work is not writing a new plan but making the existing one work. It also fits a wider IT consulting engagement when the company's technology strategy is being reviewed.
Request a consultation: tell us which processes cannot stop and we will review your current plan, backups and critical suppliers.