ISO 27001 Management Review for NIS2 and DORA

It is 08:00 on a Monday morning in February 2026. Maria, the CISO of a fast-growing European fintech, opens an email from the CEO with the subject line: “URGENT: Board Prep.” Attached is a news link about a multi-million Euro enforcement action under the NIS2 Directive, focused not only on failed controls, but on management body negligence.
The CEO’s question is short and uncomfortable:
“Can we prove that the board is actively governing cybersecurity risk, not just receiving IT updates?”
By 08:30, the CFO has added a customer audit questionnaire. The board chair wants a one-page view of cyber accountability before the next risk committee meeting. The CTO is asking whether a supplier incident changes the company’s DORA customer evidence pack. Meanwhile, Maria is staring at four issues that look operational on the surface: an unresolved privileged access exception, two delayed corrective actions, a tabletop exercise failure, and a supplier contract gap.
They are not separate problems. They are governance evidence problems.
In 2026, organizations exposed to NIS2, DORA, GDPR, customer assurance, and ISO/IEC 27001:2022 certification scrutiny face a sharper question than “Do we have security controls?”
The real question is:
Can management prove that it reviewed cybersecurity risk, understood the implications, made decisions, assigned actions, funded remediation, accepted residual risk where appropriate, and followed up?
That proof does not come from a policy PDF alone. It comes from a disciplined ISO/IEC 27001:2022 Clause 9.3 management review, supported by inputs, minutes, decisions, risk acceptance records, corrective actions, and evidence trails.
Why ISO 27001 Clause 9.3 is now board evidence
A weak management review is a rushed slide deck, a few metrics, and a signature. A strong management review is a controlled governance event where leadership decisions become evidence.
ISO/IEC 27001:2022 Clause 9.3 requires top management to review the information security management system at planned intervals to ensure its continuing suitability, adequacy, and effectiveness. The review must consider previous actions, changes in internal and external issues, changes in interested-party needs and expectations, feedback on performance, audit results, objective performance, risk assessment results, risk treatment status, and opportunities for continual improvement.
That structure is exactly what boards, regulators, customers, and auditors now expect from cybersecurity governance.
For NIS2 essential and important entities, Article 20 requires management bodies to approve cybersecurity risk-management measures, oversee implementation, and receive training. Article 21 requires proportionate technical, operational, and organizational measures, including risk analysis, incident handling, business continuity, supply chain security, secure development, effectiveness assessment, cyber hygiene, cryptography, HR security, access control, asset management, MFA where appropriate, and corrective action without undue delay.
For financial entities, DORA places ICT risk governance directly with the management body. DORA Article 5 requires the management body to define, approve, oversee, and remain responsible for the ICT risk management framework. That includes ICT risk tolerance, continuity and recovery plans, audit plans, budget, training, ICT third-party policies, major incident reporting channels, and corrective measures. Article 6 requires a documented ICT risk management framework that is reviewed at least annually and after major ICT-related incidents, supervisory instructions, testing, audits, or material changes.
GDPR adds the accountability layer. Article 5(2) requires controllers to be responsible for, and able to demonstrate, compliance with data protection principles. Article 32(1)(d) expects a process for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures.
A properly designed management review is where these obligations converge.
The regulatory pressure behind the review agenda
NIS2 and DORA do not use identical language. DORA also acts as the sector-specific EU legal act for covered financial entities where overlapping cybersecurity and reporting obligations are concerned. But both drive the same governance outcome: senior leadership must approve, oversee, resource, and correct cyber risk management.
NIS2 applies broadly to medium-sized and larger entities in covered sectors, and in some cases regardless of size. Annex I includes digital infrastructure providers such as cloud computing service providers, data centre service providers, content delivery network providers, trust service providers, public electronic communications providers, managed service providers, and managed security service providers. Member States were required to establish lists of essential and important entities by 17 April 2025.
The enforcement stakes are significant. For failures connected to Article 21 cybersecurity risk-management measures or Article 23 incident reporting, maximum administrative fines can reach at least EUR 10,000,000 or 2% of worldwide annual turnover for essential entities, and at least EUR 7,000,000 or 1.4% of worldwide annual turnover for important entities, whichever is higher.
DORA has applied since 17 January 2025 and covers a broad financial-sector ecosystem, including credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, insurers, reinsurers, trading venues, credit rating agencies, crowdfunding service providers, securitisation repositories, and ICT third-party service providers. DORA is proportional, but proportional does not mean informal. Even smaller financial entities need records showing that ICT risk governance is scaled, intentional, documented, and reviewed.
This is why the management review cannot remain a certification formality. It has become one of the most practical evidence mechanisms for NIS2 accountability, DORA ICT risk governance, GDPR accountability, and customer due diligence.
The Clarysec policy backbone for review discipline
Clarysec treats the management review as a board evidence pack, not a ceremonial annual meeting.
The Information Security Policy makes ISO 27001 management review explicit:
Management review activities (per ISO/IEC 27001 Clause 9.3) shall be conducted at least annually and shall include:
From section “Governance Requirements”, policy clause 5.3.
The same policy defines the evidence expectations:
Review of security key performance indicators (KPIs), incidents, audit findings, and risk status
From section “Governance Requirements”, policy clause 5.3.2.
And it ties review to executive decisions:
Decisions on updates to scope, controls, and resource allocation
From section “Governance Requirements”, policy clause 5.3.3.
That final point is essential. A management review is not a presentation. It is a decision forum.
The Governance Roles and Responsibilities Policy adds the traceability rule:
Governance shall support integration with other disciplines (e.g., risk, legal, IT, HR), and ISMS decisions shall be traceable to their source (e.g., audit records, review logs, meeting minutes).
From section “Governance Requirements”, policy clause 5.5.
It also assigns escalation responsibilities:
Participates in ISMS management reviews and escalates decisions requiring Board-level approval.
From section “Roles and Responsibilities”, policy clause 4.1.3.
For smaller organizations, the same governance logic should be scaled, not ignored. The Governance Roles and Responsibilities Policy-sme - SME states:
All significant security decisions, exceptions, and escalations must be recorded and traceable.
From section “Governance Requirements”, policy clause 5.5.
The Audit and Compliance Monitoring Policy-sme - SME ensures assurance findings reach leadership:
Audit findings and status updates must be included in the ISMS management review process.
From section “Governance Requirements”, policy clause 5.4.3.
And the Risk Management Policy-sme - SME sets a high-risk cadence:
Reviews the highest risks quarterly with the Risk Coordinator.
From section “Roles and Responsibilities”, policy clause 4.1.3.
The result is a practical rhythm: quarterly review of the highest risks, annual or planned Clause 9.3 management review, and triggered reviews after major incidents, audits, resilience tests, supplier failures, regulatory changes, or major business changes.
Build the board evidence pack before the meeting
The Zenith Blueprint: An Auditor’s 30-Step Roadmap addresses management review in the Audit, Review & Improvement phase, Step 28: Management Review. It instructs teams to prepare required inputs before the meeting:
ISO 27001 specifies several required inputs to the management review. Prepare a brief report
or presentation covering these points:
From the Audit, Review & Improvement phase, Step 28: Management Review.
The Blueprint emphasizes previous actions, changes in external and internal issues, ISMS performance and effectiveness, audit results, monitoring and measurement results, security objectives, incidents, nonconformities, opportunities for improvement, resource needs, and follow-up on prior decisions.
It also warns that the review must result in action:
Decisions and Actions: This is crucial – management review isn’t just a presentation;
it’s about making decisions.
From the Audit, Review & Improvement phase, Step 28: Management Review.
A board-ready evidence pack should be concise enough for executives, but detailed enough for auditors.
| Evidence item | Governance purpose | Typical owner |
|---|---|---|
| Management review agenda | Shows Clause 9.3 inputs were planned and covered | ISMS Manager or CISO |
| Prior action tracker | Shows follow-up from previous management decisions | ISMS Manager |
| Compliance register summary | Shows NIS2, DORA, GDPR, contractual, and customer obligation changes | Legal or GRC |
| Risk register summary | Shows high risks, residual risks, and risk owner decisions | Risk Coordinator or CISO |
| Statement of Applicability change log | Shows control decisions, exclusions, and implementation status | ISMS Manager |
| KPI and objective dashboard | Shows performance, trends, and missed targets | Security Operations or GRC |
| Incident and near-miss summary | Shows escalation, root cause, impact, and lessons learned | Incident Manager |
| Supplier and cloud risk report | Shows third-party ICT risk oversight | Vendor Manager or Procurement |
| Internal audit and independent review findings | Shows objective assurance and nonconformities | Internal Audit or Compliance |
| Corrective action tracker | Shows accountability, deadlines, and closure evidence | Control Owners |
| Resource and budget decision log | Shows management support and prioritization | Executive Sponsor |
| Approved minutes | Shows oversight, decisions, assigned owners, and follow-up | Meeting Secretary or ISMS Manager |
Turn ISO inputs into NIS2 and DORA evidence
Maria’s fintech needs one agenda that can satisfy ISO certification auditors, DORA-aligned customers, NIS2 scoping questions, and board oversight expectations. The easiest way to do that is to translate each Clause 9.3 input into a governance question.
| Management review agenda item | NIS2 and DORA governance concern | Evidence generated |
|---|---|---|
| Status of previous review actions | Shows a functioning oversight cycle and accountability | Minutes showing follow-up and closure status |
| Changes in external and internal issues | Shows adaptation to new threats, regulations, services, suppliers, and business strategy | Compliance register update and risk register changes |
| Changes in interested-party needs | Shows customer, regulator, supplier, and contractual obligations are reviewed | Updated obligations register and customer assurance tracker |
| ISMS performance and objectives | Shows leadership monitors effectiveness of cybersecurity measures | KPI dashboard and objective performance record |
| Nonconformities and corrective actions | Shows weaknesses are escalated and remediated | Corrective action log with owners and dates |
| Monitoring, measurement, and audit results | Shows effectiveness assessment and independent assurance | Internal audit summary and monitoring results |
| Risk assessment and risk treatment status | Shows management reviews treatment progress and residual risk | Risk treatment plan, SoA update, and acceptance records |
| Opportunities for continual improvement | Shows proactive governance and resilience improvement | Approved improvement plan and investment decisions |
| Resource and budget needs | Supports DORA governance expectations and management support | Budget approvals, resourcing decisions, and training plans |
The last line is not a substitute for ISO 27001’s required review inputs. It is Clarysec’s practical expansion for 2026 governance, because DORA, NIS2, and real board accountability require evidence that leadership considered whether security had enough people, money, tools, and authority.
A 90-minute management review for a fintech SaaS provider
Consider Maria’s company: a fintech SaaS provider with EU customers. It offers transaction monitoring services, uses a major cloud provider, relies on an outsourced SOC, processes personal data, and has recently onboarded two new payment customers. It is preparing for ISO/IEC 27001:2022 surveillance, a DORA-aligned customer review, and a NIS2 scoping assessment.
A focused 90-minute management review could work like this.
1. Start with obligations and context changes
For SMEs, the Legal and Regulatory Compliance Policy-sme - SME gives a simple starting point:
The GM must maintain a simple, structured Compliance Register listing:
From section “Governance Requirements”, policy clause 5.1.1.
The review pack should summarize whether the organization is in scope for NIS2, whether DORA applies directly or through customer flow-down, whether GDPR processing changed, and whether contractual security obligations changed.
Examples:
- A new EU customer contract requires customer security incident notification within 72 hours.
- A DORA-aligned customer due diligence request asks for ICT third-party registers, exit strategy evidence, and incident escalation records.
- A NIS2 assessment identifies possible classification risk because one service supports managed security activities in a Member State.
- A new analytics feature changes the GDPR data inventory because it processes online identifiers.
Management decisions should approve the compliance register update, assign legal and GRC to validate NIS2 classification with local counsel, and require a DORA customer evidence pack by the next quarter.
2. Present risk and Statement of Applicability decisions
The Zenith Blueprint Risk Management phase, Step 13: Risk Treatment Planning and Statement of Applicability, emphasizes executive approval:
Risk treatment decisions and the SoA should be reviewed and approved by top management.
From the Risk Management phase, Step 13: Risk Treatment Planning and Statement of Applicability.
The review should not drown the board in every risk. It should show top risks, treatment status, exceptions, overdue actions, and residual risks needing approval.
| Risk | Current status | Decision required |
|---|---|---|
| Cloud administrator account compromise | MFA implemented, privileged access review overdue | Approve monthly privileged access review owner and deadline |
| Outsourced SOC dependency | Contract lacks full audit right and incident cooperation language | Approve contract remediation or alternate provider assessment |
| Backup recovery objective not met | Recovery test exceeded target by 4 hours | Approve budget for backup redesign |
| Supplier concentration risk | Two critical services rely on the same cloud region | Approve resilience architecture review |
| Personal data log retention | Debug logs contain online identifiers longer than intended | Approve retention reduction and monitoring control |
This creates a traceable chain from risk assessment to treatment to management decision.
3. Review incidents, near misses, and reporting readiness
NIS2 Article 23 requires staged reporting for significant incidents, including an early warning within 24 hours, notification within 72 hours, and a final report within one month of the incident notification, with progress reporting for ongoing incidents. DORA Articles 17 to 19 require detection, classification, escalation, communication, reporting, root-cause analysis, and improvement for ICT-related incidents.
The management review should include significant incidents, near misses, classification outcomes, root causes, time to detect, time to escalate, time to recover, customer notification readiness, authority reporting readiness, lessons learned, and corrective actions.
The Zenith Blueprint, in Controls in Action phase, Step 16: People Controls II, explains why employee reporting must feed governance:
Lastly, Control 6.8 must feed into the continual improvement cycle of the ISMS. Reports
generated by personnel should be reviewed during management review (Clause 9.3) and
used to identify breakdowns in policies such as off-boarding, asset return, or NDA violations.
From the Controls in Action phase, Step 16: People Controls II.
If a former employee account remained active after termination, the board should not treat it as a single ticket. It is evidence of a possible weakness in HR, IT, access control, asset management, monitoring, and corrective action.
4. Review suppliers, cloud, and exit readiness
DORA Article 28 makes ICT third-party risk part of the ICT risk management framework. Financial entities remain fully responsible for compliance when ICT services are contracted out. They must maintain an up-to-date register of ICT contractual arrangements, distinguish critical or important functions, perform due diligence, manage concentration risk, secure audit and inspection rights, and maintain exit strategies.
NIS2 Article 21 also requires supply chain security, including supplier relationship security, supplier-specific vulnerabilities, supplier cybersecurity practices, and corrective measures.
For the management review, supplier reporting cannot be a procurement appendix. It must be board evidence.
Include critical supplier changes, due diligence status, contract gaps, cloud shared responsibility review, concentration risk, exit strategy results, supplier incident cooperation, and corrective actions from supplier assessments. If leadership approves continued use of a high-risk provider, the minutes should record the rationale, compensating controls, review date, and accountable owner.
Maria’s board receives one concrete supplier issue: a key platform provider suffered a minor, non-reportable incident. No customer data was affected, but the event exposed concentration risk. The CEO assigns the CTO to complete a secondary supplier feasibility study by next quarter and allocates EUR 25,000 for the assessment. That single documented decision proves supply chain risk oversight, resource allocation, and follow-up.
How Zenith Controls connects the evidence
Clarysec’s Zenith Controls: The Cross-Compliance Guide helps teams explain why ISO control evidence matters across frameworks.
For management review, ISO/IEC 27002:2022 control 5.4, Management responsibilities, is a governance anchor. It supports management direction, accountability, resourcing, and oversight. Zenith Controls links control 5.4 to supporting ISO/IEC 27002:2022 controls that commonly appear in management review evidence.
| ISO/IEC 27002:2022 control | Why it matters to management review |
|---|---|
| 5.1 Policies for information security | Management must approve, promote, resource, and institutionalize policies |
| 5.2 Information security roles and responsibilities | Management must ensure roles exist, have authority, and are monitored |
| 5.8 Information security in project management | Management ensures security is integrated into projects and business change |
| 5.35 Independent review of information security | Independent review gives management objective assurance |
| 5.36 Compliance with policies, rules and standards for information security | Compliance monitoring gives management evidence of enforcement |
| 8.15 Logging | Logs support evidence for incidents, access control, and compliance monitoring |
| 8.16 Monitoring activities | Monitoring supports detection, escalation, and performance reporting |
This control set gives Maria a cross-compliance story. Her management review evidence can support ISO/IEC 27001:2022 certification, NIS2 Article 20 oversight, NIS2 Article 21 risk-management measures, DORA Article 5 ICT governance, DORA Article 6 ICT risk management framework review, DORA Articles 24 to 27 digital operational resilience testing, GDPR Article 32(1)(d), NIST CSF 2.0 GOVERN outcomes, and COBIT 2019 governance objectives.
| Evidence theme | ISO or control anchor | Regulatory or framework relevance |
|---|---|---|
| Management responsibility | ISO/IEC 27002:2022 5.4 | NIS2 Article 20, DORA Article 5, COBIT 2019 EDM03 |
| Independent assurance | ISO/IEC 27002:2022 5.35 | GDPR Article 32(1)(d), DORA Articles 24 to 27, NIST SP 800-53 CA-2 |
| Corrective action tracking | ISO/IEC 27001:2022 Clause 10 | NIS2 Article 21, DORA Article 13, NIST SP 800-53 CA-5 |
| Policy compliance monitoring | ISO/IEC 27002:2022 5.36 | GDPR accountability, COBIT 2019 MEA02, COBIT 2019 MEA03 |
| ICT third-party risk | ISO/IEC 27002:2022 5.19 and 5.20 | DORA Article 28, NIS2 Article 21 |
| Incident governance | ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 | NIS2 Article 23, DORA Articles 17 to 19 |
Independent review and compliance monitoring deserve special attention. Management review without independent evidence becomes self-reporting. ISO/IEC 27002:2022 control 5.35 gives the board objective assurance through internal audits, external assessments, penetration test summaries, certification audit observations, and control effectiveness reviews. Control 5.36 turns “we have a policy” into “we know whether people and systems follow the policy.”
How auditors will test your management review
A Clause 9.3 management review is one of the first places auditors look when deciding whether governance is real. Different auditors ask different questions, but all of them look for traceability.
| Auditor perspective | What they will look for | Evidence that helps |
|---|---|---|
| ISO/IEC 27001:2022 auditor | Whether top management reviewed required inputs and followed up | Agenda, minutes, KPI pack, audit results, corrective actions, risk treatment approvals |
| ISO/IEC 27007-style ISMS auditor | Whether review records show ongoing oversight and implemented action items | Review schedule, action tracker, objective updates, ISMS change decisions |
| ISO/IEC 19011-style auditor | Whether conclusions are supported by objective evidence and fair audit methods | Interview notes, records, approved minutes, evidence references |
| NIST-oriented assessor | Whether senior leadership approves risk strategy, roles, resources, and program oversight | Security program plan, senior official appointment, risk strategy approval, POA&M |
| COBIT 2019 auditor | Whether leadership evaluates, directs, and monitors risk and security initiatives | Board reports, risk dashboards, EDM03 alignment, performance metrics |
| ISACA ITAF auditor | Whether tone at the top is visible and management responses are timely and effective | Internal audit responses, escalation records, incident governance trail |
The common failure is not that a meeting did not happen. It is that the meeting did not change anything. Auditors want to see decisions, owners, deadlines, evidence expected, and closure records.
Outputs that prove executive oversight
Inputs create the review. Outputs prove governance.
At minimum, the management review record should include:
Approved decisions
Examples include approving certification readiness, updating ISMS scope, revising incident reporting workflows, requiring supplier contract remediation, or accepting residual risk until a defined date.Assigned actions
Each action needs an owner, due date, priority, expected evidence, and review cadence.Risk acceptance records
Accepted risks should identify the risk owner, rationale, residual risk level, compensating controls, expiry date, and escalation threshold.Resource decisions
Record budget, headcount, tools, training, external audit support, legal assessment, tabletop exercises, or supplier assurance activities.Policy and control updates
Capture changes to access control, incident response, business continuity, supplier management, encryption, secure development, logging, vulnerability management, or data retention.Corrective action approvals
Nonconformities and audit findings should become corrective actions with ownership, timing, and evidence expectations.Follow-up mechanism
The next review should begin with the status of these decisions.
For SMEs, the Information Security Policy-sme - SME reinforces the need to connect certification, regulation, and business change:
This policy must be reviewed by the General Manager (GM) at least annually to ensure continued compliance with ISO/IEC 27001 certification requirements, regulatory changes (such as GDPR, NIS2, and DORA), and evolving business needs.
From section “Review and Update Requirements”, policy clause 9.1.1.
That sentence captures the 2026 reality. Management review must connect the ISMS, regulatory change, customers, suppliers, incidents, risk, resources, and business strategy in one governance loop.
Common management review failures in 2026
The most common failures are predictable.
First, the review is too technical. Executives receive vulnerability counts and alert volumes, but not business risk, regulatory exposure, customer impact, or decision options.
Second, there is no decision log. Minutes say “supplier risk discussed,” but do not record whether management accepted the risk, required remediation, approved budget, or assigned a deadline.
Third, residual risk acceptance is informal. A risk stays open for months because “the business knows about it,” but there is no owner approval, rationale, expiry date, or review trigger.
Fourth, audit findings do not reach management. Internal audit reports remain inside GRC folders while leadership sees only a green status summary.
Fifth, suppliers and cloud providers are treated separately from ISMS performance. Under DORA and NIS2, third-party ICT risk is core governance evidence.
Sixth, incidents are reported as operational events but not reviewed for systemic improvement. Root causes, lessons learned, and corrective actions must feed the management review.
Seventh, the prior action tracker is missing. Auditors will ask what happened to last year’s decisions. If the answer is scattered across emails and tickets, the governance story weakens.
One governance loop, many obligations
Clarysec’s practical model is simple:
Scope and obligations
Use the ISMS scope, interested parties, compliance register, customer obligations, and supplier dependencies to define what the review must cover.Risk and control evidence
Use the risk register, Statement of Applicability, control implementation evidence, KPIs, and compliance monitoring.Assurance inputs
Bring internal audits, independent reviews, penetration tests, supplier assessments, customer audits, and certification findings.Operational resilience inputs
Include incidents, near misses, business continuity tests, backup results, disaster recovery exercises, crisis management lessons, and reporting readiness.Leadership decisions
Record risk acceptance, resource allocation, scope changes, control changes, supplier decisions, corrective actions, and strategic objectives.Evidence preservation
Store minutes, packs, approvals, action trackers, and closure evidence in a controlled repository.Follow-up cadence
Review high risks quarterly, run planned Clause 9.3 management reviews, and trigger additional reviews after major incidents, supplier changes, audits, tests, or regulatory developments.
That is how one management review can serve ISO/IEC 27001:2022 certification, NIS2 management body accountability, DORA ICT risk governance, GDPR accountability, NIST CSF GOVERN review, COBIT 2019 board oversight, and customer due diligence.
Make your next management review audit-ready
Maria’s board did not need another technical dashboard. It needed defensible evidence that cybersecurity risk was reviewed, understood, decided, funded, and improved.
Your organization needs the same.
Start this month:
- Build a Clause 9.3 evidence pack.
- Map each agenda item to a risk, obligation, KPI, audit finding, incident, supplier issue, or corrective action.
- Record every decision with an owner, due date, rationale, and expected evidence.
- Use the prior action tracker as the first agenda item in the next review.
- Preserve the minutes, approvals, risk acceptances, and closure records in a controlled repository.
Clarysec can help you operationalize this quickly using the Zenith Blueprint, the Clarysec policy suite, and Zenith Controls as your cross-compliance compass for ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF, COBIT 2019, and audit readiness.
If your management review is still a compliance chore, it is time to turn it into a strategic governance asset. Download the Clarysec toolkits, prepare your board evidence pack, and make your next review the proof that leadership is governing cybersecurity risk.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


