How to run business continuity tests with an AI agent

Use the agent as the test's clerk, not its operator. It assembles the test pack, checks plans and contact lists are current, sends scripted test notifications, timestamps every recovery step and compares results with recovery objectives. People choose the scenario, perform every failover, judge the outcome and sign the report. And test what happens without the agent.

What is a business continuity test, and who owns it?

A business continuity test checks that the firm can keep its important services running, or restore them in time, when something fails: a site is lost, a key system goes down, a supplier stops, staff cannot get to work. Tests range from a walk-through of the plan to a full failover of a live system to a backup site.

The business continuity manager owns the testing programme. Each service owner owns their recovery plan and its objectives, such as how quickly the service must be restored. Technology owns the technical recovery steps. Many financial regulators expect firms to test their resilience; in the EU, DORA requires digital operational resilience testing, and in Australia APRA's CPS 230 sets expectations for operational risk management, including business continuity, as discussed in our brief on operations in business banking in Australia.

The test itself produces evidence that supervisors and auditors read. Much of the effort in a test is clerical: assembling plans, checking contacts, recording times, compiling results. That is where the agent helps.

What are the steps, and at what depth?

1. Business continuity manager: sets the scenario, scope and success criteria. Which services, which failure, which objectives must be met.
2. Agent, depth 1: assembles the test pack: the relevant recovery plans, the contact lists, the recovery objectives, the results and open actions from the last test.
3. Agent, depth 1: checks the plans are current. Named owners still in post, contact numbers that match the HR directory, systems listed that still exist, dependencies that match the current architecture. It lists every discrepancy.
4. Service owners: fix the discrepancies before the test, or record that they are accepted.
5. Agent, depth 3: sends scripted test notifications at the agreed time, through the call tree or notification tool, each clearly marked as a test.
6. Agent, depth 3: keeps the timeline during the test: when each step started and ended, who reported it, any deviation from the plan.
7. Technology and service owners: perform every recovery action. Failover, restoration, switching to manual processes. The agent never executes recovery steps.
8. Agent, depth 1: compares achieved times with objectives and lists every gap.
9. Agent, depth 2: drafts the test report: scenario, timeline, results against objectives, issues, proposed actions and owners.
10. Business continuity manager: reviews and signs the report; service owners accept their actions.

Why does the agent never run recovery steps?

Recovery actions are among the riskiest things a technology team does. A failover performed at the wrong moment, or to the wrong environment, can cause the outage it was meant to rehearse. These actions need a person who can see the whole situation and stop if something looks wrong. They are also the thing the test is meant to prove people can do. An agent performing them would test the agent, not the plan.

How do you test continuity of the agent itself?

Agents are now part of the services you are trying to keep running. Each business continuity plan for a service the agent supports should answer: what happens if the agent is unavailable, if its model provider is down, if its sources cannot be reached, or if it drops to depth 1 after a lapse or a run that clears no depth?

Build at least one scenario a year around this. The agent goes to depth 1, or off entirely, and the team runs the work without it. Measure how long it takes to get the fallback team working and whether they still know how. The answer often reveals that the plan assumed the agent would always be there.

Which controls apply, and what evidence does each leave?

Scenario and criteria set in advance. Evidence: the signed scope, dated before the test.

Plan currency checked. Evidence: the discrepancy list and how each was resolved.

Test notifications marked as tests. Evidence: the message text and recipients.

An independent timeline. The agent records times as reported, from its own clock, so the record does not depend on people's memory after the event. Evidence: the timestamped log.

Recovery actions performed by named people. Evidence: who did each step, from the timeline.

Gaps turned into owned actions. Evidence: each action, its owner and due date, tracked to closure.

The same discipline of preparing evidence and leaving the judgement to people applies to running compliance monitoring tests with an AI agent.

What should you measure?

• Plan discrepancies found before each test, which should fall over time.
• Recovery objectives met, by service.
• Actions from previous tests still open.
• Time to restore work without the agent, in agent-unavailable scenarios.
• Time from test end to signed report.

Where does it usually go wrong?

Test notifications look real. A message that is not clearly marked as a test causes panic or, worse, real action. Every scripted message carries a test marker in the first line.

The plan is tested, not reality. The agent checks the plan against itself and finds no problems. It must check against live sources: the HR directory, the asset register, the supplier list.

The report is too clean. A drafted report reads well and hides the struggle. The business continuity manager should add what the timeline does not show: confusion, workarounds, and luck.

The agent's own failure is never tested. It is the newest dependency and the one least likely to appear in old scenarios. Add it, as you would any change introduced through train, shadow, certify, widen.