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.
O 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.
O 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.
What goes into a DRP
Once the assessment is complete, the plan is organized essentially along four fronts:
- 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 RTO and without testing is infrastructure, not continuity.
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 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.
O partial test recovers one system in the alternate environment, within a scheduled window. It validates the procedure and measures the actual time.
O 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.
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.
