Running a Management Review Under ISO 27001 Requirements

Running a Management Review Under ISO 27001 Requirements

The requirements and structure of Clause 9.3

Clause 9.3 of ISO/IEC 27001:2022 decides whether an information security management system is actually run by the people accountable for it, or just documented by the people implementing it. It's a short clause, barely a page once you strip out the sub-headings, but it carries audit weight out of proportion to its length. The 2022 revision took what used to be a single undivided block of text and split it into three distinct sub-clauses, each with its own obligations. Clause 9.3.1 sets the general requirement: top management has to review the ISMS at planned intervals to confirm it remains suitable, adequate, and effective.

That restructuring wasn't a formatting decision. It created three separately auditable obligations where previously there was one. An auditor working from the current standard can now fail an organization on the inputs alone, on the outputs alone, or on the general conduct of the review, rather than treating the whole thing as one loosely defined activity. That distinction matters because ISO 27001 is not a checklist of security controls: it's a specification for a management system, and Clause 9.3 is the point where that system has to prove, on paper, that it is actually being governed rather than merely maintained. 9.3.3 Management Review Results (what the review must produce as documented outputs)

Management review as a leadership obligation, not a security-team task

The review belongs to top management, full stop. It is not something the ISMS lead can run solo and then summarize for the executive team in a follow-up email. The standard's intent is specific here: it wants people in the room who can allocate budget, redirect headcount, and change organizational priorities, whether that's a CEO, a COO, or a board-level designee acting with that authority. A security manager presenting a slide deck to an empty conference room, then circulating minutes afterward, does not satisfy this requirement no matter how good the slide deck is.

At minimum, the room needs the information security manager, someone from senior leadership with actual authority, and representation from each department affected by the ISMS. Beyond that baseline, certain additional voices earn their seat for concrete reasons. Legal and compliance input matters because regulatory shifts, GDPR enforcement trends, NIS2 obligations, and sector-specific rules all need to appear in the ISMS risk picture rather than sitting in a separate compliance silo. IT and technical leads can speak to vulnerabilities and infrastructure changes with a level of detail no summary report captures. HR brings visibility into the human side of security controls: training completion rates, departing employees, disciplinary incidents tied to security policy. And where supply chain risk is material to the business, a supplier representative's presence turns third-party risk from an abstract line item into something with an actual name attached to it.

Factors driving the decision on review frequency

The standard says "planned intervals." It does not say quarterly, and it does not say annually. That vagueness is deliberate, and it puts the burden of justification on the organization rather than on the standard itself.

Most certification bodies treat annual reviews as the accepted floor. Anything less frequent invites scrutiny, but plenty of factors push organizations toward a tighter cycle. Size and complexity of the ISMS is one: a company running a handful of controls across one office looks nothing like one managing dozens of controls across multiple business units, and the review cadence should reflect that difference. An organization migrating infrastructure or launching new product lines generates risk faster than a stable one, so the pace of change in the business or IT environment is another driver. Nature of the business, level of risk tied to the information assets involved, and the track record of prior reviews all factor in too. A review that keeps surfacing a long list of unresolved action items is telling the organization something: the current interval is too slow to keep pace with what's actually happening. High-growth companies, or ones mid-transformation, often do better on a quarterly rhythm.

The seven mandatory inputs of Clause 9.3.2

Clause 9.3.2 doesn't offer suggestions. A general conversation about "how security is going" doesn't substitute for working through the list.

The first input is the status of actions from previous reviews. Open items need tracking to actual resolution. Auditors trace these across meetings deliberately: raise a training budget shortfall in one review, and the next one had better show a decision addressing it, not a repeat of the same complaint.

The second and third inputs both trace back to context analysis, but they're distinct. Input (b) covers changes in external and internal issues relevant to the ISMS, drawing on the Clause 4.1 context analysis: regulatory shifts, market changes, restructuring, new lines of business. This is also where the climate change determination introduced by Amendment 1:2024 lands, which gets its own treatment further down. Input (c) covers changes in the needs and expectations of interested parties, drawing on Clause 4.2. This one was added in the 2022 revision, and it's the input most likely to go missing from organizations still running an agenda structured around the 2013 version of the standard. Customer contractual requirements, regulator expectations, insurer demands, board-level asks: all of it belongs here.

Input (d) is feedback on information security performance, and the standard specifies it has to cover trends, not snapshots, across four areas: nonconformities and corrective actions, monitoring and measurement results (think staff training completion, mean time to patch, incident counts), audit results from both internal and external sources, and how well the organization is meeting its stated security objectives. The word "trends" in the clause text is not incidental. A single quarter's numbers with no comparison point tells top management almost nothing useful.

Input (e), feedback from interested parties, sounds close to input (c) but isn't the same thing. Input (c) is about changes in what parties expect. Input (e) is about feedback actually received: complaints, supplier assessments, correspondence from a regulator. Input (f) covers risk assessment results and the status of the risk treatment plan, and the practical move here is presenting a summary of the most critical risks with clear status markers, on track or delayed, and a named owner attached to anything that's slipping, rather than dumping the entire risk register on the table. Input (g), opportunities for continual improvement, closes the list. This one is proactive by design: identifying where the ISMS could get stronger before something forces the issue, distinct from corrective action, which only kicks in after a problem has already shown up.

Auditors go through the minutes against this exact list, item by item. Skip one, and it counts as a potential nonconformity regardless of how well the rest of the meeting went.

Amendment 1:2024 and the climate change question now inside Clause 9.3

Amendment 1:2024 to ISO/IEC 27001:2022 was published in February 2024, and it added one new requirement to Clause 4.1: organizations have to decide if climate change is a relevant issue. It also added a note to Clause 4.2 making clear that interested parties can hold climate-related requirements of their own.

Neither of those clauses lives inside 9.3 directly, but both feed it. Clause 4.1 supplies input (b), and Clause 4.2 supplies input (c), so the climate change determination doesn't stay tucked away in a context-analysis document somewhere. Whether or not an organization planned for that, it appears on the management review agenda. Certification bodies started checking for compliance with the amendment during surveillance audits starting from its February 2024 publication date, which means organizations due for a surveillance visit since then need an actual answer on the climate change determination on record, not a shrug.

The documented outputs Clause 9.3.3 requires

The standard is explicit that documented information has to exist as evidence of those results. This is not a nice-to-have; it's written into the clause.

The distinction that trips up a lot of organizations is what counts as a decision versus what just sounds like one. "We will increase security engineering headcount by one in Q3 2026," with a name attached and a deadline attached, is a decision. "Security is important" or "we'll continue to monitor the situation" is not a decision; it's a placeholder dressed up as one. Auditors read minutes looking for the former and flag the latter every time they find it standing in for it.

Real outputs fall into a few categories, and these include changes to the ISMS itself, meaning updates to scope, policy, controls, or procedure, resource commitments that top management actually approved, such as budget, headcount, or a tooling purchase, and action items that carry both an owner and a target date. Anything vaguer than that isn't really an output, it's a sentiment. Clause 9.3.3 requires the results of the management review to include decisions related to continual improvement and any changes needed

The management review's connection to the PDCA cycle and Clause 10

Clause 9.1, monitoring and measurement, and Clause 9.2, internal audit, both generate the raw performance data that feeds into the review. The review's job is to take that data and turn it into decisions, and those decisions then flow directly into Clause 10, improvement, and Clause 6.2, information security objectives.

Internal audits are good at finding problems. They surface nonconformities and gaps, but they don't have the authority to fix anything on their own. That authority sits with the people in the management review room, the ones who can approve the budget or redirect the headcount that a fix actually requires. And the review only earns its keep if those decisions get tracked through to actual implementation. Clause 10 is what closes that loop; skip it, and the PDCA cycle just stalls out at Act, with decisions made on paper that never turn into anything real. That's also why input (a), the status of actions from previous reviews, carries so much weight in practice. It's the one mechanism that holds the whole cycle accountable across time instead of letting each meeting start fresh with no memory of what the last one decided. In the Plan-Do-Check-Act cycle, Clause 9.3 is the bridge between Check and Act

Documentation, retention, and the evidence trail auditors follow

The standard doesn't imply documentation is expected. It states it outright: documented information has to exist as evidence of the management review's results.

The core artifacts an auditor will ask for include formal minutes covering every input discussed and every decision reached, attendance records confirming the right people, meaning top management, were actually present, an action log with named owners and due dates, and the supporting documents that fed the discussion: internal audit reports, risk assessment summaries, performance metrics, and the current status of the risk treatment plan. Minutes need to separate what was merely noted from what was actually decided. A slide deck presented in the meeting is supporting material, nothing more; it doesn't stand in for the minutes themselves.

These records don't exist in isolation. They sit alongside the Statement of Applicability, the risk assessment and treatment plan records, internal audit reports, control implementation logs, and training completion records, forming one connected evidence set rather than a stack of disconnected files. An auditor pulling a thread from the management review minutes should be able to follow it straight into the risk register or the audit report it references, without hitting a gap.

Common audit failures in management review

Management review is one of the ISO 27001 requirements most often reduced to a box-ticking exercise, and auditors tend to notice when minutes written in real time differ from minutes reconstructed after the fact. The tell is usually in the language: real-time minutes carry the mess of an actual discussion, reconstructed ones read too clean, too uniform, too aligned with the clause text itself.

The most common failure pattern is missing mandatory inputs, and the most common omissions are input (c), changes in interested party expectations, and the Amendment 1:2024 climate change determination. Organizations still running an agenda built around the 2013 version of the standard are especially exposed here, since neither of those requirements existed in that earlier structure. The second major failure pattern is wrong attendees or absent leadership. Neither failure is complicated to fix. Both require treating the review as a leadership function with a fixed agenda that Clause 9.3 actually defines it as, heard directly by leadership rather than secondhand.