EN 
PT 
ES 
The plan is written. It was approved, signed, and filed in a shared folder. Someone asks when it gets tested.
The answer is always the same: we can't take the operation down.
So the plan sits there, untouched, for two or three years. Until the day it runs for the first time, with no rehearsal, with the business actually down and the clock running.
It sounds like a fair question, but it rests on a definition error. Most of what validates a continuity plan isn't a test at all, and it never touches production.
“Testing” and “exercising” are not the same thing
The NIST SP 800-84, published in September 2006 and written for exactly this problem, pulls apart three activities that usually get lumped together.
Test is an evaluation tool that uses quantifiable metrics to validate whether a system or component works in the environment the plan describes. Cutting power to a device is a test. So is measuring whether the call tree reaches everyone inside the time limit.
Training means telling people what their role in the plan actually is.
Exercise is a simulated emergency, run to find out whether one or more parts of the plan hold up.
The document is blunt about the line between them: “test” is reserved for systems and components, and is not used for exercising plans.
That matters more than it sounds. When the board asks whether the plan has been tested and IT answers that the operation can't be taken down, the two sides are answering different questions. One is about the plan. The other is about the system.
A tabletop exercise never touches production
What NIST calls a tabletop runs entirely on discussion. The people who own a role in the plan sit down together, a facilitator walks them through a scenario and asks questions, and the group answers the way it would answer in a real crisis.
The guide spells out the part that matters here: a tabletop exercise deploys no equipment and no other resources.
Nothing gets shut down. No service goes offline. And the exercise still finds what the document hides, because it forces the plan to answer questions nobody asked while writing it:
- who declares the disaster, and on what evidence
- who that person has to reach, and through which channel, if the ticketing system is down
- where the plan lives, and whether anyone can reach it when the file server is the thing that failed
- who decides for the business when the process owner is on a plane
- what the customer is told, and how fast
Those are questions about how the company is organized, not about technology. And almost all of them fail the first time somebody asks them out loud.
A functional exercise runs in a simulated environment
One step up is what NIST calls a functional exercise. Here people carry out the role they would have in a real emergency, but inside a simulated operational environment.
The scale is yours to set. It can cover one piece of the plan, such as emergency notification or the configuration of a single device, or it can run end to end across every element.
This is where the hands-on checks live, the ones that take work but not downtime: restore a backup into an isolated environment and open the application to confirm it comes up, bring the replica online on a separate network, confirm the software license exists somewhere other than the original server, time how long the team really needs for a procedure that is three lines on paper.
Having a backup and being able to restore it are two different claims. The second one only gets proven when somebody restores.
What really does need downtime, and how to shrink the window
It would be dishonest to say nothing requires downtime.
A real failover, where the operation moves to the standby environment and comes back, proves things no simulation proves: whether DNS propagates in time, whether third-party integrations point at the new address, whether the secondary environment holds the real load instead of the estimated one.
What gets negotiated is not whether there is downtime, but how much:
- one system at a time, instead of the whole environment, starting with the one that hurts least
- an agreed-upon window, in a quiet period, with the rollback planned before anything starts
- a defined abort criterion, the point at which the exercise stops and the operation goes back to normal, agreed in writing before the start
- a rehearsed failback, because coming back is usually the least documented part and the one that surprises people most
Two hours of downtime on the calendar costs less than two days of downtime nobody scheduled.
The standard asks for a program, not an event
ABNT NBR ISO 22301:2020, the Brazilian edition of the business continuity management standard, covers this in clause 8.5, the exercise program.
The text requires the organization to put in place and maintain a program of exercising and testing that validates, over time, how well its continuity strategies and solutions actually work. The exercises have to line up with the continuity objectives and, taken together over time, they have to validate the strategies in place.
Two words carry the weight in that sentence.
The first is program. The standard does not ask for an annual event. It asks for a sequence of exercises that, added up, cover what has to be validated.
The second is over time. The standard sets no frequency. The organization decides, based on its own continuity objectives and on how fast its environment changes.
That leaves room for the design that works in practice: tabletop exercises more often and at low cost, functional exercises at wider intervals, and the full failover on the systems where the risk justifies the window.
For regulated financial institutions, it is not optional
In part of the Brazilian market, continuity testing stopped being good practice and became a legal obligation.
A Resolution CMN 4.893, of 26 February 2021, which governs the cybersecurity policy of institutions authorized to operate by the Brazilian central bank, requires in article 3 that the policy set out how the incident scenarios used in continuity tests are to be built.
The same resolution requires the incident response plan to record the results of those tests, covering outage scenarios caused by incidents. It was amended by Resolution CMN 5.274, of 18 December 2025.
For payment institutions, the equivalent rule is Resolution BCB 85, of 8 April 2021.
In practice, for anyone under that regulation, the test scenario has to be defined in policy and the result has to exist as a document. A plan that was never exercised produces no such document.
What an exercise finds and a document never will
Continuity plans fail in predictable places, and that is exactly why exercising works.
NIST notes that exercises help surface gaps and inconsistencies in plans and procedures, and show where people need more training.
In practice, the failures sit at the seams:
- the procedure assumes two tasks run in parallel, and in execution they run one after the other, which blows the RTO without anything having gone wrong
- the person responsible for a step left the company, and the plan still has their name on it
- the credential you need is stored in the system the scenario just took down
- the restore time was estimated against a data volume from three years ago
- the vendor the plan calls has a response SLA longer than the RTO promised to the business
None of these show up in a document review, because the document is consistent with itself. They show up when somebody tries to execute it.
If the RTO and RPO in your plan have not been through this kind of check, the method for setting them is the step that comes before this one.
How does Integrity-UX conduct this work?
The work starts with the scenario, not with the environment. We define what will be exercised, who takes part, and which question the exercise has to answer, and that is agreed before anything goes on a calendar.
The first format is the tabletop, with the business areas that own a role in the plan. What comes out of it is the list of what nobody could answer, and that is almost always about decisions and communication rather than technology.
Then comes the functional exercise, in an isolated environment: a restore with the application opened, times measured against the RTO and RPO on record, and a check on the dependencies the paper assumes and the execution contradicts. Full failover goes where criticality justifies the window, with the abort criterion and the failback agreed in writing before the start.
Every round ends in a record: the scenario used, who took part, the times achieved against the objectives, the gaps found, and the changes made to the plan. That record is what ABNT NBR ISO 22301 expects from an exercise program, and what the Brazilian central bank requires from the institutions it regulates.
We are a Microsoft Partner, and we work both on the environment the client already runs, whether public cloud, their own data center or hybrid, and on Azure when that is the choice. This can be contracted alongside building the business continuity plan and DRP or applied to a plan that already exists.
Next steps
If your plan is written and has never been exercised, there is a check that needs no calendar and no window. Take the recovery procedure for one system and try to answer three questions: who declares the disaster, where the plan can be reached if the file server is the thing that failed, and whether the person named at each step still works here.
If those three answers don't come, the tabletop is your next step, and it fits in two hours.
For the layer underneath, where the numbers the exercise will test come from, the article on how to set RTO and RPO covers the method. For the structure of the document itself, the article on DRP covers what goes into the plan.
If you would rather talk about your own case, the business continuity plan and DRP page has a direct contact.
Frequently asked questions
Does testing a business continuity plan require downtime?
Not in most cases. NIST SP 800-84 reserves the word test for systems and components, and uses exercise for plans. A tabletop exercise runs on discussion alone and deploys no equipment. A functional exercise runs in a simulated environment. Only a full failover needs real downtime, and even that can be done one system at a time, in an agreed-upon window.
How often should the plan be exercised?
ABNT NBR ISO 22301:2020 sets no fixed frequency. Clause 8.5 requires an exercise and testing program that validates the continuity strategies over time. The frequency comes from the company's own continuity objectives and from how fast its environment changes. An environment that changes a lot needs a shorter cycle.
What is the difference between a tabletop and a functional exercise?
A tabletop is a facilitated discussion around a scenario, with no equipment deployed. It validates decisions, roles and communication. A functional exercise puts people through their roles in a simulated operational environment, and validates procedure, restore and timing.
What has to be recorded after an exercise?
The scenario used, who took part, the times achieved against the stated objectives, the gaps found and the changes made to the plan. For institutions authorized to operate by the Brazilian central bank, Resolution CMN 4.893/2021 requires the results of continuity tests to appear in the incident response plan.
Does restoring a backup count as a continuity test?
It counts as one piece of it. A restore proves the copy exists and the data comes back. It says nothing about how long the business takes to resume, whether the application starts in the alternate environment, whether integrations point to the right place, or whether people know what to do. Those take an exercise, not just a restore.
