Management review: turn risk registers into decisions

NIS 2 moved accountability for cybersecurity risk onto the management body. In many mid-market organizations, the risk register still lives mostly inside the security team: scored, treated and reviewed by people who cannot approve budget or accept exposure on behalf of the company. Auditors and, under NIS 2, supervisory authorities increasingly look at exactly that gap.

The good news is that you already own the machinery. ISO 27001 gives you the risk assessment process in Clause 6.1.2, the risk owner role, and the management review in Clause 9.3. The practical approach is to reuse those building blocks instead of standing up a parallel NIS 2 governance process. This guide shows how to convert register entries into priorities, named owners and follow-up actions that leadership can actually decide on.

The pressure is real but the follow-through is uneven. According to the European Union Agency for Cybersecurity, 70% of organizations identified compliance as the main driver of cybersecurity investment, while only 41% said those investments had strengthened risk management (European Union Agency for Cybersecurity). Spending rises; decision quality does not automatically follow.

What you'll need before you start

This guide assumes an ISMS that is already operating, not one still being built. Before the first decision-ready review, make sure you have:

• A populated risk register with consistent scoring, documented rationale and a named owner per entry

• A documented ISO 27001 risk management approach covering criteria, acceptance thresholds and treatment options

• A treatment plan linked to Annex A controls and the Statement of Applicability

• A fixed management review cadence written into policy, with top management committed to attending

• Clarity on which NIS 2 national transposition applies to your entity and sector

Step 1: Map your ISO 27001 risk process to NIS 2 management obligations

Start by inventorying what your ISMS already produces and checking it against the governance duties in NIS 2 Article 20 governance requirements and the risk management measures in Article 21. Most of the substance is there: the register evidences risk identification and analysis, the treatment plan evidences control selection, and the Statement of Applicability evidences justification.

The gap is rarely technical. It is evidentiary. NIS 2 expects documented proof that the management body received risk information, understood it, and acted on it. A register that is complete and current but has never been formally presented to leadership satisfies Clause 6.1.2 and leaves Article 20 exposed.

Build a short mapping sheet: each NIS 2 obligation on one side, the existing ISMS artifact on the other, and a gap flag where no artifact demonstrates management involvement. Expect your gaps to cluster around training for the management body, documented decisions, and escalation thresholds. For the detail of what the directive expects operationally, work through the cybersecurity risk management measures under NIS 2 alongside your Annex A mapping.

Step 2: Assign a risk owner as the bridge between security and leadership

Name a single risk owner at leadership level who is accountable for bringing risk upward. In mid-market organizations this is typically the CEO, the COO, or a designated leadership person who owns policies, risk and GRC. Security remains the analytical engine. The risk owner is the translation layer.

This role has two jobs. First, interpret: read a register entry about unrotated service account credentials and restate it as a business consequence with a cost, a regulatory angle and a time horizon. Second, filter: decide which of the many entries in the register actually require a decision from the management body this quarter, and which are operational work that security executes under existing authority.

Avoid the pattern where every risk is owned by the CISO or by "IT". Auditors challenge it, and it places decision rights with someone who cannot release the budget. Security pushed from the top works; security escalated from the bottom stalls.

Step 3: Distill the risk register into a decision-ready summary

Do not forward the register. Produce a one-page decision-ready summary with a fixed structure, and keep it to the risks that genuinely need an executive choice. For each item, include four things:

1. The risk in business terms: what fails, who is affected, what it costs or triggers in regulatory terms

2. The decision required: accept, treat, share, avoid, or escalate for more analysis

3. The options and their consequences: typically two, with cost, effort and residual risk for each

4. The named owner and proposed deadline

Strip the threat taxonomy, the likelihood arithmetic and the control identifiers. Keep them in the register where the auditor will look for them. Supplier exposure deserves a standing place on this page: third-party involvement accounted for 48% of data breaches in Verizon's 2026 Data Breach Investigations Report, up 60% from the prior year (Verizon). A concentration risk in a single critical processor is a leadership decision, not a security ticket.

Five to eight items is a workable page. More than that and the review becomes a reading exercise.

Step 4: Run the management review as a decision-making mechanism

Structure the agenda around decisions, not status. Every line item on the summary gets a recorded outcome before the meeting closes: accepted with rationale, treated with a budget and date, shared with a named counterparty, avoided, or escalated with a defined next analysis step.

Clause 9.3 already requires inputs such as changes in external issues, performance of controls, audit results and opportunities for improvement. Layer the decision prompts on top of that required agenda rather than replacing it. Auditors routinely check the number of management reviews held against the frequency stated in your policy, then test the documentation, action items and summaries behind each one.

Leadership engagement is measurable elsewhere too. The UK Department for Science, Innovation and Technology found that among medium and large businesses and high-income charities sharing cyber updates with senior leaders, 79% of businesses and 84% of charities included management of cyber risk in those updates, in the same survey where 43% of UK businesses identified a breach or attack in the previous 12 months, rising to 65% of medium and 69% of large businesses (UK Department for Science, Innovation and Technology). Updates reach the top. Documented decisions are the harder part.

Step 5: Close the loop with follow-up actions and evidence

Every decision taken in the review must land back in the register and the treatment plan within days, not at the next cycle. Update the treatment option, the residual score, the owner, the deadline and the review date. An accepted risk needs the acceptor's name and the date of acceptance recorded against it.

Retain three evidence artifacts per cycle: the signed minutes, the decision log, and the updated register entries showing the change. Together these demonstrate ongoing management involvement under both ISO 27001 Clause 9.3 and NIS 2 Article 20. Keeping the register, treatment plans and policy sign-offs in one system rather than scattered spreadsheets makes this reconstructable months later, which is the problem Secfix, the compliance automation platform, is built to solve.

Completeness matters because partial programs are the norm. PwC reported that only 2% of executives said their organization had implemented cyber resilience actions across all areas surveyed (PwC).

Troubleshooting: where this breaks down

Leadership rubber-stamps the summary. Shorten it further and require a recorded choice per item, with the rationale captured in the minutes in the owner's own words. If every item is approved as proposed, the filtering in Step 2 was too generous.

The review produces no traceable actions. Pre-populate the agenda with explicit decision prompts rather than discussion topics. "Approve 18k for log retention or accept the detection gap until Q3" produces a decision; "risk update" does not.

The full register keeps reaching the management body. Enforce the gatekeeper step. The risk owner filters before escalation, and the register stays available as an annex nobody is asked to read.

Maturity assumptions outrun reality. Cisco found that only 4% of organizations worldwide reached its Mature level of cybersecurity readiness in 2025 (Cisco). Present options at the maturity you actually have.

Key takeaways

• Reuse your existing register, risk owner role and management review rather than building a separate NIS 2 governance track.

• Name one leadership-level risk owner who filters and translates before anything reaches the management body.

• Replace register forwarding with a one-page summary carrying the decision, the options and the owner.

• Record an explicit outcome for every item in the review, with a deadline, and write it back into the register that week.

• Keep minutes, decision logs and updated entries together as the evidence trail an auditor or regulator will request.

Frequently asked questions

Is management personally liable under NIS 2?

Under NIS 2 (Article 20), management bodies must approve the cybersecurity risk-management measures, oversee their implementation and complete training, and they can be held liable for infringements. National transpositions vary in how sanctions apply, so check your jurisdiction. In practice, the management review is where that accountability becomes documented and auditable. Comparing the changes from NIS 1 to NIS 2 shows how much the governance expectations tightened.

How often should management review risks?

ISO 27001 requires reviews at planned intervals, and Clause 8.2 requires reassessment when significant changes occur. For NIS 2 readiness, quarterly reviews give leadership enough frequency to demonstrate active oversight without the agenda degrading into a status update. Whatever cadence you set, state it in policy and hold to it: auditors count.

How does ISO/IEC 27005 help structure the risk assessment behind the review?

ISO 27001 defines what the process must achieve; ISO/IEC 27005 explains how to run it. It provides the methodology layer, including criteria, scoring approaches, scenario construction and treatment selection. That consistency is what makes the register comparable across cycles and therefore summarizable for leadership. Without it, two analysts score the same scenario differently and the summary loses credibility at the exact moment it needs it.

Next steps

Run one cycle end to end before you change anything else: map the gaps, name the risk owner, build the one-page summary, hold the review, write the decisions back. Then check whether an auditor could reconstruct the decision trail from your records alone. If reconstructing it means digging through email threads and spreadsheet versions, consolidating risk, vendors, assets and policy sign-offs into a single system is the next move to make.