EN 
PT 
ES 
A DRP, or Disaster Recovery Plan, is the plan that defines how operations resume after a serious outage: what comes back first, how quickly, with how much data loss considered acceptable, who executes it and how the team confirms that the environment is running again. Without that plan, recovery depends on whoever happens to be available and on what that person remembers in the middle of a crisis.
Almost every midsize and large company has backups. Even so, few can state, with a number, how long it takes them to resume operations after a serious incident. That distance between holding a copy of the data and being able to resume the business is exactly what a DRP addresses.
If your question is still one layer earlier, at the level of copies and retention, the article on the advantages of cloud backup covers the 3-2-1 rule and what separates backup from recovery.
Why recovery takes longer than companies expect
The pattern repeats. The incident happens, the backup is intact, and even so operations take days to return. Not for lack of data, but for lack of sequence.
The team starts restoring whichever system someone remembered first, discovers midway that it depends on an authentication service that is not up yet, goes back, brings up the authentication service, and then realizes a certificate is missing because it was stored in the environment that went down. Each of these discoveries costs hours, and mapping the dependencies beforehand would have revealed all of them.
It follows the same logic as an office move. In practice, having all the boxes is different from knowing which one to open first so the company can work again tomorrow morning. The DRP is the order of the boxes.
RTO and RPO, the two numbers the business defines
Every plan rests on two numbers, and they are not an IT decision.
The RTO, Recovery Time Objective, is the maximum acceptable time between the outage and the return of the service. The question it answers is: how long can the company operate without that system.
The RPO, Recovery Point Objective, is the maximum acceptable data loss, measured in time. The question is: if we lose the most recent transactions, how many hours of work will have to be reentered by hand.
The business provides the answers. IT sizes the architecture that meets them, and cost follows that choice closely.
In the first conversation, it is common for every system to be classified as critical, with a one-hour RTO for all of them. Real prioritization appears when the cost of the corresponding architecture comes to the table. At that point the ERP that sustains billing keeps an RTO measured in hours, and the internal ticketing system can come back the following day without anyone losing money over it.
Arriving at those two numbers has a method, and it starts before the RTO: the article on how to set RTO and RPO covers the assessment with the business areas, the criticality scale, and the mistake that invalidates the number.
What goes into a DRP
Once the assessment is complete, the plan is organized essentially around four areas:
- Classification and dependencies. The list of systems with criticality defined by the business, and the map of what each one needs in order to run. It is the least expensive part of the work and the one that reduces recovery time the most.
- Strategy per workload. The decision on how each system is recovered. Not every system justifies the same investment.
- Executable procedure. The actual step by step, with startup order, commands, credentials accessible outside the environment that went down and an objective criterion for declaring the system restored. A generic document does not recover an environment.
- Roles and communication. Who declares the disaster, who executes, who speaks with clients and who authorizes the return to normal operations, with alternate contacts, because the crisis may reach the company's own email.
How to choose the recovery strategy
Four models cover most cases, and the difference between them is always the same trade-off: the faster the return, the higher the cost of keeping the structure on standby.
In backup and restore, there are copies of the data and the environment is brought up again when needed. It is the least expensive and the slowest, with recovery in hours or days.
In pilot light, the essentials stay active at minimum scale, usually the replicated database, and the rest comes up when triggered. Recovery in hours.
In warm standby, a reduced copy of the environment runs at all times and takes over operations at expanded scale. Recovery in minutes.
In active-active, two environments operate in parallel and traffic is redirected. Recovery is almost immediate, and it is the most expensive model.
The choice is made system by system, not for the entire company. The most common design combines the extremes: active-active for what sustains revenue, backup and restore for what can wait.
The cloud has changed this equation for the better. Maintaining a second environment no longer requires an idle data center, because the cloud provisions resources when they are needed and replication across regions resolves much of the design. What has not changed is the need for the plan: replication without a procedure, without an agreed-upon RTO and without testing is infrastructure, not continuity.
What an hour of downtime costs
The choice among the four models looks like a technical decision, and in the end it rests on a number that almost no company has: what each hour of downtime costs. Without that number, the decision is settled by whoever argues best. The business side asks for immediate recovery because it imagines the worst, and IT presents the price of active-active. With the number on the table, the conversation is no longer about what anyone believes, but about what pays for itself.
The calculation begins with the revenue that does not come in, which is the obvious part: the sale that does not happen, the order that is not invoiced, the support call that is never answered. In a business that bills by volume, dividing the revenue for the period by its working hours is enough for a first approximation. Next come the penalties, where there is a service level agreement with a client, because in that case the price of downtime is already written into a contract. Then there is the team that depends on the system and continues to be paid while it waits, a cost that runs even though no one is producing anything.
What is missing is the part that rarely appears in the spreadsheet and is usually the largest of all: the rework after the system comes back. Eight hours of orders written on paper amount to two days of data entry, with transcription errors along the way and customers calling to ask where their orders are. Operations do not return to normal when the environment comes back online; they return when the backlog has been cleared, and that interval is almost always longer than the outage itself.
Added together, these four components give the cost per hour of each business function, and the number has to be produced function by function. Billing, shipping and customer service come to very different numbers, and that contrast is what justifies a different model for each one.
Once that number exists, the comparison between the models becomes arithmetic. The model to choose is the first one whose annual cost of keeping the structure on standby falls below the loss it prevents, and the spread between them frames the choice: backup and restore costs little more than storage, pilot light adds whatever remains powered on, warm standby keeps a fraction of the environment running around the clock, and active-active means paying twice for the infrastructure, forever. For most functions in a mid-sized company, that crossover point falls between four and twenty-four hours, almost never at zero. When the arithmetic points to zero, the cost of downtime has usually been overestimated, and it is worth rerunning the numbers before submitting the budget for approval.
Why the plan fails when it matters
Even with a sound initial design, plans fail for well-known reasons.
The first is the plan written for the audit. It satisfies the questionnaire, looks good in the report and is of no use in the small hours of an incident, because it lacks the execution detail.
The second is documentation stored inside the very environment that is supposed to be recovered. When the environment goes down, the plan goes down with it.
The third is access concentrated in a single person. If recovery depends on someone who is on vacation or unreachable, the agreed-upon RTO becomes an optimistic estimate.
And the fourth is the outdated plan. The environment changes every month, the plan was written once, and recovery is attempted with an old map.
Testing, the part almost no one does
A plan that has never been executed is a hypothesis. Testing is what turns the RTO from an intention into a measured number, and it has three levels.
A tabletop exercise walks through the plan verbally against a scenario, without interrupting anything. It sounds modest, and it is where gaps in responsibility and wrong contact details come to light.
The partial test recovers one system in the alternate environment, within a scheduled window. It validates the procedure and measures the actual time.
The full failover transfers operations to the secondary environment. It is the only one that proves the RTO in practice, and the one that demands the most preparation.
The cadence that works is an annual review of the plan and a partial test every six months on critical systems, with a record that notes the measured time, not the estimated time. The gap between those two numbers is usually the most useful information the exercise produces.
Each of those levels has a name in the standard and a different cost in downtime. The article on how to test a continuity plan separates an exercise from a test, and shows what fits outside the window.
How does Integrity-UX conduct this work?
We start with the classification of systems together with the business areas, because RTO and RPO are business decisions, and we map the dependencies between applications, which is where time is lost during recovery. From there, we define the strategy for each workload, write the procedure in executable form and assign the roles.
Then come the tests, with a record of the actual recovery time, and the periodic review that keeps the plan aligned with an environment that never stops changing.
Learn about the Integrity-UX DRP service or talk to a specialist.
Next steps
If your company has backups but cannot say how long it takes to resume operations, the first step is not to buy technology. It is to answer, together with the business, how long each system can stay down and how much information can be lost. Those two numbers define everything else, including the investment.
Frequently asked questions
What is a DRP?
A DRP, or Disaster Recovery Plan, is the document that defines how IT operations resume after a serious outage, with priorities, deadlines, procedures and owners.
What is the difference between a DRP and a backup?
A backup is the copy of the data. A DRP is the plan that brings operations back online, with recovery order, alternate environment, owners and validation criteria. The backup is an input to the plan, not the plan itself.
What are RTO and RPO?
RTO is the maximum acceptable time until the service is back. RPO is the maximum acceptable data loss, measured in time. Both are defined by the business and determine the cost of the solution.
How often should a DRP be tested?
A review of the plan at least once a year and a partial test every six months on critical systems. Any significant change in architecture calls for a new validation.
Is a DRP mandatory?
There is no Brazilian law that requires a plan under that name. The LGPD requires the adoption of security measures that preserve the availability of data, and the ISO 22301 standard addresses business continuity. Regulated sectors, such as financial services, have requirements of their own.
How long does it take to build a DRP?
It depends on the number of systems and the maturity of the environment. What determines the timeline is the mapping of dependencies and the definition of RTO and RPO with the business areas, not the technical work.
This content was produced by the Integrity-UX team, an IT consultancy specializing in infrastructure, continuity and cloud for midsize and large companies.
Source: ABNT NBR ISO 22301, business continuity management systems.
