Management review inputs

ISO 22301 Clause 9.3.2 requires you to bring a defined set of inputs into each BCMS management review so top management can make informed decisions and drive corrective action. Operationalize it by running a repeatable “management review input pack” process: collect required data, validate it, summarize trends, and present decisions and action items with owners and due dates. ¹

Key takeaways:

• Your management review agenda must explicitly cover each required input category, not a generic “BC update.”
• Evidence is the input pack plus proof that prior actions were tracked to closure and decisions were made.
• Most audit findings come from missing trend analysis, missing issue-change analysis, or poor action tracking.

Management review is where a Business Continuity Management System (BCMS) either becomes a controlled system that improves, or a set of documents that drift. Clause 9.3.2 is narrow but unforgiving: you must feed management review with specific inputs so leadership can assess performance, address nonconformities, and approve improvements. The standard is not asking you to “talk about continuity.” It is asking you to prove that review decisions were made using complete information: prior review actions, internal/external changes, performance data (including monitoring and measurement), audit results, progress against objectives, and improvement opportunities. ¹

For a CCO, GRC lead, or continuity owner, the fastest path is to productize the requirement into a single recurring deliverable: a management review input pack with named data owners, a cutoff date, a validation step, and a decision log. Once you can produce that pack on demand, audits get easier and the BCMS stops depending on institutional memory.

Regulatory text

Requirement (excerpt): “The review shall consider actions from previous reviews, changes in issues, BCMS performance, nonconformities, audit results, and improvement opportunities.” ¹

What the operator must do: For every scheduled management review, you must (1) gather information that covers each required input area, (2) present it in a way management can evaluate effectiveness and decide actions, and (3) retain documented information showing the inputs were considered and what decisions/actions resulted. The easiest audit-proof method is a standardized agenda mapped 1:1 to Clause 9.3.2 plus an attached input pack and action log.

Plain-English interpretation (what auditors expect)

Auditors are looking for completeness and follow-through:

• Completeness: Every management review includes all required inputs, even when there is “nothing new.” If nothing changed, your pack should say “no material change” and show how you checked.
• Performance-based review: You provide performance information (monitoring/measurement, trends, objectives) in a way that supports decisions, not raw data dumps.
• Closed-loop management: Actions from the prior review are tracked, escalated when overdue, and either closed with evidence or formally re-scoped with approval. ¹

Who it applies to

Entities: Any organization implementing or certifying to ISO 22301. ¹

Operational context: This hits teams responsible for BCMS governance: business continuity, operational resilience, enterprise risk, compliance, internal audit, and business owners who own BC objectives. It also touches third parties indirectly: changes in third-party dependencies and continuity performance often belong in “changes in issues” and “BCMS performance.”

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

1) Define your “management review input pack” template

Create a single template with sections that exactly mirror the required inputs:

1. Actions from previous management reviews
2. Changes in internal and external issues (your “context” changes)
3. BCMS performance
   • monitoring and measurement results
   • trends in nonconformities
   • audit findings summary
   • fulfillment/progress of BC objectives
4. Nonconformities and corrective actions (status and trends)
5. Audit results (internal and external, if applicable)
6. Opportunities for improvement (OFIs, lessons learned, program roadmap) ¹

Practical tip: add an “Executive decisions needed” box at the front. It forces the pack to be decision-grade.

2) Assign data owners and a cutoff date

For each input section, assign an accountable owner and specify where the data comes from (system/report). Example ownership model:

• Prior actions: BCMS coordinator or GRC PMO (action log)
• Internal/external issues: ERM, compliance, security, procurement (context register, risk register, regulatory change log, third-party changes)
• Performance and objectives: BC program owner + business owners (KPIs, exercise results, BIA updates, objective tracking)
• Nonconformities: quality/GRC (NCR log, corrective action tracker)
• Audits: internal audit/compliance (audit reports, finding tracker)
• Improvements: BC steering committee inputs, after-action reviews ¹

3) Collect, validate, and summarize (don’t just attach files)

Run a short validation step before the meeting:

• Reconcile action status against evidence (closure notes, approvals, test results).
• Check completeness: every required section present, even if “no updates.”
• Summarize trends: what is getting better/worse, where you are stuck, and why.
• Call out threshold breaches: missed exercises, overdue corrective actions, untested critical processes, or unreviewed third-party dependencies (if those are part of your BCMS scope). ¹

Output should be a tight narrative plus an appendix of source reports.

4) Run the management review meeting with a mapped agenda

Use an agenda that mirrors your pack. For each section, capture:

• what was reviewed,
• what decisions were made,
• what actions were assigned (owner, due date, success criteria),
• what risks were accepted (and by whom, if applicable to your governance). ¹

5) Document results and feed them back into the BCMS

After the meeting:

• Update the action log.
• Open corrective actions for systemic issues (repeat findings, recurring exercise failures).
• Update objectives or resources if management approved changes.
• Capture improvement items and route them into your BCMS plan/backlog. ¹

6) Make it repeatable (automation and tooling)

If your inputs live across GRC, ticketing, audit, and continuity tools, manual assembly becomes the failure point. Many teams centralize this in a GRC workflow so each input has an owner, due date, and evidence attachment. If you use Daydream, treat the “management review input pack” as a recurring workflow with mandatory fields for each Clause 9.3.2 input and an exportable pack for auditors.

Required evidence and artifacts to retain

Keep artifacts in an audit-ready folder (or GRC record) per review cycle:

• Management review agenda mapped to required inputs (Clause 9.3.2 categories)
• The final management review input pack (versioned)
• Source reports used (monitoring/measurement outputs, objective status, exercise summaries, NCR log extract, audit summaries)
• Meeting minutes or decision record
• Action log showing:
  • prior actions reviewed,
  • current actions assigned,
  • closure evidence for completed actions
• Any approvals for scope, objectives, resources, or risk acceptance linked to BCMS topics ¹

Common exam/audit questions and hangups

Auditors and cert bodies tend to probe these areas:

• “Show me where you considered actions from the last review. What was overdue and what did management decide?”
• “What changed in your internal/external issues since the last review, and how did that affect BCMS priorities?”
• “Show performance trends. Do you have recurring nonconformities? What is the root cause theme?”
• “How do audit results feed into management review, and how do you ensure corrective actions are effective?”
• “Which BC objectives were met, which were not, and what did management do about it?” ¹

Hangup: teams present raw KPIs without interpretation. Auditors want evidence that management reviewed, questioned, and decided.

Frequent implementation mistakes (and how to avoid them)

1. Generic minutes with no mapped inputs
   Fix: Use a structured template with explicit headings matching Clause 9.3.2.

2. No “changes in issues” analysis
   Fix: Maintain a simple context-change log (internal reorganizations, major tech changes, third-party dependency shifts, new regulatory expectations) and summarize deltas each cycle.

3. Treating audits and nonconformities as separate governance
   Fix: Bring audit themes and NCR trends into the review and tie them to resourcing or priority changes.

4. Action logs that don’t close the loop
   Fix: Require closure evidence and management escalation when actions stall.

5. OFIs that never become work
   Fix: Convert improvement opportunities into a tracked backlog with ownership and a stated decision (approved, deferred, rejected with rationale). ¹

Risk implications (why this requirement matters operationally)

Missing inputs leads to predictable failure modes: the BCMS doesn’t track whether corrective actions work, the organization misses material changes (like new critical third-party dependencies), and management cannot justify resources or priorities. In a disruption, those gaps show up as untested assumptions, outdated recovery strategies, and repeated control failures that were visible in audits or exercises but never acted on. Clause 9.3.2 is a governance control that forces those issues to surface. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Draft the management review input pack template mapped to Clause 9.3.2. ¹
• Build or clean up the action log so prior-review actions can be shown with evidence.
• Identify input owners and where each data element lives (systems, reports, repositories).
• Run a dry-run pack assembly using last period’s data to expose gaps.

By 60 days (Near-term)

• Run one management review using the mapped agenda and input pack.
• Capture decisions and create a single decision/action register from the meeting.
• Add a “changes in issues” mini-process (monthly intake from ERM, procurement, security, and compliance).

By 90 days (Stabilize and scale)

• Standardize performance reporting (trend views for nonconformities, objective tracking, monitoring/measurement).
• Add quality checks: completeness review before distribution, version control, and evidence attachment rules.
• If tooling supports it, automate reminders, owner attestations, and pack generation (Daydream or your existing GRC/work management tool). ¹

Frequently Asked Questions

Do we need to include every input category even if nothing changed?

Yes. The review “shall consider” the specified inputs, so your pack should explicitly state “no material change” where applicable and show that you checked. ¹

What counts as “changes in issues” for management review inputs?

Treat this as changes to internal and external factors that affect BCMS outcomes, such as reorganizations, major technology shifts, new critical third-party dependencies, or changes in risk posture. Document the change and the BCMS impact assessment. ¹

Can internal audit results be handled in a separate forum instead of management review?

You can have a separate audit forum, but Clause 9.3.2 still requires audit results to be considered as part of management review inputs. Include at least a theme summary, status of key findings, and decisions/actions. ¹

What is the minimum evidence an auditor will ask for?

Expect to provide the agenda, the input pack, minutes/decision records, and an action log showing prior actions and new actions with owners and closure evidence. ¹

How do we show “BCMS performance” without drowning leadership in metrics?

Provide a short dashboard that ties monitoring/measurement, nonconformity trends, audit themes, and objective progress to decisions needed. Put raw reports in an appendix. ¹

What if management review identifies improvements but leadership won’t fund them?

Record the improvement opportunity, the decision (approved/declined/deferred), and the rationale. Auditors mainly look for a controlled decision process and follow-through on agreed actions. ¹

Footnotes

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