If a regulator called tomorrow and asked how you govern cyber risk, could you answer without calling IT?
In many organisations, the honest answer is no. The board probably has a slide from last quarter and a general sense that things are OK.
NIS2 is usually discussed as a security law, which is how it ends up on IT’s desk. But read the NIS2 carefully, and you’ll see that risk management is now an obligation held by the management body.
This accountability can not be delegated to IT.
We have written before about what NIS2 requires and how to approach compliance. This piece is narrower and aimed higher. It is for boards, executives, and owners who want to know what THEY need to be able to show.
Article 20(1) requires member states to ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for infringements.
Three separate duties sit in that sentence.
Article 20(2) adds a fourth.
Members of management bodies are required to follow training so they gain sufficient knowledge to identify risks and assess cybersecurity risk management. Entities are encouraged to offer similar training to employees. The obligation on directors themselves is the mandatory part.
So the list is actually:
What Article 20 establishes is that delegating the operational function does not delegate the governance function.
A board can hand over the work. It cannot hand over the responsibility for making sure the work is adequate, resourced, and reviewed.
This is the same principle we described in our piece on why every digital system needs an operating model. A system with no named owner is a system on borrowed time. NIS2 takes that idea and gives it legal force.
Article 21 requires appropriate and proportionate technical, operational and organisational measures, judged against the state of the art, the cost of implementation, the entity’s size, its exposure, and the likely severity of incidents.
It then lists ten categories that every in-scope entity must cover: risk analysis and information system security policies, incident handling, business continuity and crisis management, etc.
Notice what that list is. It is a standard of care moreso than a technical specification.
An organisation can suffer a serious attack and still be compliant, provided it can demonstrate that appropriate governance. An organisation can also own excellent security technology and fail Article 21.
Put simply, supervisory conversation will be focused primarily on documents.
A number of specific company fine figures circulate online. We are not going to repeat numbers we cannot verify, and we would gently suggest treating any article that leads with a dramatic fine total the same way.
What is documented is arguably more revealing.
On 8 July 2026, the European Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice of the European Union for failing to notify measures transposing NIS2 into national law. The Commission asked the Court to impose financial sanctions consisting of a lump sum and daily penalties running until each country notifies complete transposition.
Meanwhile, national authorities have moved from registration into active supervision, and regulators have begun publishing guidance aimed directly at boards. Ireland’s National Cyber Security Centre released guidance on cyber governance for management board members on 7 July 2026, written for CEOs, managing directors, CIOs and CISOs.
The regulator’s expectations of boards are already formed, whatever stage the national law has reached.
Since supervision is evidence-based, the useful question for a director is not whether the company is secure. It is what you could put on the table.
Seven documents. A board member should be able to locate each one without calling IT.

1. The scope and registration record. Are we in scope, as an essential or an important entity, in which member states, and who made that determination, and when? Plus proof of registration with the relevant national authority. In several countries, failing to register is a standalone breach separate from any security failure.
2. The approval record. Minutes showing that the management body approved the cybersecurity risk-management measures on a date, with the reasoning. Article 20(1) asks for approval as an act of governance. A policy that exists without a recorded board decision behind it does not evidence that the board approved anything.
3. The risk picture in business language. The current risk assessment covering the ten Article 21 categories, expressed in terms of services and consequences rather than vulnerabilities. It should show what has been mitigated and, importantly, what has been consciously accepted and by whom.
4. The director’s training record. Evidence that management body members have completed cybersecurity training. This is a direct obligation on the individuals under Article 20(2), and it is the one boards discover last.
5. The incident playbook, with names and clocks. NIS2 works on a 24-hour early warning, 72-hour notification, and one-month final report cycle. The document should name who declares an incident, who notifies the authority, who speaks publicly, and who can authorise taking systems offline. Most organisations would spend the first 24 hours deciding who is allowed to decide.
6. The supplier dependency list. Your direct suppliers and service providers, what each one can reach, and what you know about their security practices. Article 21 makes their weaknesses your regulatory problem.
7. The effectiveness evidence. Article 21 requires procedures to assess whether the measures actually work. Test results, audit findings, exercises, and a record of what was done about the gaps. Findings raised and never closed are worse than findings never raised.
If your organisation can produce all seven, the governance obligation is being met in substance.
We have spent 30 years building systems for regulated environments, and the pattern in front of us now is a familiar one. A technical obligation arrives, the organisation routes it to the technical department, and the part that actually determines the outcome sits somewhere else entirely.
NIS2 asks for clear ownership and evidence.
The good news for leaders is that this is achievable without becoming a security expert. Seven documents, one named owner for each, are reviewed on a schedule. If you want help mapping your scope and closing the gaps that carry the most enforcement risk, that is what our NIS2 practice does.
Start with the question we opened with. Ask your board whether they could answer a regulator without calling IT. The answer will tell you how much work is left.
Our goal is to help take your organization to new heights of success through innovative digital solutions. Let us work together to turn your dreams into reality.