Renata Cole had eleven months invested in Halyard Logistics' ISMS by the time the Stage 2 auditor asked to see minutes from the last management review. She pulled up a calendar invite titled "ISMS Review — Q3," attached to a twenty-two-minute recording and a one-page set of notes that read, in full: "Reviewed ISMS. No major issues. Continue as planned. — R. Cole."
The auditor, a soft-spoken but relentless lead assessor named Marcus Webb, asked three follow-up questions Renata couldn't answer from that page. What was the status of the four corrective actions opened after the internal audit in April? Had anyone reviewed whether Halyard's risk assessment still reflected the new AWS region it had stood up for a client in Frankfurt? What decision, specifically, had top management made about the two risks sitting above the accepted threshold on the risk register?
Renata didn't know. Nobody in the room that day had known, because nobody had prepared those inputs — the meeting had been a twenty-two-minute status update dressed up as governance. Webb raised it as a major nonconformity against Clause 9.3, not because Halyard had skipped the meeting, but because the meeting hadn't done what Clause 9.3 actually requires a management review to do. Halyard's biggest prospective customer, a regional grocery chain worth roughly $340,000 in annual recurring revenue, had made ISO 27001 certification a signed contractual condition with a hard deadline six weeks out. The nonconformity meant a corrective action plan, a follow-up visit, and a very uncomfortable conversation with the customer's procurement team about why the "final" certificate had slipped.
Halyard's mistake is the most common one I see in management review: treating it as a meeting to hold rather than a process to run. This article exists so you don't repeat it.
Who This Is For
This is the hands-on companion to the article on Clause 9 Performance Evaluation, written for the ISMS manager, CISO, or compliance lead who owns getting a conforming management review onto the calendar, staffed, and documented. You'll walk away with a ready-to-use agenda, a checklist mapped line-by-line to the seven inputs required by Clause 9.3.2, a table of the outputs an auditor expects to find recorded, and enough detail on minutes and evidence to survive a Stage 2 or surveillance audit without a scramble. If you've ever sat in a "management review" that was really just a status meeting with a fancier name, this is the fix.
What Clause 9.3 Actually Requires
Clause 9.3 is short — three subclauses, a page or so in the standard — but it is one of the most frequently cited sources of nonconformities I encounter in Stage 2 and surveillance audits, precisely because its brevity tempts organizations into treating it casually. The clause has three parts, and each one carries distinct obligations.
9.3.1 General states that top management shall review the organization's ISMS at planned intervals to ensure its continuing suitability, adequacy, and effectiveness. Three words matter here: suitability (does the ISMS still fit the organization as it exists today), adequacy (is it resourced and structured well enough to do its job), and effectiveness (is it actually achieving its intended outcomes — reducing risk, meeting objectives). A review that only asks "did we do the things on our checklist" answers none of those three questions.
9.3.2 Management review inputs lists what top management must consider — not what they're free to consider if time allows, but what the review must take into account. This is the section most audits probe hardest, because it's the easiest to shortcut and the easiest to verify was shortcut.
9.3.3 Management review results requires that the review produce decisions related to continual improvement opportunities and any need for changes to the ISMS, and that documented information be retained as evidence of the review's results. In plain terms: the meeting has to produce decisions, and you have to be able to prove it happened and what came out of it.
Subclause | What It Requires | Most Common Audit Gap |
|---|---|---|
9.3.1 General | Top management reviews the ISMS at planned intervals for continuing suitability, adequacy, effectiveness | No defined interval, or top management delegates the review entirely to IT/security staff |
9.3.2 Inputs | Seven specific categories of input must be considered (status of prior actions, changed issues, changed interested-party needs, performance feedback, interested-party feedback, risk assessment/treatment status, improvement opportunities) | One or two inputs addressed verbally; most inputs never actually assembled or presented |
9.3.3 Outputs | Decisions on continual improvement and ISMS changes; documented information retained as evidence | Minutes say "discussed" instead of recording an actual decision; no owner or due date attached to actions |
Nowhere in Clause 9.3 does ISO/IEC 27001:2022 specify a frequency. "Planned intervals" is deliberately flexible — the standard trusts the organization to set a cadence appropriate to its risk profile and rate of change, and then to actually keep to it. In practice, I tell every client the same thing: annual is the floor, not the target. An annual-only review means you're formally reconsidering your ISMS's suitability once every twelve months, which is a long time to run on autopilot in a fast-changing threat and technology environment. Most organizations I've worked with — particularly anyone in the SaaS, healthcare, or financial services space — land on quarterly reviews, sometimes with a lighter operational check-in monthly and one heavyweight annual review that rolls everything up.
Management Review Is Not a Status Meeting
The single most common structural failure I see is confusing the Clause 9.3 management review with the operational security meetings that should be feeding into it. Weekly vulnerability triage, monthly SOC stand-ups, quarterly steering committee check-ins on project status — these are valuable, sometimes essential, but they are not a substitute for the top-management review Clause 9.3 requires. Auditors distinguish between the two immediately, and conflating them is a fast route to a nonconformity.
Characteristic | Operational / Steering Meeting | Clause 9.3 Management Review |
|---|---|---|
Primary audience | Security team, IT operations, project owners | Top management (per ISO 27001's definition — the people who direct and control the organization at the highest level) |
Frequency | Weekly to monthly | Per planned interval — typically quarterly or annually |
Focus | Tactical execution: tickets, patches, incidents in progress | Strategic: is the ISMS still suitable, adequate, effective |
Inputs | Dashboards, open tickets, sprint status | The seven 9.3.2 inputs, consolidated and pre-read |
Outputs | Task reassignment, priority shifts | Documented decisions on ISMS change and improvement |
Documentation standard | Informal notes, ticket updates | Formal minutes retained as audit evidence |
Audit relevance | Supporting evidence only | Directly audited against Clause 9.3 |
Both meeting types matter, and in a well-run ISMS the operational meetings are exactly where the raw material for the management review gets generated — incident counts, audit findings, KPI trends. But if your organization's only governance touchpoint is the weekly security stand-up, you don't have a management review; you have operations with no strategic layer above it, and that's precisely the gap Halyard fell into.
Who Must Attend, and Why "Top Management" Is Not Optional
ISO/IEC 27001:2022 defines top management (a term worth bookmarking in the ISO 27001 glossary of terms alongside the standard's other precise vocabulary) as the person or group of people who directs and controls an organization at the highest level — for most of the mid-market organizations I work with, that's the CEO or Managing Director plus their direct reports who own resourcing and risk decisions, not delegated entirely to the CISO or IT manager. This matters because Clause 9.3.1 explicitly assigns the review to top management, and Clause 5 (Leadership) builds a broader expectation of visible, active engagement — a topic covered in depth in the Clause 5 leadership requirements article. An auditor who sees a management review chaired and attended solely by the ISMS manager, with no evidence that anyone with budget and resourcing authority was in the room, will ask hard questions about whether top management is actually exercising the oversight the standard requires.
That doesn't mean every review needs the full C-suite in the room for two hours. It means the people with authority to approve budget, accept risk, and change organizational priorities need to be present for the decisions — even if supporting staff carry the preparation and presentation load.
Role | Required Attendance | Typical Contribution |
|---|---|---|
CEO / Managing Director (or delegate with equivalent authority) | Mandatory — top management representative | Chairs or co-chairs; makes/ratifies final risk-acceptance and resourcing decisions |
CISO / Information Security Manager | Mandatory | Prepares and presents the consolidated inputs; proposes recommendations |
ISMS Manager / Compliance Lead (if distinct role) | Mandatory | Owns the agenda, minutes, and action tracking |
Head of IT / Engineering | Strongly recommended | Speaks to technical risk status, vulnerability and patching trends |
Head of HR | Recommended, at least annually | Speaks to people-control status (training completion, screening, terminations) |
Legal / DPO / Privacy Lead | Recommended, especially where PII is in scope | Speaks to regulatory and interested-party changes |
Internal Audit Lead | Mandatory for the review that follows an internal audit cycle | Presents audit findings and open corrective actions |
Risk Owners (rotating, as relevant) | As needed for specific high risks under discussion | Speaks to specific risk treatment status |
For organizations building out formal accountability structures, this attendance table maps closely onto the broader exercise described in the article on building a security RACI for roles and responsibilities — management review attendance should follow the same logic of "who is accountable, who is consulted."
Setting the Cadence: How Often Is "Planned Intervals"
Because ISO 27001 deliberately doesn't fix a number, I get asked constantly what the "right" frequency is. The honest answer is that it depends on how fast your risk environment, headcount, and technology stack change — but there are patterns I've seen hold up across 200-plus implementations.
Organization Profile | Common Cadence | Rationale |
|---|---|---|
Small business, stable environment, <50 employees | Annual, with a lightweight interim check at 6 months | Low rate of change; full quarterly cycle would be disproportionate overhead |
Startup / high-growth SaaS | Quarterly | Rapid headcount, infrastructure, and product change; risk landscape shifts materially between quarters |
Mid-market (100–1,000 employees), single ISMS scope | Quarterly | Balances governance rigor with meeting fatigue; aligns well with quarterly board reporting cycles |
Enterprise / multi-site / multiple ISMS scopes | Quarterly local reviews rolling up to a semi-annual or annual executive review | Local operational detail needs frequent attention; executive bandwidth is scarcer |
Regulated industries (healthcare, financial services) | Quarterly, often aligned to existing risk or audit committee cycles | Regulatory expectations and existing governance rhythms often already demand this cadence |
Whatever cadence you choose, the standard's expectation is that it's planned — meaning documented in your ISMS procedures, not decided ad hoc each time the CISO feels nervous before an audit. I ask every client to write the interval into their management review procedure or ISMS manual, along with a fallback rule: if a material change happens outside the planned interval — a breach, a major acquisition, a new regulatory obligation — an unscheduled review is triggered rather than waiting for the next slot.
"The question I ask every client in year one isn't 'how often should we meet' — it's 'what would make us call an emergency review.' If the answer is 'nothing, we just wait for the quarterly slot,' that's a maturity gap, not a scheduling choice." — Dana Osei, ISMS Manager, Clearbrook Financial
The Seven Required Inputs (Clause 9.3.2)
This is the section of the standard that separates a real management review from a rubber stamp. Clause 9.3.2 lists seven categories of input that top management "shall" consider. Not "may find useful" — shall consider. Auditors will ask for evidence that each one was actually assembled and presented, not just that the meeting happened. I've built the checklist below in the exact order the standard presents them, because I've found teams that follow this order rarely miss one.
# | Required Input (9.3.2) | Typical Source | Who Prepares It | Evidence an Auditor Will Ask For |
|---|---|---|---|---|
a | Status of actions from previous management reviews | Prior meeting minutes and action log | ISMS Manager | Action tracker showing each prior action's status (open/closed/overdue) with owner and date |
b | Changes in external and internal issues relevant to the ISMS | Clause 4 context analysis, business change log | ISMS Manager, with input from leadership | Updated context-of-the-organization document or a change log referencing new issues since the last review |
c | Changes in needs and expectations of interested parties | Interested-party register, contract reviews, regulatory tracking | Compliance Lead / Legal | Updated interested-party register or a summary of new/changed requirements |
d | Feedback on information security performance, including nonconformities and corrective actions, monitoring and measurement results, audit results, and fulfilment of information security objectives | Internal audit reports, NC/CA log, KPI dashboard, objectives tracker | CISO / Internal Audit Lead | Internal audit report(s), corrective action log, KPI trend data, objectives status table |
e | Feedback from interested parties | Customer security questionnaires, complaints, surveys, supplier feedback | CISO / Customer Success / Sales Engineering | Log of security-related customer feedback, complaint records, survey summaries |
f | Results of risk assessment and status of the risk treatment plan | Risk register, risk treatment plan | Risk Owner(s) / ISMS Manager | Current risk register extract, risk treatment plan status, any risks above appetite flagged for decision |
g | Opportunities for continual improvement | Consolidated from all of the above, plus staff suggestions, near-misses, industry trends | ISMS Manager, with contributions from attendees | Improvement log or backlog with proposed items and prioritization |
Two of these — feedback on information security performance (item d) and results of risk assessment (item f) — are almost always the ones organizations under-prepare, because they require pulling data from multiple systems rather than summarizing a single source. Item d, in particular, has four sub-components bundled into it (nonconformities and corrective actions; monitoring and measurement results; audit results; objectives fulfilment), and I routinely see reviews that address only one — usually just internal audit results — while treating the other three as implicit. An auditor who reads the standard closely will ask about all four separately.
For the risk assessment input (item f), the review needs to go beyond "the risk register is up to date." Top management should be shown, specifically, which risks currently sit above the organization's defined risk acceptance criteria, what treatment is planned or underway, and whether any risk needs an explicit acceptance decision from the room. This is where the review connects directly to the practices described in the ISO 27001 risk treatment plan guide and to the accountability model in risk owners and accountability.
"I tell clients: if your management review input for risk is a screenshot of the risk register, you haven't given top management anything to decide. Show them the three risks closest to the line and ask them, on the record, whether they accept, treat further, or transfer. That's the whole point of the meeting." — Marcus Webb, Lead Auditor, Northfield Assurance
Preparing the Inputs: A Realistic Timeline
Assembling seven inputs well takes longer than most first-time ISMS managers budget for. The table below reflects the prep cycle I recommend for a quarterly review; scale proportionally for annual-only cycles, but don't compress a full assembly into the final week regardless of frequency — that's exactly how inputs get reduced to a single slide with no real analysis behind it.
Timing Before Review | Activity | Owner |
|---|---|---|
3 weeks prior | Pull raw data: audit reports, NC/CA log, KPI dashboard, risk register extract, incident log, interested-party feedback | ISMS Manager, with data owners |
2 weeks prior | Draft consolidated inputs pack; flag any risks or decisions requiring top-management input | ISMS Manager |
10 days prior | Circulate draft pack to functional leads (IT, HR, Legal) for accuracy review and additions | ISMS Manager |
5 days prior | Finalize agenda and pre-read pack; send to all attendees, including top management | ISMS Manager |
2 days prior | Confirm attendance; pre-brief the chair on any contentious decisions expected | ISMS Manager / Chair |
Day of | Hold the review; capture minutes and decisions in real time | ISMS Manager (minute-taker) plus Chair |
Within 5 business days after | Distribute finalized minutes; open action items in tracker with owners and due dates | ISMS Manager |
A pre-read pack matters more than most teams expect. Reviews that open with the CISO presenting forty slides of raw data for the first time rarely produce real decisions — attendees are too busy absorbing information to deliberate. Circulating the inputs pack five business days ahead, with a one-page executive summary up front, consistently produces sharper, faster, better-documented decisions in the room itself.
A Ready-to-Use Management Review Agenda
Below is the agenda template I hand to clients as a starting point — built to move through all seven required inputs, land on documented outputs, and fit inside 90 minutes for a well-prepared quarterly review (budget 2–2.5 hours for the annual deep-dive version, or the first review of a new ISMS).
Time | Agenda Item | Maps to 9.3.2 Input | Led By |
|---|---|---|---|
0:00–0:05 | Welcome, quorum confirmation, approval of previous minutes | — | Chair |
0:05–0:15 | Status of actions from previous management review | (a) Status of previous actions | ISMS Manager |
0:15–0:25 | Changes in external and internal context since last review | (b) Changed issues | ISMS Manager / Leadership |
0:25–0:35 | Changes in interested-party needs and expectations | (c) Changed interested-party needs | Compliance Lead / Legal |
0:35–0:55 | Information security performance: audit results, NC/CA status, KPIs, objectives fulfilment | (d) Performance feedback | CISO / Internal Audit Lead |
0:55–1:05 | Feedback from interested parties (customers, suppliers, regulators) | (e) Interested-party feedback | CISO / Customer-facing lead |
1:05–1:20 | Risk assessment results and risk treatment plan status; decisions required on risks near/above appetite | (f) Risk assessment & treatment status | Risk Owner(s) / ISMS Manager |
1:20–1:30 | Opportunities for continual improvement | (g) Improvement opportunities | ISMS Manager, open floor |
1:30–1:45 | Decisions: ISMS changes, resource allocation, risk acceptance, improvement priorities | Output — 9.3.3 | Chair (top management) |
1:45–1:50 | Confirm action owners, due dates, and next review date | Output — 9.3.3 | ISMS Manager |
1:50–1:55 | AOB and close | — | Chair |
Notice that the last twenty minutes of the agenda are reserved explicitly for decisions, separate from the input presentations. This is a deliberate structural choice, not padding. When decision-making is folded into each input's discussion time, it's easy for a room to nod along to a status update without ever formally deciding anything — which is exactly the failure mode that got Halyard Logistics its nonconformity. Separating "here's the information" from "here's what we're deciding" forces the room to produce an actual output.
How Inputs Flow to Outputs
flowchart LR
A1["Status of prior actions"] --> R["Management Review Meeting\n(Top Management)"]
A2["Changed external/internal issues"] --> R
A3["Changed interested-party needs"] --> R
A4["IS performance feedback\n(NC/CA, KPIs, audits, objectives)"] --> R
A5["Interested-party feedback"] --> R
A6["Risk assessment & treatment status"] --> R
A7["Improvement opportunities"] --> R
R --> O1["Decisions on ISMS changes"]
R --> O2["Decisions on improvement opportunities"]
R --> O3["Risk acceptance / treatment decisions"]
R --> O4["Resource allocation decisions"]
O1 --> C["Documented Minutes\n(Evidence of Results)"]
O2 --> C
O3 --> C
O4 --> C
C --> T["Action Tracker"]
T --> N["Continual Improvement Cycle\n(feeds next review's Input a)"]
N -.-> RThe loop matters as much as the meeting. Every output becomes an input to the next review — decisions on ISMS changes and improvement opportunities get tracked to closure, and their status becomes item (a) on the following agenda. This is where Clause 9.3 hands off directly to Clause 10 Improvement: a management review decision to pursue further treatment or address a nonconformity should flow into the same corrective-action mechanism the standard requires for any other nonconformity, complete with a root cause analysis where the underlying cause isn't already obvious. A management review that doesn't close this loop is really just a series of disconnected status updates, which is precisely what auditors are trained to spot when they compare minutes across two or three consecutive cycles and find the same "open" action sitting untouched.
The Required Outputs: What Decisions Must Come Out of the Room
Clause 9.3.3 is deliberately narrower than 9.3.2 — it doesn't prescribe a long list of output categories, but it does require that the review result in actual decisions on two things: continual improvement opportunities, and any need for changes to the ISMS. In practice, those two categories expand into several recurring decision types I see come out of well-run reviews.
Output Category | What It Looks Like in Practice | Example |
|---|---|---|
Decisions on continual improvement opportunities | Prioritized list of improvements approved, deferred, or rejected, with rationale | Approve automating quarterly access reviews; defer SIEM upgrade to next fiscal year |
Decisions on ISMS changes | Changes to scope, policies, risk methodology, or organizational structure | Expand ISMS scope to include the new Frankfurt AWS region; revise risk acceptance criteria |
Risk acceptance or treatment decisions | Formal acceptance of residual risk, or direction to pursue further treatment | Top management formally accepts residual risk on legacy ERP pending Q3 migration |
Resource allocation decisions | Budget or headcount approved to close gaps identified in the inputs | Approve budget for a second penetration test and a compliance analyst hire |
Objective revisions | Updates to information security objectives based on performance data | Revise phishing-simulation click-rate objective from 8% to 5% given current 6.2% baseline |
Policy or procedure change directives | Instructions to update specific documented information | Direct HR to revise the remote-working policy following the interested-party feedback review |
Confirmation of next review date and scope | Explicit scheduling of the next planned interval | Next quarterly review confirmed for the second week of October |
The critical discipline here is specificity. "Discussed risk register, no changes needed" is not a decision an auditor can verify — it's a summary of inaction. "Top management reviewed the three risks above appetite (R-014, R-022, R-031); R-014 accepted with CFO sign-off, R-022 and R-031 assigned to IT Director for additional treatment by 30 September" is a decision, with an owner and a date, that any auditor can trace forward to the next review's status-of-actions input.
"An auditor doesn't read your minutes looking for eloquence. We're looking for a verb with an owner attached to it. 'Approved,' 'accepted,' 'rejected,' 'assigned' — those are decisions. 'Discussed' and 'noted' are not." — Elena Kowalski, Quality & Compliance Director, Arden Biotech
Minutes and Documented Evidence
Clause 9.3.3's requirement to retain documented information as evidence of the review's results is where I see the most avoidable nonconformities, because fixing it costs nothing but discipline. Minutes don't need to be elaborate; they need to be complete, traceable, and consistent across cycles. Below is the structure I recommend, built to satisfy both the standard and the practical needs of continuity between reviews.
Minutes Section | Required Content | Why It Matters to Auditors |
|---|---|---|
Header | Date, location/platform, meeting type, ISMS scope covered | Confirms this was the planned-interval top-management review, not an informal chat |
Attendance | Full names and roles of attendees; note any required roles absent and why | Verifies top management actually participated |
Status of previous actions | Each prior action listed with current status (closed/open/overdue) | Directly evidences input (a) |
Input summary per 9.3.2 item | Brief summary of what was presented for each of the seven inputs, referencing the source documents | Evidences all inputs were considered, not just discussed informally |
Decisions log | Each decision recorded as a discrete line: decision, owner, due date | Evidences the 9.3.3 outputs |
Action tracker extract or reference | Link or attachment to the live action tracker reflecting new items | Shows the loop closes into ongoing tracking |
Next review date | Confirmed date/interval for the next planned review | Evidences "planned intervals" per 9.3.1 |
Sign-off | Chair (top management representative) confirmation, dated | Confirms top management ownership of the outcome |
I recommend retaining minutes for at least the full three-year certification cycle, and ideally longer where contractual or regulatory retention requirements apply — this dovetails with the broader records-retention approach covered in ISO 27001 document control and records management, and with the way Statement of Applicability revisions should be version-controlled and cross-referenced back to the review decision that triggered them.
One evidentiary trap worth naming explicitly: auditors increasingly compare consecutive management review minutes side by side. If the same risk, the same open action, or the same "opportunity for improvement" appears verbatim across three consecutive cycles with no visible progress, that's read as evidence the review isn't actually driving change — even if each individual meeting was well-documented. Minutes need to show a trajectory, not just a snapshot.
What Good Minutes Actually Look Like
Because "decisions, not summaries" is easier to state as a principle than to apply under time pressure, it helps to see the difference in practice. Below is a side-by-side of the same agenda item, minuted two ways — the version that generates an auditor's follow-up question, and the version that closes the topic.
Weak Minute (Reads as a Summary) | Strong Minute (Reads as a Decision) |
|---|---|
"Discussed the risk register. Group agreed things looked reasonable overall." | "Risk register reviewed (v4.2, dated 3 July). Three risks above appetite presented: R-014 (legacy ERP), R-022 (contractor VPN access), R-031 (unpatched line-of-business app). Decision: R-014 accepted by CFO pending Q3 migration (owner: J. Alvarez, review date 30 Sept). R-022 and R-031 assigned to IT Director for additional treatment, due 15 Sept." |
"Reviewed audit findings, no major concerns." | "Internal audit report (ref IA-2026-02) presented: 2 minor nonconformities, 1 observation. NC-1 (access review evidence gap) assigned to HR Ops, due 20 Aug. NC-2 (logging retention below policy) assigned to Infrastructure, due 5 Sept. Both accepted as valid findings by the review; no dispute raised." |
"Talked about training completion, seemed fine." | "Security awareness training completion at 94% (target 95%). Decision: extend deadline by two weeks for remaining 6% and escalate non-completion to line managers; HR to report completion status again at next review." |
Notice the pattern: the strong version names a specific document or data point, records a specific decision with a verb, and assigns an owner and date. None of this requires more time in the room — it requires the minute-taker to capture the decision as it's made rather than paraphrasing the discussion afterward. I typically recommend the ISMS manager read each decision back to the room before moving on, precisely so the wording that ends up in the minutes matches what was actually agreed.
What Auditors Actually Check
Audit Check | What "Pass" Looks Like | What Triggers a Finding |
|---|---|---|
Interval adherence | Reviews occur at the documented planned interval, evidenced by dated minutes | Gaps longer than the defined interval, or reviews skipped without an unscheduled review triggered by a material change |
Attendee authority | Top management (as defined by the organization) is present and actively participating | Review chaired and attended solely by IT/security staff with no resourcing authority |
All seven inputs present | Each 9.3.2 item traceable to specific evidence referenced in the minutes | One or more inputs missing entirely, or addressed as a single unsupported bullet point |
Decisions, not summaries | Minutes record discrete decisions with owners and dates | Minutes read as a narrative summary with no identifiable decisions |
Traceability to action tracker | Decisions map to tracked actions with status visible at the next review | Decisions exist in minutes but never appear in any tracking system afterward |
Evidence retention | Minutes, pre-read packs, and supporting data retained and retrievable | Minutes exist but supporting inputs (audit reports, KPI data) cannot be produced on request |
Making It Meaningful, Not Theatre
I've sat in management reviews that were technically compliant and functionally useless — every box on the auditor's checklist ticked, every input present in a slide deck, and yet nothing in the room actually changed as a result. This is the failure mode that worries me more than outright nonconformity, because it passes audits while providing none of the governance value the standard is designed to produce.
The tell is usually pacing. A review that races through forty-five minutes of status updates and then spends four minutes on "any decisions" has its priorities backwards. I coach clients to flip the ratio: the input presentations should be tight, pre-read, and summarized in no more than two minutes of live airtime each, freeing the majority of the room's time for actual deliberation — debating whether a risk should be accepted, whether a control needs more investment, whether an objective is still the right one to chase.
A second tell is whether top management asks questions. In a genuinely engaged review, the CEO or equivalent pushes back on at least one item — questions why a corrective action is still open after two cycles, or asks whether the proposed risk treatment budget is proportionate to the exposure. If every review concludes with unanimous, immediate agreement on everything presented, it's worth asking honestly whether the room is actually evaluating the ISMS or simply approving whatever the CISO recommends. Both patterns can produce clean minutes; only one produces genuine oversight.
"The best management reviews I've chaired felt slightly uncomfortable. Someone asked why we were still accepting a risk we'd said we'd treat two quarters ago. That discomfort is the entire point — it means the room is actually governing, not just attending." — Raj Patel, CEO, Fenwick Cloud Systems
Practical techniques that consistently improve substance over theatre: rotate who presents each input so it isn't always the CISO narrating their own homework; require at least one input each cycle to come with a explicit recommendation and a dissenting view considered; and close every review by asking the room directly, "what would make next quarter's review harder than this one" — a question that tends to surface risks nobody wanted to volunteer.
Small Organization vs Large Organization Approach
The mechanics of Clause 9.3 don't change based on headcount, but the shape of the meeting should. A twenty-person startup running its first ISMS and a 3,000-employee enterprise with five business units need structurally different approaches to hit the same requirements without either wasting time or missing rigor.
Dimension | Small Organization (<100 employees, single site) | Large / Multi-Site Organization |
|---|---|---|
Attendee count | 3–6 (often the whole leadership team) | 8–15, with rotating specialist contributors |
Structure | Single review covering the whole ISMS | Local/business-unit reviews rolling up into a consolidated executive review |
Cadence | Annual or semi-annual, sometimes quarterly for regulated sectors | Quarterly at each level; annual executive deep-dive |
Input consolidation effort | Low — one risk register, one audit program, one KPI set | High — inputs must be normalized across units before the executive review |
Common integration point | Standalone ISMS meeting | Folded into existing risk committee, audit committee, or board risk subcommittee |
Typical failure mode | Meeting held too informally to produce documented evidence | Executive review becomes too high-level to surface real decisions; local detail gets lost |
Governance strength | Easier to keep genuinely engaged (small room, direct stakes) | Requires deliberate design to avoid the review becoming ceremonial |
For small organizations, my consistent advice is: don't over-engineer the process, but don't under-document it either. A 45-minute review with the founder and two department heads is entirely sufficient for a twenty-person company — as long as the seven inputs are genuinely assembled and the decisions are written down with the same rigor a larger company would apply.
For larger organizations, the risk runs the other way. The executive-level review often becomes a highlights reel, disconnected from the operational detail that actually matters. I recommend a two-tier structure: business-unit or regional reviews that go deep on their own risk registers and audit findings, feeding a structured summary — not a raw data dump — up to a quarterly or semi-annual executive review that focuses on cross-cutting risks, resource decisions, and ISMS-wide changes. This structure also tends to integrate cleanly with existing governance bodies (audit committees, enterprise risk committees) rather than requiring a brand-new meeting series that competes for calendar space.
Common Mistakes
Across the reviews I've audited or remediated, the same handful of mistakes account for the overwhelming majority of Clause 9.3 findings.
Mistake | Why It Happens | Consequence | Fix |
|---|---|---|---|
Treating it as a status meeting | Easier to prepare a status update than a decision-ready inputs pack | Nonconformity for missing 9.3.2 inputs or 9.3.3 outputs | Rebuild the agenda around the seven required inputs and a dedicated decisions block |
Top management not genuinely present | Delegated to CISO/IT as "their compliance thing" | Nonconformity or major finding on Clause 9.3.1/Clause 5 | Calendar-block the CEO/equivalent; frame the review as a governance obligation, not an IT meeting |
No pre-read pack | Time pressure before the meeting | Rushed, shallow decisions; attendees disengaged | Circulate a concise pack 5 business days ahead |
Minutes record discussion, not decisions | Minute-takers default to narrative summary | Auditor cannot verify 9.3.3 outputs | Use a decisions-log format: decision / owner / date, separate from narrative notes |
Same open action carried across 3+ cycles with no progress | No real accountability mechanism between reviews | Reads as evidence the review isn't driving change | Tie actions to the same tracker used for corrective actions; report status explicitly each cycle |
Risk assessment input reduced to "register is current" | Easier than presenting specific risks for decision | Top management never actually exercises risk acceptance authority | Present the risks nearest or above appetite explicitly, with a recommendation |
One-size review regardless of scale or change | Convenience; "we've always done it this way" | Under-governance in fast-changing orgs, over-ceremony in stable ones | Set cadence deliberately per the organization's rate of change, and add unscheduled reviews for material events |
No link between review outputs and objectives | Objectives owned separately from the review process | Objectives drift from what the ISMS is actually facing | Explicitly revisit objectives as part of the performance-feedback input each cycle |
Case Studies
Case Study 1: Halyard Logistics — From Nonconformity to Recovered Contract
Returning to Renata Cole's story: the major nonconformity gave Halyard Logistics a 90-day corrective action window before the customer's contractual deadline would be missed. Renata rebuilt the review process from the agenda in this article, ran a genuinely prepared review within three weeks (pulling the audit findings, KPI data, and a real risk-register extract for the first time), and produced eleven pages of minutes with fourteen discrete, owned decisions — including formal risk acceptance from the CFO on two risks that had been sitting unaddressed for two quarters. The follow-up audit visit closed the nonconformity in six weeks, four weeks ahead of the contractual deadline, and Halyard signed the $340,000 grocery-chain contract on schedule. The lasting change wasn't the paperwork — it was that the CEO now personally reviews the risk register summary before every quarterly review, something that had never happened before the finding.
Case Study 2: Corvis Analytics — Scaling Reviews with Headcount
Corvis Analytics, a 40-person SaaS analytics company at initial certification, ran its first two management reviews as a 30-minute conversation between the founder and the sole security engineer — technically covering the inputs, but thin on documented rationale. By the time Corvis reached 150 employees and was pursuing SOC 2 alongside ISO 27001 renewal, the same lightweight approach was producing minutes an auditor flagged as "insufficient evidence of the fulfilment of information security objectives" — input (d) had become too complex for a two-person conversation to cover credibly. Corvis restructured to a quarterly review with six standing attendees (CEO, CTO, Head of Customer Success, HR lead, and two security engineers presenting rotating inputs) and adopted the decisions-log minutes format. The next surveillance audit closed with zero findings against Clause 9.3, and the CTO reported that the review process directly drove a decision to fund a second penetration test after the risk-assessment input surfaced a gap the founder hadn't previously been shown.
Case Study 3: Bridgeport Health Network — Integrating Into Existing Governance
Bridgeport Health Network, a healthcare system with an existing enterprise risk committee, initially ran its ISMS management review as a fully separate meeting — creating calendar conflict and, within a year, executive attendance that had quietly dropped to a delegate rather than the required decision-makers. Bridgeport's compliance director restructured the ISMS review as a standing 45-minute agenda item within the existing quarterly risk committee, using the same agenda structure from this article but presented alongside the committee's other regulatory risk items. Attendance from genuine decision-makers went from roughly 40% to 100% of scheduled reviews, because the meeting was no longer competing for a separate calendar slot. The integration also strengthened Bridgeport's broader alignment story, since interested-party feedback from its HIPAA-driven obligations now sat naturally alongside its ISO 27001 review inputs rather than being tracked in a parallel process.
"Once we stopped asking executives to find a new meeting slot and started asking them to spend forty-five extra minutes in a meeting already on their calendar, attendance stopped being a fight." — Priya Nandakumar, Compliance Director, Bridgeport Health Network
The Time and Effort Investment, Realistically
Clients regularly underestimate how much preparation a genuinely conforming review takes, then overcorrect into believing it requires a full-time coordinator. Neither extreme is accurate. The table below reflects the effort I typically see once a review process is mature — the first one or two cycles for a new ISMS usually take 30–50% longer while templates and data pipelines are built out.
Activity | Small Org (Quarterly) | Mid/Large Org (Quarterly, Multi-Unit) |
|---|---|---|
Data pulling and consolidation | 3–5 hours | 15–25 hours (across contributing units) |
Drafting inputs pack | 2–4 hours | 8–12 hours |
Review meeting itself | 60–90 minutes | 90–150 minutes (local) + 60–90 minutes (executive roll-up) |
Minutes finalization and distribution | 1–2 hours | 4–6 hours |
Action tracker updates | 1 hour | 3–5 hours |
Total ISMS-manager effort per cycle | ~8–12 hours | ~35–50 hours |
This is a modest investment relative to the governance value it produces — and relative to the cost of a nonconformity remediation cycle, which routinely consumes far more staff time under audit pressure than a well-run review ever would. Halyard Logistics' remediation, from finding to closure, cost Renata roughly 60 hours of unplanned work compressed into three weeks — more than five of her normal quarterly review cycles combined.
Feeding Metrics Into the Review
The performance-feedback input (9.3.2 item d) is only as strong as the underlying measurement program behind it. Objectives fulfilment, monitoring and measurement results, and meaningful KPI trends all depend on having defined, tracked metrics well before the review date — a topic significant enough that it deserves its own treatment on ISO 27001 metrics and KPI selection (a piece we don't yet have live on the site, but plan to publish as a dedicated companion guide). Until then, the minimum viable metric set I recommend every organization bring into a management review includes: percentage of security objectives on track, number of open corrective actions by age, mean time to remediate critical vulnerabilities, security awareness training completion rate, and phishing simulation click/report rates. None of these need to be sophisticated dashboards in year one — a single spreadsheet trended quarter over quarter is enough to give top management something concrete to react to.
The Strategic Opportunity Hiding in a Compliance Requirement
It's easy to treat Clause 9.3 as a box to tick every quarter or year, and I understand the instinct — most organizations first encounter management review as an audit requirement, not as something they asked for. But every organization I've watched genuinely commit to running these reviews well has found the same thing on the other side: it's the only recurring forum where information security risk, business priorities, and resourcing decisions get discussed together, by the people with the authority to act on all three at once. That's not a compliance artifact. That's governance most organizations don't have anywhere else in their calendar.
The organizations that extract the most value from management review are the ones that stop asking "what do we need to show the auditor" and start asking "what do we need top management to actually decide this quarter." Halyard Logistics didn't just fix a nonconformity — it built the first forum where its CEO was routinely forced to engage with specific, named risks rather than a vague sense that "security is handled." Bridgeport Health Network didn't just improve attendance — it made information security a standing line item in the same conversation as its other enterprise risks, which is exactly where it belongs. That reframing, more than any single agenda template, is what turns Clause 9.3 from an audit line item into a genuine driver of a more resilient, better-resourced security program — and it's a story worth telling to customers, insurers, and boards who increasingly want evidence that security decisions are made deliberately, not by default.
Where to Go From Here
Before your next review, pressure-test your process against three questions: can you produce evidence for all seven 9.3.2 inputs, not just the easy ones; do your last three sets of minutes show decisions with owners and dates, or summaries of discussion; and is top management — genuinely, not by delegation — in the room making the calls. If any of those answers is uncomfortable, that discomfort is useful signal, not a reason to avoid the fix.
To build out the rest of your ISMS documentation alongside your management review process, PentesterWorld's ISO 27001 Mandatory Documents Checklist will help you confirm management review minutes sit correctly alongside every other required record, and the Internal Audit Report Template gives you a consistent format for the audit-results input your review depends on. If you're heading toward Stage 2 or a surveillance visit and want a broader sanity check before the assessor arrives, run through the Certification Readiness Checklist. And if you're building or refining your ISMS from the ground up, The Complete ISO 27001 Implementation Guide walks through where management review fits into the full certification journey, with the ISO 27001 Glossary of Terms on hand for any vocabulary that trips you up along the way.
A conforming management review isn't the hardest part of ISO 27001 — but it's one of the parts most likely to be quietly done wrong for years before an auditor finally asks the question Marcus Webb asked Renata Cole. Ask it of yourself first.