IT Governance vs NIS2 Governance: One Framework, Four Decisions You Can’t Delegate

The European Union Agency for Cybersecurity published a 170-page document in June 2025 whose entire purpose is to map the NIS2 cybersecurity requirements onto the standards organisations already use. It names ISO/IEC 27001:2022, ISO/IEC 27002:2022, the NIST Cybersecurity Framework 2.0, ETSI EN 319 401 and CEN/TS 18026:2024. It mentions COBIT zero times. It mentions ISO/IEC 38500 zero times. [5]

That absence is the answer to the question in the title, and it is not the answer most people expect. You do not need a second governance framework. You need the one you have, extended at four specific points — because information technology governance and NIS2 Article 20 governance are not competing frameworks. They govern different objects, and they have opposite rules about who is allowed to sign.

What Information Technology Governance Actually Governs

The confusion starts because “governance” is doing two jobs in one sentence. Information technology governance, in its formal sense, is a board-level discipline concerned with whether the organisation’s use of technology serves its purpose. It is not information security management, and treating the two as synonyms is what produces the duplicate-framework anxiety.

ISO/IEC 38500 is the international standard for it, and its scope is explicit: the document “provides guiding principles for members of governing bodies of organizations and those that support them on the effective, efficient and acceptable use of information technology (IT) within their organizations.” [4] Note the object — the use of IT, judged on effectiveness, efficiency and acceptability. Security is one input to that judgement, not its subject.

Two details matter here and are missing from almost everything written about this. First, the current edition is the third, published February 2024, which “cancels and replaces the second edition (ISO/IEC 38500:2015).” [3][4] If your reference material describes six principles, it is describing the withdrawn edition. The 2024 edition carries eleven: purpose, value generation, strategy, oversight, accountability, stakeholder engagement, leadership, data and decisions, risk governance, social responsibility, and viability and performance over time. Its governance model gained a fourth task as well — “engage stakeholders” now sits alongside evaluate, direct and monitor. [4]

Second, and more consequentially, the standard says of itself that it “provides principle-based guidelines and therefore does not include specific implementation detail.” [4] COBIT sits at the same altitude, and ISACA describes it as “specifically designed to play well with others,” built to “integrate the industry standards, guidelines, regulations and best practices unique to your enterprise.” [7]

Ireland’s National Cyber Security Centre draws the line cleanly for board members: “Governance is about setting strategy, oversight, risk appetite (board and executive level)” while “Management is about implementing policies, processes, and controls (operational level).” Overlap exists, the NCSC notes, because “some actions (e.g. policy approval, role assignment) are both governance-driven and management-executed.” [6] That overlap is precisely where Article 20 lands.

What Article 20 Imposes: Three Verbs and a Training Duty

Article 20(1) is one sentence and it is worth reading in full: “Member States shall ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements by the entities of that Article.” [1][2]

Three verbs: approve, oversee, be liable. The object of all three is fixed — the Article 21 measures — and Article 21(2) is a closed list, providing that measures “shall be based on an all-hazards approach” and “shall include at least” ten named domains, from risk-analysis policies through incident handling, business continuity, supply chain security, cryptography and multi-factor authentication. [1] Your IT governance framework tells you how to govern. Article 21 tells you what must exist to be governed.

Article 20(2) adds a training duty, asymmetric in a way that is regularly reported incorrectly. Management-body members “are required to follow training.” For everyone else, Member States “shall encourage” entities “to offer similar training to their employees on a regular basis.” [1] Binding on the board; encouragement for staff. Most summaries flatten both into one mandate.

The Directive also never defines “management body” — the term is absent from the Article 6 definitions, leaving its meaning to national transposition and your own corporate law. Our guide to what Article 20 actually requires your board to sign works through the decisions and evidence types that follow.

The Delegation Seam: the One Clause That Decides Your Structure

Here is the mismatch, and it is a single clause on each side.

ISO/IEC 38500:2024 defines “direct” as “communicate desired purposes and outcomes.” Attached to that definition is Note 2 to entry: “Objectives, strategies and policies can be set by management if they have the relevant authority delegated to them by the governing body.” [4] Delegation is not a workaround in the IT governance model. It is designed in. A governing body that sets direction and then delegates the setting of objectives and policies to management is using the standard exactly as written.

Article 20(1) contains no such note. Approval of the Article 21 measures sits with the management body, full stop. [1]

That could be dismissed as drafting habit — a directive is terse, a standard is discursive. The evidence that it is not comes from the EU’s own implementing regulation. Where Commission Implementing Regulation (EU) 2024/2690 wants to permit delegation, it says so: Annex point 2.1.1 provides that risk assessment results and residual risks “shall be accepted by management bodies or, where applicable, by persons who are accountable and have the authority to manage risks, provided that the relevant entities ensure adequate reporting to the management bodies.” [5] The drafters knew how to write a delegation clause. They wrote one for residual-risk acceptance and none into Article 20(1).

The mechanism matters more than the textual point. A framework whose default is delegation generates decision records showing approval wherever authority was delegated to — and that record is the artefact a supervisory authority reads when it asks who approved the measures. If your minutes, your policy sign-off page and your RACI all show a CIO or CISO in the approving seat because your framework permitted it, you have produced documentary evidence that approval sat below where Article 20 places it. The framework did not fail; it did what it was built to do, on an obligation that was not built for it.

This reading is structural rather than settled — Article 20 delegation has not been tested in published case law, and national transposition varies. Treat it as the conservative position: keeping approval at board level costs one agenda item, and getting it wrong leaves an evidence trail you cannot retroactively fix. Where the layer beneath the board should sit is covered in our guide to NIS2 programme governance structure.

The Absence Test: What the Regulator’s Own Mapping Names

Return to the ENISA guidance, because it answers the framework question empirically rather than rhetorically. The document exists to map each technical requirement of Implementing Regulation 2024/2690 to, in its words, “requirements of European and international standards or frameworks” — and it lists them: ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST Cybersecurity Framework 2.0, ETSI EN 319 401 V3.1.1 and CEN/TS 18026:2024. [5]

Searching the full 170-page text returns 110 occurrences of “NIST,” nine of “27002,” five of “27001,” one of “ITIL” — and zero of “COBIT” or “38500.”

Read that correctly. It is not a verdict that IT governance frameworks are inadequate — it is evidence that they sit at a layer NIS2 does not regulate. The Directive regulates a defined set of security measures and who approves them; it says nothing about IT value delivery or portfolio decisions, which is most of what COBIT and ISO/IEC 38500 exist to govern. Absence here means wrong layer, not disapproval. ENISA’s own instruction points the same way: “To implement the requirements, the relevant entities may build upon their current usage of standards or frameworks, if available,” and the guidance “does not aim to establish a new standard or to duplicate existing ones.” [5]

Two honest caveats. ENISA states that its document “is not legally binding and is only of an advisory character,” and warns that “the mapping should not be interpreted as a measure of equivalency among different standards or frameworks.” [5] Mapping a control is not the same as satisfying an obligation. And the Implementing Regulation binds only eight digital and ICT service types — DNS providers, TLD registries, cloud and data centre providers, CDN providers, managed service and managed security service providers, online marketplace, search engine and social network platforms, and trust service providers. [5] For a hospital or an energy operator the CIR is instructive rather than directly applicable; your binding detail comes from national transposition.

What Extends Cleanly, and What You Have to Add

The effort column below is our estimate for an organisation that already runs a functioning IT governance framework, not a figure from any regulator.

NIS2 duty	Where it already lives	What you must add	Effort
Approve the Article 21 measures (Art 20(1))	Policy approval exists in every governance framework	Remove the delegation path for this one approval; name the management body in the sign-off block	Low
Oversee implementation (Art 20(1))	The “monitor” task of your existing model	A standing agenda item with a named reporting line, not an annual review	Low
The Article 21(2)(a)–(j) measure set	Rarely complete — frameworks govern, they do not enumerate controls	A measure register mapped to your existing controls, with gaps flagged	High
Residual-risk acceptance	Risk governance principle; risk committee	Documented acceptance criteria and a reporting line back to the board	Medium
Resourcing commitment	Resource-allocation decisions already sit with the board	The commitment written into the security policy itself	Low
Dated policy approval record	Minutes exist; the date of approval often is not on the document	An approval block on the policy carrying the date and the approving body	Low
Board training (Art 20(2))	Nowhere — no IT governance framework obliges directors to be trained	A training record for each management-body member	Medium

Two of those rows come from the Implementing Regulation and repay a closer look, because they interlock. CIR Annex point 1.1.1(e) requires the security policy to “include a commitment to provide the appropriate resources needed for its implementation, including the necessary staff, financial resources, processes, tools and technologies.” Point 1.1.1(k) requires the same policy to “indicate the date of the formal approval by the management bodies.” [5] The resourcing commitment sits inside the document the board dates and signs. A board that approves the policy in one meeting and declines the budget in the next has dated a document that contradicts its own decision — and both records survive.

For the oversight-model question specifically — how often to meet, and how to structure minutes so they evidence oversight — see our guide to Article 20 board governance models and minute structure.

The Four Decisions, by Role

Grouping Article 20(1), Article 20(2) and the approval artefacts into four decisions is our synthesis, not a list any regulator publishes. But it is the shortest accurate statement of what cannot move down a delegation chain: approve the Article 21 measures; accept the residual risk position reported to you; commit the resources; undertake the training yourself.

Role	What changes for you
CIO / IT director	Your framework stays. Audit its delegation register for anything routing security-measure or security-policy approval to an executive role, and route it back. Then build the Article 21(2) measure register — the genuinely new work, and the largest line in the table above.
Compliance officer	Your evidence problem is dates and signatures, not content. Check the security policy carries an approval block naming the management body with a date, that residual-risk acceptance is written against stated criteria, and that a training record exists per director. ISO 27001 certification evidences a management system, not a board approval.
Board member	Four things are personally yours and cannot be delegated to the people who brief you. Ask for the measure register, the residual-risk position, the resourcing request and your own training date — and make sure the minutes record that you asked.

What to Do This Quarter

Two of these are document edits and cost almost nothing: strip the delegation path that lets an executive approve a security policy or measure, and add an approval block carrying the management body’s name and date to your policy on the security of network and information systems. The third is a calendar entry — board training, the one Article 20 obligation with no equivalent anywhere in IT governance practice, and therefore the one nobody has already done.

The measure register, mapping your existing controls against Article 21(2)(a) to (j) and marking the gaps, is the real project and the one worth resourcing properly. Everything else here is an amendment to a framework you already run.

Frequently Asked Questions

Do we need a separate NIS2 governance committee?
Generally, no. Nothing in Article 20 requires a dedicated body, and creating one risks moving decisions away from the management body where the Directive places them. A standing item on an existing risk or audit committee, reporting into the board, is the more defensible structure.

We are ISO 27001 certified. Is Article 20 covered?
Partly, and the part it misses is the important one. A certified information security management system gives you most of the Article 21 measure content and the documentation habits. It does not by itself produce a dated management-body approval, a director training record, or the personal liability position Article 20(1) attaches. The frequently quoted claim that ISO 27001 covers roughly 70% of NIS2 circulates without a traceable source — treat it as vendor shorthand, not a planning figure.

Can the CISO approve the measures if the board delegates it in writing?
Article 20(1) places approval with the management body and contains no delegation clause, in contrast to the Implementing Regulation’s explicit clause for residual-risk acceptance. [1][5] A written delegation does not obviously cure that, and it creates a record showing approval below board level. The conservative reading — keep the approval, delegate the preparation — costs one agenda item.

Does holding a COBIT or ISO/IEC 38500 qualification help?
For running the governance layer, yes. As evidence of NIS2 compliance it appears nowhere in the EU’s own mapping, and ISO/IEC 38500 is guidance addressed to governing bodies rather than a certifiable management system. It will not substitute for the Article 20(2) training record.

Does Implementing Regulation 2024/2690 apply to us?
Only if you are one of the eight digital and ICT service types in its scope. [5] For everyone else it is instructive, and supervisory authorities read it, but your binding detail comes from your member state’s transposition.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Directive (EU) 2022/2555 (NIS2) — Article 20 (governance), Article 21 (cybersecurity risk-management measures) and the Article 6 definitions, EUR-Lex
2. Directive (EU) 2022/2555, Article 20: Governance — article-level text, nis-2-directive.com
3. ISO/IEC 38500:2024, Information technology — Governance of IT for the organization, third edition, February 2024, prepared by ISO/IEC JTC 1/SC 40 — catalogue record and scope, ISO
4. ISO/IEC 38500:2024 — published preview containing the Foreword, Introduction, Scope and Clause 3 terms and definitions, including the delegation note at 3.1, ISO preview (PDF)
5. ENISA. Technical Implementation Guidance on Cybersecurity Risk Management Measures, version 1.0, June 2025 — reproduces the Annex to Commission Implementing Regulation (EU) 2024/2690, with non-binding guidance and the standards mapping. European Union Agency for Cybersecurity, enisa.europa.eu (PDF)
6. National Cyber Security Centre Ireland. Guidance on Cyber Governance for Management Board Members in NIS2 entities — section 3.2, governance versus management, ncsc.gov.ie (PDF)
7. ISACA. COBIT — Control Objectives for Information and Related Technologies — framework positioning and integration guidance, isaca.org