Disaster Recovery Consulting: How the Project Works and What It Delivers

A disaster recovery (DR) consulting project has a start, a middle and an end. It begins with the environment a company runs today and ends with a written recovery plan with a test plan and a trained team, with a named owner for every step of the recovery.

In practice the work breaks into seven stages: risk analysis, a systems and dependency inventory, RTO and RPO agreed with each business area, recovery order and runbooks, owners and alternates, a test plan with training, and periodic review. Every stage produces a concrete deliverable, so the company knows what it will receive before the work starts.

This article explains how that project works from the inside, who has to take part, and where it tends to stall. For the basic definitions of DR, RTO and RPO, read DRP (Disaster Recovery Plan): what it is, how to build one and how often to test it (in Portuguese). Here the focus is how the engagement is run.

When disaster recovery consulting makes sense

Consulting is not the purchase of a tool, and it is not a document that sits in a drawer. It makes sense in three common situations.

• There is no plan. Recovery depends on the memory of two or three people, and nobody can say in what order the systems come back.
• There is an old plan. It was never tested, or it did not keep up with changes in the environment: new systems, new vendors, people who left.
• The company is about to change its environment. A cloud migration, a data center move or a consolidation is the best moment to build recovery into the design from day one.

Consulting does not replace the in-house team. It adds experience to a project the team runs only a few times in a career, and it leaves the plan in the hands of the people who will execute it.

Where a DR project usually stalls

Almost every company has some kind of backup. Few have a plan that says, without improvisation, what comes up first, who makes the call, and what to do when the one person who knows the system is not answering the phone.

The work stalls at three well-known points:

1. DR treated as an IT-only topic. The business is left out of the decisions on downtime and data loss, and the plan is built on numbers nobody approved.
2. A plan written as an audit document. It looks polished but has no step-by-step that anyone can follow at 3 a.m. during an incident.
3. A plan that was never exercised. It only gets validated on the day it is too late to fix it.

A well-run project addresses all three from the start. The plan ships with a test plan and team training; the test itself comes later, run together with the company. That is why the list of deliverables below mixes business decisions, documents and a testing routine.

The seven stages of the project, one by one

The order matters. Each stage uses the output of the previous one, and skipping a stage usually shows up later as a hole in the plan.

1. Risk analysis

The starting point is the threats that could stop operations in that specific environment, from ransomware to hardware failure to the loss of a site. The result is a prioritized list that shows where to invest first. A generic plan tends to fail in exactly the scenario nobody mapped.

What you receive: the list of scenarios, ranked by the effect each one would have on operations.

2. Systems and dependency inventory

This is where you find out what exists, what is critical and what depends on what. It prevents the classic surprise: a cloud system that will not come back because it depends on an on-premises authentication service. The inventory includes the business impact analysis (BIA): knowing what each system supports and what the company loses when it goes down.

What you receive: the systems inventory and a map of what depends on what.

3. RTO and RPO agreed with each business area

RPO is how much data the business can afford to lose. RTO is how fast a service has to be back. The person who owns the process sets both numbers, because they are a business decision with a cost: the shorter the time, the larger the investment. IT explains how to deliver the number, not which number is acceptable. The article How to define RTO and RPO (in Portuguese) covers that conversation.

What you receive: an RTO and RPO table per system, approved by the owner of each process.

4. Recovery order and runbooks

With RTO, RPO and dependencies on the table, you set the order: what comes up first, how, and what waits. Each step becomes a runbook written for the person who will execute it, not for the person who will audit it.

What you receive: the recovery sequence and the step-by-step runbooks.

5. Owners and alternates

Every step has an owner and an alternate. The plan has to work when the primary person is on vacation, sick or out of reach.

What you receive: the list of roles, with a primary and an alternate for each.

6. Test plan and training

The plan ships with a test plan, and the team is trained for its roles. The test itself is run later, together with the company, at the agreed interval, and whatever fails goes back into the plan. The article How to test a continuity plan without stopping operations (in Portuguese) covers the test formats.

What you receive: the test plan and a team trained to run it.

7. Periodic review

Systems change, vendors change, people change. The periodic review checks that systems, dependencies and owners are still the same. A significant architecture change, such as a migration or a new system, calls for a review outside the calendar.

What you receive: the updated plan, with a record of what changed.

Who needs to be in the room

Three groups take part in the project, and none of them can stand in for the others.

• Business areas: define how long operations can stay down and how much data can be lost.
• IT and infrastructure: report what exists, design the recovery strategy and execute the procedures.
• Leadership: approves the investment the business numbers require and decides when the plan is triggered.

If only IT takes part, the result is a plan that is technically correct for numbers nobody approved.

A conversation that shows the difference: when IT asks “how long can billing be out?”, the answer usually comes back as “as little as possible.” That number cannot be used to design anything. The project swaps in a question the manager can answer: “what happens to operations if this system is down for half a day? And for two days?” From that answer on, RTO stops being a guess.

How to choose the recovery strategy for each system

Not everything has to come back at the same speed, and that distinction is what controls cost. Strategies range from restoring from backup, the cheapest and slowest, to a hot standby environment that is already running and synchronized, the most expensive and the fastest. A DR project does not require a duplicate secondary site: the choice is made system by system, according to the RTO the business set.

In practice, the design follows four questions, in order:

1. What is this system’s RTO? The lower it is, the closer to standby the strategy has to be.
2. What is its RPO? If the company cannot lose more than a few minutes of data, a daily backup is not enough and some form of replication comes in.
3. What does it depend on? A fast strategy is no use if the service it depends on has a slow one.
4. What does it cost to keep this strategy? Cost goes into the conversation with leadership next to the business number, so the decision is made with eyes open.

An illustrative example, not from a client: an internal lookup system the company can do without for a day is usually recovered from backup. The order system, without which the company stops selling, calls for a faster strategy. The same environment holds both, each at a cost the business can carry.

Two distinctions help the conversation. Backup keeps copies of the data, and DR organizes the recovery of the environment. High availability keeps a service up when a component fails, but it replaces neither backup nor DR. For the first, see our Backup page (in Portuguese).

Hybrid environments and ransomware

In a hybrid environment, the plan deals with the dependencies between what runs on premises and what runs in the cloud, which is where the surprises tend to appear. A common example: the application runs in the cloud, but login goes through an on-premises identity server. If the local site goes down, the application, which was intact, no longer opens. We are a Microsoft Azure partner and also work with the other clouds.

With ransomware, the logic changes. After a physical disaster, the most recent copy will do. After an attack, it may already be compromised, and the plan has to provide for rolling back to a point before the infection. That affects backup retention and brings backup protection inside the DR design.

That is why the project treats ransomware as a separate case with its own procedure. It defines who decides to isolate the environment, which copy is considered trustworthy, and in what order systems come back once the environment has been cleaned.

How to tell whether the plan is good: a checklist

A good DR plan passes a short list of questions. If any answer is “no,” the plan still has work ahead:

• Does every critical system have an RTO and RPO approved by the person who owns the process?
• Is there a written recovery order that accounts for dependencies?
• Can each procedure be followed by someone who did not help write it?
• Does each role have a primary and an alternate, with current contact details?
• Does the plan have a test plan, and was what failed in past tests fixed?
• Is there a review date and a trigger for a review outside the calendar?
• Is the backup protected against alteration and deletion, including in a ransomware scenario?

The list is a starting point for a conversation with the team, not a certification.

What ISO 22301 changes in this work

ISO 22301:2019 is the international standard for business continuity management systems. We use it as a good-practice reference to structure the plan. A DR project does not certify the company to the standard: certification is done by an accredited certification body.

For further reading on contingency planning for information systems, there is NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, a guide from the U.S. standards agency, published in May 2010 and updated on 11/11/2010.

How Integrity-UX runs this work

It starts with a diagnostic of the current environment that maps systems, dependencies and single points of failure. The scope, the effort and the timeline for each phase come from it. Once the plan is ready, our team can support the periodic review and the execution of tests, depending on what the company needs.

Timeline and price depend on the scope and are set in a proposal. We have a certified team and work in the cloud, on premises and in hybrid environments.

Next steps

To reach the first conversation with something useful in hand, gather:

• the list of systems the company considers critical;
• the environment layout (on premises, cloud or hybrid);
• what backup already exists;
• whether any plan has been tested, and when.

With that, our team builds the diagnostic. See also the DRP (Disaster Recovery Plan) service page or talk to a specialist on our team.

Frequently asked questions

What does a disaster recovery consulting engagement deliver?

Risk analysis, a systems and dependency inventory, RTO and RPO agreed with each area, recovery order, step-by-step runbooks, owners and alternates, a test plan, training and periodic review.

Does disaster recovery require a duplicate secondary site?

Not necessarily. The strategy varies with each system’s RTO, from restoring from backup to a standby environment. Most companies use different strategies for different systems.

Who needs to take part besides IT?

The business areas and leadership. RTO and RPO answer how long operations can stay down and how much data can be lost, and only the person who owns the process can say.

What is the difference between disaster recovery and high availability?

High availability keeps a service up when a component fails. DR organizes the restart when the whole environment is lost. Neither replaces the other, and neither replaces backup.

Does the Integrity-UX DR service certify a company to ISO 22301?

No. The standard is used as a good-practice reference. ISO 22301 certification is done by an accredited certification body.

Does the plan cover ransomware?

Yes. The project treats ransomware as its own scenario, with a rollback to a point before the infection and backup protection built into the design.

How much does it cost and how long does it take?

It depends on the scope. Timeline and price are set in a proposal, after the diagnostic of the environment.

Last updated: November 11, 2026.

Sources:

• ISO 22301:2019, Security and resilience, Business continuity management systems, Requirements. Edition 2, published October 2019. iso.org/standard/75106.html (accessed 11/11/2026).
• ISO 22301:2019/Amd 1:2024, Security and resilience, Business continuity management systems, Requirements, Amendment 1: Climate action changes. Published February 2024. iso.org/standard/88412.html (accessed 11/11/2026).
• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems. Published May 2010, updated 11/11/2010. csrc.nist.gov/pubs/sp/800/34/r1/upd1/final (accessed 11/11/2026).