Exercise programme

ISO 22301 Clause 8.5 requires you to establish an exercise programme that tests business continuity procedures at planned intervals, then feeds results back into improvements. To operationalize it quickly, define an exercise schedule, pick exercise types aligned to your critical processes, run and document exercises, track corrective actions to closure, and update plans and training based on lessons learned. ¹

Key takeaways:

• You need a planned, repeatable programme, not ad hoc “annual testing.”
• Exercises must validate real procedures and dependencies, then drive documented improvements.
• Audit success depends on artifacts: a schedule, scenarios, results, issues, and closed corrective actions.

An “exercise programme requirement” is often misunderstood as a single test event. ISO 22301:2019 Clause 8.5 is broader: it expects a managed programme that repeatedly tests business continuity procedures on a planned basis and proves the organization learns and improves from those tests. ¹

For a CCO, GRC lead, or resilience owner, the fastest way to implement is to treat exercises like any other control lifecycle: scope, schedule, execution, evidence, corrective action, and governance reporting. Your programme should cover the most important continuity outcomes first (critical products/services, key locations, key technology, and key third parties) and then expand in depth and realism over time.

This page gives requirement-level guidance you can drop into a control library and run operationally: who owns what, what to do step-by-step, what evidence auditors ask for, and the common failure modes that make an exercise programme look “paper-only.”

Regulatory text

Clause 8.5 requirement (excerpt): “The organization shall establish an exercise programme to test business continuity procedures at planned intervals.” ¹

Operator meaning: You must (1) define a programme (not a one-off test), (2) plan exercises on a schedule, (3) test documented continuity procedures in a way that demonstrates they work, and (4) keep evidence that outcomes drove updates to plans and procedures. ¹

Plain-English interpretation

An exercise programme is a calendar-driven set of BC exercises that proves your organization can execute its continuity procedures under realistic conditions. It also proves governance: you detect gaps, assign corrective actions, fix them, and update plans and training. A programme that runs exercises but does not track issues to closure will fail the intent of Clause 8.5 even if you have meeting notes and screenshots.

Who it applies to (entity and operational context)

This requirement applies to any organization operating a business continuity management system (BCMS) aligned to ISO 22301, across:

• Business units delivering critical products and services (operations, customer support, sales ops, finance).
• Technology and security functions supporting recovery (infrastructure, apps, IAM, SOC/IR).
• Facilities/workplace if physical sites matter (call centers, plants, warehouses).
• Third parties that are part of recovery paths (cloud providers, payroll processors, outsourcers, logistics partners). “Third party” coverage matters because BC procedures often depend on external services even when plans are internal.

Operationally, this requirement lands on a small set of accountable owners:

• BCMS owner / resilience lead: programme design, schedule, standards, reporting.
• Process/application owners: procedure quality, participation, remediation ownership.
• Risk/Compliance/Internal Audit: independent challenge, evidence expectations, closure verification.

What you actually need to do (step-by-step)

1) Define the exercise programme scope and rules

Create an “Exercise Programme Standard” (one document) that answers:

• What counts as an exercise (tabletop, technical recovery test, crisis comms drill, etc.).
• What must be exercised (critical processes, recovery procedures, communications, third-party dependencies).
• How often you plan to exercise (state your planned intervals without guessing a universal cadence).
• How you will record results, issues, and corrective actions.
• What “pass” means (criteria tied to your procedures and recovery objectives, if defined elsewhere in your BCMS).

Keep it simple. Auditors want consistency, not novelty.

2) Build a planned exercise schedule

Publish a schedule that maps:

• Exercise name
• Type (tabletop, simulation, technical, full-scale)
• Scope (process/system/site)
• Owner and required participants
• Target window (planned interval)
• Dependencies (third parties, shared services)
• Evidence pack location (where artifacts will be stored)

Practical tip: if you can’t schedule full realism yet, schedule smaller exercises that still test procedures end-to-end (for example, “restore access for critical users using documented steps” rather than “talk about restoring access”).

3) Design exercises that test procedures, not slide decks

Each exercise should include:

• Objective(s) tied to specific procedures (“execute call-tree escalation,” “run alternate payment process,” “recover application from backups”).
• Scenario with realistic constraints (missing staff, partial outage, third-party degradation).
• Success criteria stated up front (procedure followed, decisions logged, communications sent, handoffs completed).
• Injects (new information that forces use of procedures, not improvisation).
• Observers (people who record what happened, separate from doers).

4) Execute and capture results in a repeatable way

Run the exercise and document:

• Attendance and roles.
• Timeline of key actions and decisions.
• Where procedures worked and where they broke.
• Deviations from documented steps (and why).
• Communications outcomes (internal/external drafts, approval path, timing).
• Third-party interactions (tickets opened, escalations, SLAs invoked).

A common audit hangup: “You ran it, but you can’t show that you tested the procedure.” The fix is to annotate the procedure during the exercise (step numbers referenced in notes) and capture objective evidence (screenshots, ticket logs, call transcripts where appropriate).

5) Convert findings into corrective actions with owners and due dates

Create an issues log that includes:

• Finding statement (clear and testable).
• Root cause category (procedure gap, training gap, tooling gap, third-party gap).
• Risk rating (your internal method).
• Corrective action(s), owner, and target completion date.
• Verification method (re-test, manager sign-off, artifact review).

If your organization already has a GRC issue workflow, use it. If not, a controlled spreadsheet with change history can work, but it must show governance and closure.

6) Update continuity documentation and training

Clause 8.5 is about testing procedures. When issues are found, update:

• BC plans and runbooks
• Call trees and contact lists
• Communications templates
• Recovery scripts and access lists
• Third-party escalation paths

Then push changes into training or briefings for the teams who will execute in real events.

7) Report programme health to governance

Provide periodic reporting to the BCMS steering group or equivalent:

• Exercises completed vs. planned
• High-risk findings and remediation status
• Trends (repeat findings, chronic dependencies)
• Upcoming exercises and scope changes

This is where you prove the programme is managed.

Required evidence and artifacts to retain

Keep an “exercise evidence pack” per exercise plus programme-level artifacts.

Programme-level artifacts

• Exercise Programme Standard / procedure
• Multi-exercise schedule with planned intervals
• Roles and responsibilities (RACI)
• Template set (scenario template, observer notes, after-action report, issues log)

Per-exercise evidence pack

• Approved exercise plan (objectives, scope, scenario, success criteria)
• Attendance record
• Observer notes and decision log
• After-action report (what worked, what didn’t, prioritized improvements)
• Issues/corrective actions with owners, dates, closure evidence
• Updated plan/runbook version history showing incorporation of lessons learned

Retention should align to your management system document control rules; auditors will mainly test that evidence is complete, controlled, and retrievable.

Common exam/audit questions and hangups

Expect these questions:

• “Show me your exercise programme and how you decide what to test.”
• “Where is the schedule, and did you execute to it?”
• “How do you know exercises tested procedures rather than general awareness?”
• “Show corrective actions from the last exercise and proof they were implemented.”
• “How do third-party dependencies get exercised?”
• “How do you ensure lessons learned update the BC plans and training?”

Hangups that trigger nonconformities:

• No planned schedule, only informal intentions.
• Tabletop-only programme that never tests technical or operational procedures.
• Findings exist but are not tracked to closure.
• Plans updated without clear traceability to exercise results.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails Clause 8.5	Fix
“Annual test” with no programme governance	Looks like a one-off event	Publish a programme standard + schedule + reporting cadence
Testing scenarios without referencing procedures	Doesn’t prove procedures work	Tie exercise objectives to runbook steps; require observers
No third-party participation	Misses real recovery dependencies	Include third-party contact/escalation steps; document outcomes
After-action report has generic statements	Weak evidence and no actionability	Write findings as testable gaps with owners and verification
Corrective actions closed without proof	Auditors treat closure as unverified	Require closure artifacts and a verification step (review or re-test)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is operational: weak exercising causes false confidence, extended outages, unsafe workarounds, and broken communications under stress. From a governance lens, failure patterns usually show up as repeat findings, inability to produce evidence, and plans that drift away from actual operations.

Practical 30/60/90-day execution plan

Days 0–30: Stand up the programme mechanics

• Assign accountable owner and approvers for the exercise programme.
• Publish the Exercise Programme Standard and evidence templates.
• Inventory critical processes/systems and key third-party dependencies to prioritize exercise scope.
• Draft and approve the exercise schedule for the next cycle.
• Run one “pilot” tabletop focused on a single critical process to validate templates and evidence capture.

Days 31–60: Execute and prove the control works

• Run additional exercises across different scopes (one business process, one technology/service recovery, one communications drill).
• Start an issues log and route corrective actions through your existing GRC workflow where possible.
• Report results and remediation status to governance.
• Update BC plans/runbooks where gaps were found; capture document control evidence.

Days 61–90: Mature realism and close the loop

• Re-test one high-risk gap after remediation (targeted re-exercise).
• Expand exercises to include third-party touchpoints (escalations, joint call, dependency validation).
• Establish a repeatable reporting pack (completion status, findings, closure).
• Confirm that training/briefings reflect updated procedures.

If you want to run this with less manual coordination, Daydream can hold the exercise schedule, evidence packs, and corrective actions in one place, then generate an audit-ready trail from exercise results to plan updates and issue closure.

Frequently Asked Questions

What counts as an “exercise programme” versus a single BC test?

A programme has defined rules, a planned schedule, documented execution, and a corrective-action loop. A single test event can be part of the programme, but it does not satisfy Clause 8.5 by itself. ¹

Do we have to run full-scale failovers to meet ISO 22301 Clause 8.5?

Clause 8.5 requires testing procedures at planned intervals, but it does not prescribe a specific exercise type. Use a mix of tabletops, simulations, and technical tests that match your risk and dependencies, then document why. ¹

How do we show auditors that we tested “procedures” and not just general awareness?

Tie exercise objectives to named runbooks/plan sections and capture observer notes that reference specific steps executed. Keep objective evidence such as tickets, screenshots, and communications drafts in the evidence pack.

What evidence is most often missing in audits?

Teams often miss the planned schedule, clear success criteria, and closure evidence for corrective actions. Auditors also look for plan updates that clearly trace back to exercise findings.

How should third parties be included in the exercise programme?

Include third-party escalation steps in scenarios and, where feasible, perform at least some joint coordination (calls, ticket escalation, restoration validation). Retain evidence of the interaction and the outcome in the exercise pack.

Can we centralize this in our existing GRC tool, or do we need a dedicated BC platform?

Either can work if you can schedule exercises, store evidence packs with document control, and track corrective actions to verified closure. The deciding factor is whether you can produce a clean audit trail quickly.

Footnotes

1. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements