Prepare For the Worst with the Best in the Business
Experience capable, consistent, and easy-to-use business continuity management software.
A 30-day BCM readiness sprint is a temporary effort to bring the most important overdue continuity-plan reviews back under control. Over four weeks, the team builds one backlog, prioritizes plans by operational importance and change, completes focused reviews, routes decisions, and moves unfinished work into a dated maintenance queue.
The goal is not to claim that every plan can be fixed in 30 days. It is to complete the highest-priority work, document what remains, and restore a process the team can sustain.
Readiness sprint summary
- Use it when: Overdue reviews are scattered, ownership is unclear, or leadership needs a credible recovery plan for the backlog.
- Prioritize first: Plans supporting important operations that also have material changes, exercise findings, ownership gaps, or conflicting versions.
- Route elsewhere: BIA rework, recovery-strategy redesign, major testing, and crisis-governance decisions.
- Track separately: Reviews completed, plans approved, and plans deferred.
- End state: A smaller backlog, identifiable approved versions, and accountable work for every unresolved plan.
The sprint is editorial guidance, not an ISO, NIST, or regulatory requirement. ISO 22301:2019 describes a management system that includes monitoring, reviewing, maintaining, and continually improving business continuity. It does not prescribe a 30-day sprint. Each organization must set its own scope, frequency, authority, and evidence requirements.
Set the sprint scope and triage the backlog
The sprint will lose time if the team begins with competing spreadsheets or no shared definition of completion. Set the working rules before day one.
Build one review queue
Create one tracker containing every plan in sprint scope. Include:
- Plan name and supported business area
- Owner, reviewer, and approver
- Last approval date and version
- Known operational, organizational, technology, facility, or supplier changes
- Exercise findings that affect the plan
- Priority and reason
- Next action, due date, and blocker
- Link to the working plan and supporting record
Reconcile duplicates before assigning reviews. If two versions appear current, record that as a version-control issue rather than asking reviewers to choose informally.
Prioritize by operational importance and change
Age matters, but the oldest review is not automatically the most consequential. Start with plans that support high-priority operations and show another reason for concern.
| Priority | Conditions | Sprint action |
|---|---|---|
| First | High-priority operation plus material change, uncertain ownership, an applicable exercise finding, conflicting versions, or an approaching external deadline | Assign immediately and validate the affected sections first |
| Next | Important operation, overdue review, and no known material change | Confirm the no-change assumption, validate sensitive sections, and route the result |
| Then | Lower-priority scope with no known material change | Review if capacity remains, or schedule with a named owner and date |
| Separate workstream | New BIA, recovery-strategy redesign, major technology validation, unresolved policy decision, or crisis-team redesign | Record the dependency and route it to the appropriate owner |
Record the reason for each priority. This gives leadership a clearer explanation of why some overdue plans moved before others.
If the sprint exposes deeper questions about crisis-team membership or authority, move those questions outside the review sprint. MHA Consulting’s guidance on setting up a crisis management team addresses that strategic work.
Set capacity and defer rules
Estimate how many plans reviewers and approvers can examine properly within four work weeks. Include time for corrections and approval, not just the first review.
Move a plan out of the fast path when:
- The owner cannot confirm how the operation currently works.
- Recovery objectives require a new or updated BIA.
- A dependency or technology change requires testing.
- The recovery strategy is no longer feasible.
- Approval depends on a policy or risk decision outside the plan owner’s authority.
Deferral is not closure. Record the reason, accountable owner, required decision, and next date.
If the team closes easy reviews but leaves high-exposure plans unresolved, the backlog is smaller on paper, but the most consequential uncertainty remains.
Run the four-week readiness sprint
This schedule assumes four work weeks within a 30-calendar-day window. Adjust the dates for holidays, external deadlines, and approver availability while preserving the sequence.
| Week | Objective | Required outputs |
|---|---|---|
| 1 | Triage and assign | Reconciled backlog, priority reasons, owners, reviewers, approvers, dates, and defer flags |
| 2 | Conduct focused reviews | Material-change checks, reviewer input, required corrections, and escalated dependencies |
| 3 | Correct, decide, and approve | Completed changes, recorded dispositions, approvals where possible, and assigned open actions |
| 4 | Verify and transition | State check, sprint report, unresolved queue, maintenance dates, and governance handoff |
Week 1: Triage and assign
Use a short launch meeting with the people who can resolve ownership, priority, and approval questions. By the end of the week, every in-scope plan should have a next action, responsible person, and date. “Awaiting response” is incomplete unless the tracker also names whose response is required and when it will be escalated.
Week 2: Conduct focused reviews
Validate the plan elements most likely to have changed:
- Ownership, contacts, and escalation paths
- Critical procedures and decision points
- People, technology, facility, supplier, and information dependencies
- Recovery assumptions and required resources
- Related plans and documents
- Changes identified through incidents or exercises
Record who confirmed unchanged content and when. Silence is not confirmation.
NIST SP 800-34 Rev. 1 supports the underlying maintenance logic. It says contingency plans should be reviewed at an organization-defined frequency and when significant changes occur, with testing deficiencies addressed during maintenance. Its direct scope is federal information-system contingency planning, so treat it as informative guidance outside that context.
Include an exercise finding only when it requires a change to the plan under review. Route findings requiring a new exercise, strategy redesign, or investment decision into separate accountable work.
Week 3: Correct, decide, and approve
Give every reviewed plan one disposition:
- Ready for approval: Required corrections are complete and the plan can move to the authorized approver.
- Correct and resubmit: Identified changes must be completed before approval.
- Defer with accountable action: A material dependency prevents approval and has been routed to an owner with a decision or delivery date.
Record the disposition and decision maker. Do not describe a plan as approved because comments stopped arriving.
After approval, identify the approved version and clearly supersede prior working copies according to the organization’s records practices. NIST’s maintenance guidance supports coordinating changes, keeping a record of changes, and maintaining version control.
Week 4: Verify and transition
Check the state of every plan and prepare a concise closeout report showing:
- Reviews completed
- Plans approved
- Plans awaiting correction or approval
- Plans deferred and the reason
- Corrective actions opened or closed
- High-priority items still unresolved
- Decisions or resources required
- The next maintenance and governance dates
These counts describe workflow status. They do not prove that each recovery strategy will work during a disruption.
Separate completed reviews from approved plans
The sprint needs three distinct states. Combining them creates false closure.
| State | Definition | Evidence to retain |
|---|---|---|
| Review completed | The defined content was examined and a disposition was recorded | Review scope, owner, reviewer input, material-change check, disposition, and review date |
| Plan approved | Required corrections were completed and an authorized approver accepted an identifiable version | Approver, approval date, approved version, and documented limitations, if any |
| Plan deferred | A material dependency prevents approval and has been routed into accountable work | Reason, owner, required decision or deliverable, due date, and next review date |
A completed review can end in approval, correction, or deferral. Only the first outcome produces an approved plan. A previous approval also does not make a plan permanently current. Later changes can trigger another review.
A completed review is not automatically an approved plan. The team must record the disposition, identify the approved version when one exists, and control anything left open.
Move From Catch-Up to Measurable Progress
A sprint can bring overdue reviews under control. The next job is keeping plans, tests, measures, and evidence moving together. Use The BCM Readiness Guide: From Exercise to Evidence to plan that transition.
Keep the backlog from returning
For every unresolved item, set the next action, accountable owner, decision or due date, reason it remains open, consequence of further delay, and the management meeting where it will be reviewed.
Then retire the temporary sprint meetings and tracker, or fold the records into the system used for ongoing maintenance. Do not leave a parallel process running after the catch-up need has passed.
For the recurring process, use Plan Maintenance Without Burnout to set review triggers, attestations, and change control. Place the remaining work into the organization’s established governance cadence so status, decisions, and overdue actions stay visible.
Managing Reviews, Approvals, and Plan Versions in One Place
A small sprint can run with a spreadsheet and shared documents. The cost is manual reconciliation across plan links, versions, owners, comments, review status, approval status, and open work.
BCMMetrics' BCM Planner is the tool you need when that information is fragmented. BCM Planner supports uploading or building templates, creating and editing recovery plans, tracking plans through draft, review, complete, and approved statuses, storing and sharing plans, and recording exercise results.
The platform does not determine plan priority, decide whether a change is material, or set approval authority. Those remain governance decisions.
When evaluating the current workflow, ask:
- Can we produce one reliable view of plan status?
- Can reviewers find the current working version without asking the BCM team?
- Can we track plans from draft through review, completion, and approval?
- Can deferred work be recorded separately with an owner and date?
- Can exercise results be recorded and the resulting plan changes tracked?
- Can we retrieve the approved plan and supporting review record without rebuilding the history from email?
If several answers are no, the process problem is not limited to reviewer effort. The workflow is creating additional administrative work.
Take the next step
A readiness sprint will not solve every continuity weakness. It can give a limited team a defensible order of work, completed high-priority reviews, identifiable approved plans, and accountable treatment of everything that remains.
Download The BCM Readiness Guide: From Exercise to Evidence to connect the catch-up effort to current data, tested strategies, useful measures, and visible program progress.
Theron Long
Theron Long is responsible for supporting BCMMetrics' development and operations. Prior to taking on this role, Theron worked as a Consultant under one of MHA’s Senior Advisory Consultants where he had hands on experience in business continuity. He now uses that experience to further innovate BCMMetrics for our internal functions and subscribers alike. Theron has a bachelor’s degree in Technical Communication with a concentration in User Experience from Arizona State University.