ServiceNow Business Continuity Management Testing and Acceptance Checklist

This checklist covers how to plan, run and accept a Business Continuity Management test. Start by defining scope and entry criteria, then choose a test layer: a tabletop review, a simulated disaster or a full recovery. During the test, validate each recovered system, record what actually happens and sign off only against agreed acceptance criteria.

Pre-Test Scope and Entry Criteria

Before starting a Business Continuity Management test, define scope. Are you testing the entire continuity plan or a specific recovery procedure? Are you testing one system or multiple systems? Are you testing recovery from primary data centre to backup data centre, or recovery to alternative processes? Scope defines what you will test and what is out of scope.

Establish entry criteria: what conditions must be true before the test can start? The test plan must be approved. The recovery environment must be prepared and ready. Personnel must be notified and available. If these conditions are not met, defer the test rather than proceeding with incomplete preparation.

Test Layers and Scenarios

Testing happens in layers. A tabletop exercise is the first layer: the team reviews the plan on paper, walks through steps, and discusses what would happen in a real disaster. No actual systems are affected. This is a low-risk way to identify major flaws before attempting an actual recovery. Conduct tabletop exercises quarterly.

The second layer is a simulation: you simulate a disaster (for example, announce “the primary data centre is offline”) and see how the team responds. Some systems are actually recovered; others are simulated. This is more realistic than a tabletop but still controlled. Third layer is a full recovery test where all systems are actually recovered in the backup environment. This is the most realistic and most risky; it should be done annually or after major changes.

Execution Procedures and Monitoring

During a test, assign a test coordinator to manage time and track progress. Assign an observer to watch for issues and document what happens (not what was supposed to happen). Assign system leads to execute recovery procedures and report status. Define communication methods: how will teams report status to the coordinator? Use a conference call or a dedicated communication channel.

Monitor start time, estimate completion time, actual completion time, and any deviations. If a procedure fails, note the failure and the reason. If a procedure takes longer than expected, investigate. If a procedure triggers an unexpected problem, document it. Do not try to hide problems during a test; that defeats the purpose of testing.

Validation Checklist During Test

As systems are recovered, validate that they work. Create a validation checklist for each system or procedure. For a database recovery, the checklist includes: database is online, tables are accessible, data is consistent, no errors in the event log. For a network failover, the checklist includes: network is online, connectivity is functional, performance meets requirements. Run through the checklist as recovery progresses.

Validation should check for data integrity. After a backup is restored, run a data integrity check: do record counts match, do key columns have values, are there unexpected nulls or duplicates? Compare data before and after recovery to ensure no data was lost or corrupted. Do not skip data validation; a recovery that restores data that is wrong is a failed recovery.

Evidence Collection and Documentation

Collect evidence during the test to prove that recovery worked. Take screenshots of system status (online, reachable, performing). Capture logs showing successful recovery operations. Document start and end times. Collect data validation reports. Capture any errors or warnings that occurred. This evidence is valuable for regulatory audits and for demonstrating that your disaster recovery procedures work.

Document exceptions and workarounds. If you had to manually intervene because a procedure failed, document what happened and what the workaround was. If a procedure took much longer than expected, capture why. Use this documentation to improve the procedure for next time.

Post-Test Analysis and Regression Traps

After the test, analyse results. Did all systems recover successfully? Did recovery happen within the RTO? Was all data recovered (RPO met)? Did integrations between systems work? Were communication and decision-making effective? Document lessons learned: what went well, what went poorly, what needs to be fixed?

Identify regression risks: changes that were made since the last test that might break recovery. New systems were added; does the recovery plan include them? System configurations changed; does the backup capture the new configuration? New integrations were added; was the dependency documented? Review these risks before declaring the test successful.

Acceptance Criteria and Sign-Off

Define acceptance criteria before the test begins. For example: all critical systems recover within RTO, all data is recovered within RPO, communication works without email or primary systems, recovery team can execute procedures using documentation without live trainer guidance, and no data corruption is found after recovery. The test passes if all acceptance criteria are met.

Assign acceptance authority: who decides if the test passed? Usually the business continuity manager and business stakeholders decide. Get sign-off from leadership after the test. This creates accountability and ensures that concerns are escalated, not ignored.

Issue Tracking and Closure

For each issue found during the test, create an issue record: what is the issue, what is the impact, what is the cause, and what is the fix? Assign ownership and a target completion date. Track issues to closure. Issues should be fixed before the next test or before a real disaster occurs. If an issue remains open past the target date, escalate to leadership.

Continuous Improvement from Test Results

A test is only valuable if you use the results to improve. Do not file the test report and forget it. Use test results to update documentation, fix procedures, improve timelines, and train teams. Track metrics over multiple tests: is RTO improving, are issues decreasing, is test duration stable? Use the trend to assess whether your disaster recovery programme is maturing.

Decide what a test is allowed to break before it starts

A continuity test lead is often handed a plan and a date, and a common mistake at that point is to treat the exercise as a single event. It is better to think of it as a set of permissions. Some tests may stop a production service for a short window. Others may only move traffic or restore a copy of data into an isolated environment. Before anyone touches a system, the lead should write down which systems are in the blast radius, which business users will feel an effect, and who has the authority to halt the exercise if the effect spreads further than planned.

Before choosing, it helps to read the business continuity management overview so that the test matches the scope the program has already agreed. The choice of test type should follow from what you are trying to learn, not from what the team is comfortable doing. A tabletop walk-through is good at exposing wrong assumptions about roles and decision rights. A simulated failover is good at exposing wrong assumptions about timing and communication. A live recovery is the option that most fully tests whether the backup actually restores. Many programs need all three over time, but a single test should answer one main question so that a failure has an obvious cause.

Ordered steps for the lead before the first recovery action

1. Confirm that the plan version under test is the one in the approved record, and note its last review date in the test file.
2. Walk the dependency list with each system owner and mark any link that is not recorded in the configuration data. An undocumented link is a finding even if the test never reaches it.
3. Agree the stop condition in writing. It should name the signal (for example, data that fails a reconciliation check, or a business-critical service that cannot be restored inside the window) and the person who calls the stop.
4. Check that the out-of-band channel works before the test begins, not during it. Send a test message to every participant through that channel.
5. Freeze unrelated change for the test window so that a planned release does not confuse the results; the approach to change freezes is a useful reference for how to scope that freeze.
6. Brief the observer on what to record, using the same discipline as a hypercare checklist after a go-live. The observer is not there to help with recovery; their job is to write down what actually happened, including the parts that went well.

What to record while the exercise is running

Many test reports are thin because they were written from memory a week later. The record should be built in real time, with timestamps against each step. Ask the observer to capture the time a decision was requested, the time it was made, who made it, and what information they had at that moment. Those four fields explain more about a slow recovery than any summary of the procedure does, and they are the kind of trail described in audit trail evidence planning.

For technical steps, record the exact command, screen, or ticket that confirmed success, and note whether the confirmation came from the system itself or from a person’s judgment. A service that answers a health check is not the same as a service that serves the expected records. Where a step was skipped because it was thought unnecessary, write that down as a deviation with the reason given. Skipped steps are often the origin of the surprises that show up in the next real incident.

Telling a useful failure from a damaging one

Not every failed step means the test failed. A useful failure is one that is understood, bounded and recorded: the procedure was wrong in a specific way, the affected system was returned to its prior state, and the owner can state what will change. A damaging failure is one where nobody can say what state the data is in, or where a workaround was applied quietly and nobody recorded it. The first kind feeds the improvement list. The second kind should stop the exercise and trigger a separate investigation before anyone repeats it.

Be careful with the phrase partial success. It is often used to describe a test in which the main system came back but a dependency did not. Treat that as a failed recovery of the business service, even though the infrastructure team will report a pass. The continuity question is whether the service the business needs can be used, not whether a component is running.

Questions test leads ask after the first run

Can a test count if one dependency had to be simulated?

It can count, but the report must say so in the same sentence as the result. A recovery that depended on a simulated supplier feed proves that your internal steps work and says nothing about whether the supplier would have behaved the same way. Record the simulated dependency as an open risk so it is not forgotten the next time the plan is reviewed.

What do we do when the recovery works but takes far longer than the plan says?

Record the actual elapsed time for each step and compare it with the planned time. Do not adjust the plan to match what happened on the day. The gap is the finding. Decide whether the plan needs a more realistic timeline, a second person on the critical step, or a different recovery route, and assign that decision to the plan owner.

Who should be able to stop a live exercise?

The lead should have the authority, and the business continuity owner should be the escalation point if the lead is unavailable. Anyone who sees a stop condition met should be able to raise it through the agreed channel without waiting for approval. Make that explicit before the exercise, because people hesitate to halt a test they were told was important.

Should the same person run the test and write the report?

It is better that they do not. The lead is absorbed in coordination and is least able to see what the team did under pressure. Use the observer’s record as the primary source and let the lead review it. A report written by someone who was also operating a system tends to describe the plan as it was intended to be followed.

Bring the test scope to a working session

Agreeing stop conditions and the record format early makes the result far more useful.