What is a DRP and Why Your Data Center Isn’t Resilient Without One

Your data center has N+1 chiller redundancy, two UPS units in a dual bus configuration, a generator with 48 hours of autonomy, and a dual CFE utility feed. On paper, it is Tier III. In reality, you do not have a DRP.

The difference between the two concepts is the difference between an infrastructure that tolerates component failures and an organization that survives a disaster.

A DRP is not a document you file away and forget. It is the set of decisions, procedures, and drills that allow your operation to continue when the primary data center ceases to exist as such.

The acronym DRP stands for Disaster Recovery Plan. NIST SP 800-34 Rev. 1 defines it as the documented plan containing procedures to recover and restore critical IT systems and data in the event of a disaster.

But that definition is misleading because of how short it is. A serious DRP includes a Business Impact Analysis (BIA), tiered recovery strategies, defined alternate sites, documented operating procedures, roles and responsibilities, recovery metrics, periodic drills, and a dedicated annual budget.

Without all of that, you do not have a DRP. You have a document.

Why technical redundancy is not resilience

The most common mistake I see in Mexican data centers is confusing redundancy with resilience. They are different things. Redundancy is the duplication of components so that, if one fails, another takes its place. Resilience is the organization’s ability to keep operating its mission when the entire system, redundant or not, fails.

An example: your data center has two chillers in N+1. One fails. The second takes the load. That is redundancy working.

Now imagine a different scenario: a flood in the electrical room takes both chillers out of service at the same time. N+1 redundancy does not protect against this; it protects against a single component failure.

Resilience — keeping operations running — requires a plan that says: if this happens, critical servers migrate to the alternate site within 4 hours. That is a DRP.

The three numbers that matter: RTO, RPO, and MTPD

A DRP is measured by three parameters, defined in NIST SP 800-34 and adopted in ISO 22301:

• RTO (Recovery Time Objective). Maximum tolerable time between the service interruption and its restoration. If your RTO is 4 hours, the promise to the business is: after an interruption, critical systems are back in operation in less than 4 hours. Exceeding that time is a major incident that affects the customer’s operation and triggers contractual clauses.

• RPO (Recovery Point Objective). The maximum amount of data you are willing to lose, measured backward from the moment of the interruption. If your RPO is 15 minutes, it means the last valid copy of the data is at most 15 minutes old. This defines the replication technology: for an RPO of 0 you need synchronous replication; for an RPO of 5 minutes, asynchronous replication with a snapshot every 5 minutes is enough.

• MTPD (Maximum Tolerable Period of Disruption). The total time beyond which the organization is no longer viable. For a bank, the MTPD may be 24 hours; for a billing SMB, it may be 5 days. RTO is always less than or equal to MTPD. What happens between RTO and MTPD is the zone where business damage shifts from recoverable to catastrophic.

The 4 DRP tiers according to NIST

NIST SP 800-34 Rev. 1 classifies disaster recovery solutions into four tiers, from least to greatest capability:

Tier 1 — Simple backup with no alternate site

Tape or disk backups stored off-site (at another physical location). Typical RTO: 1-5 days. RPO: up to 24 hours.

Recovery involves restoring the backups onto new (or repaired) hardware at the original site or at a new one. Cost: low. Suitable for: historical archives, non-critical data, internal management systems.

Tier 2 — Warm alternate site (warm site)

A second data center with electrical, mechanical, and network capacity pre-installed, but without synchronized data. Servers exist at the alternate site but must be configured with data restored from backup.

Typical RTO: 12-48 hours. RPO: 4-24 hours. Cost: medium. Suitable for: critical internal systems with tolerance for half a day of downtime.

Tier 3 — Active alternate site (hot site) with replication

Two data centers operating in parallel with asynchronous data replication between them. The alternate site has full capacity and can take over the load with little reconfiguration.

Typical RTO: 1-6 hours. RPO: 5-30 minutes. Cost: high. Suitable for: mission-critical operations systems, ERP, and transactional platforms.

Tier 4 — Resilience with zero downtime and zero data loss

Multiple data centers with synchronous replication, load balancing between sites, and automatic failover at the application level. RTO: less than 1 hour (typically minutes). RPO: 0 or nearly 0.

Cost: very high. Suitable for: real-time financial services, trading platforms, and payments infrastructure.

The BIA: the first step before writing the DRP

Before writing a single line of the DRP, you must do a Business Impact Analysis (BIA). The BIA identifies the critical business functions, the systems that support them, the financial and operational impact of their interruption, and the dependencies between them. ISO 22301 defines the components of the BIA:

• Identification of critical activities. Which business functions, if interrupted, generate direct revenue loss, regulatory non-compliance, reputational damage, or customer impact.

• Dependency analysis. For each critical activity, which IT systems, which external providers, which public services (power, telecom, water), and which personnel are required.

• Financial impact estimation by duration of interruption. How much the business loses per hour, per day, per week of unavailability. This supports the calculation of which DRP tier is economically justified.

• Definition of RTO and RPO per activity. Not all activities need the same tier. A transactional platform may require an RTO of 1 hour; the internal financial reporting system may tolerate 24 hours.

The BIA takes between 4 and 12 weeks depending on the size of the organization. It is work driven by interviews with leaders of each area, not a document written by a single consultant.

If the BIA is done correctly, the DRP writes itself; if done poorly, the DRP ends up being a technically unachievable wishlist.

Disaster types the DRP must cover

A mature DRP covers at least these disaster categories, with specific procedures for each:

• Natural disasters. Flood, fire, earthquake, hurricane, structural failure of the building. The DRP defines the alternate site and the mobilization logistics.

• Extended power failures. CFE outage longer than 4 hours, generator failure, fuel exhaustion, UPS failure. The DRP defines when to evacuate to the alternate site and when to wait for recovery of the primary site.

• Telecom failures. Main internet provider outage, dark fiber failure, denial-of-service attack on the uplink. The DRP defines carrier redundancy and DNS failover.

• Cyberattacks. Ransomware that encrypts production data, information exfiltration, compromise of administrative credentials. The DRP defines communication with the incident response team, restoration from offline backups, and notification of customers and authorities.

• Human errors. Accidental database deletion, firewall misconfiguration, deployment of defective code to production. The DRP defines rollback procedures, restoration from a recent backup, and integrity validation.

• Provider failures. Outage of a critical SaaS service, cloud provider insolvency, hosting SLA breach. The DRP defines plan B when the provider does not respond.

How to write a DRP

The typical structure of a serious DRP, based on NIST SP 800-34 Rev. 1:

1. Scope and assumptions. Which systems it covers, what is assumed (personnel location, communication availability, excluded scenarios).

1. Roles and responsibilities. Who declares the disaster, who authorizes DRP activation, who executes each procedure, who communicates with customers and authorities. No personal names (they change); roles only: IT Director, NOC Manager, Communications Lead.

1. Detection and activation procedures. How to identify that the event qualifies as a disaster (time threshold, impact severity), how to escalate to the crisis committee, and how to formally declare the active DRP state.

1. Recovery procedures. For each critical system: step by step to bring it up at the alternate site or restore from backup. Includes commands, IPs, contacts, and dependencies.

1. Communication procedures. Who speaks with customers, regulatory authorities, the media, employees, and providers. Pre-approved communication templates.

1. Return to normal plan. Once the primary site is recovered, how to bring operation back without generating a new interruption. Includes maintenance window, integrity validation, and data synchronization.

1. Metrics and KPIs. Actual RTO vs target, actual RPO vs target, disaster declaration time, full recovery time, and number of incidents covered by drills.

The most expensive mistake: a DRP without drills

I have seen perfectly drafted DRPs, 200 pages long, with network diagrams, step-by-step procedures, and approval signatures. I have also seen those same DRPs fail when they were needed, because no one had tested them.

A DRP that has not been executed in a drill is a theoretical document. The first time it runs under pressure, the document reveals its inconsistencies, omissions, and wrong assumptions.

The minimum acceptable frequency of drills:

• Once a year, full recovery drill at the alternate site (with a planned primary site outage or simulated unavailability).

• Twice a year, partial drill of one or two critical systems (restore from backup, application failover, switchover of telecom provider).

• Quarterly, tabletop exercise. The team sits down, the facilitator presents a scenario, and they discuss step by step what they would do.

Each drill should generate a post-mortem document: what worked, what failed, what to adjust. The DRP is updated with those findings. A DRP without a post-mortem is a DRP that ages badly.

How to choose the right tier for your organization

Three questions any CFO will answer without trouble:

1. How much do you lose per hour of downtime on your most critical system? If the answer is less than around $2,800 USD/hour (~$50,000 MXN/hour), a Tier 1 or 2 is probably enough. If it is more than around $27,800 USD/hour (~$500,000 MXN/hour), you need Tier 3 or 4.

1. What is the annual cost of operating each tier? Tier 1: low (offline backups, around $11,100 USD/year [~$200,000 MXN/year]). Tier 2: medium (warm site, around $55,000-167,000 USD/year [~$1-3M MXN/year]). Tier 3: high (active site, around $278,000-833,000 USD/year [~$5-15M MXN/year]). Tier 4: very high (multi-site with synchronous replication, above $1.1M USD/year [~$20M+ MXN/year]).

1. What is the annual probability of a disaster requiring the DRP? If you operate in a high-seismic zone or a hurricane zone, the annual probability of a major event is higher, which reduces the payback time of Tier 3 or 4. If you operate in a stable zone with robust technical redundancy, Tier 2 may be enough for years.

The answer is not always the highest tier. It is the tier where the annual DRP cost is less than or equal to the expected annual loss from disasters. That is the correct financial decision.

Recommendation to get started

If you do not have a DRP today, this is the minimum viable order:

1. Identify your 3-5 most critical systems. What, if it goes down for 24 hours, generates direct revenue loss or regulatory non-compliance.

1. For each one, define RTO and RPO with the business owner. Do not invent them yourself.

1. Document the recovery procedure for each one, step by step, in a document that a person with medium technical knowledge can execute (not the expert who left 6 months ago).

1. Set up offline backups (tape, external disk, immutable storage) that are tested by restoring at least quarterly. A backup that has not been tested by restoring is not a backup.

1. Run a tabletop exercise in the next 60 days. The facilitator presents a scenario: the primary data center is inaccessible. What do you do in the first hour? Who talks to the customer? How do you recover the most critical system?

That is the minimum. It is less than a formal DRP, but it is more than most organizations in Mexico have. From there, scale to the tier your BIA justifies.

Sources and references

• NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems — https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf

• ISO 22301:2019 — Security and resilience: Business continuity management systems — Requirements — https://www.iso.org/standard/75106.html

• DRI International (DRII) — Professional Practices for Business Continuity Management — https://www.drii.org/

• Sentinel One — RTO vs RPO: Key Differences in Disaster Recovery Planning — https://www.sentinelone.com/cybersecurity-101/cloud-security/rto-vs-rpo/

• Splunk — What is Business Impact Analysis? — https://www.splunk.com/en_us/blog/learn/business-impact-analysis-bia.html