Read NIS2 only as a security checklist and its most important change is easy to miss. The directive does not simply ask organisations to improve controls. It connects those controls to management approval, oversight, training, business continuity, supplier relationships and evidence of effectiveness.
The boardroom is now part of the control environment
Article 20 requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures taken to comply with Article 21, oversee their implementation and undertake training. Member States must also ensure that management bodies can be held liable for infringements by the entity.
That changes the practical question. It is no longer enough to ask whether the security team has a policy. Leadership needs a defensible way to understand which risks matter, which measures have been approved, whether they work and how weaknesses are escalated.
Cybersecurity becomes a recurring management cycle: understand, decide, fund, oversee, test and improve.
Article 21 crosses organisational boundaries
The measures listed in Article 21 make the cross-functional nature of the work explicit. They cover risk analysis and information-system security, incident handling, business continuity and crisis management, supply-chain security, secure acquisition and development, vulnerability handling, evaluation of effectiveness, cyber hygiene and training, cryptography, human resources, access and asset management, and—where appropriate—multi-factor authentication and secure communications.
No single department owns that whole list. Procurement shapes supplier requirements. Legal teams translate obligations into contracts and governance. Operations protects continuity. Human resources supports role clarity and training. Technical teams design and run controls. Management connects those parts and decides what level of risk the organisation can justify.
Where contracts create false comfort
One misunderstanding I encounter repeatedly is the belief that a contract assigning responsibility to an external service provider also removes the company’s own responsibility. It does not do so by itself. A contract can allocate duties, remedies and reporting obligations, but the company still needs to understand the dependency, define its expectations, request appropriate evidence and oversee the resulting risk.
Five questions I would put in front of management
- 01
Which services and operations are truly in scope?
Start with critical services, dependencies, data and decision points—not with a generic inventory of policies.
- 02
Who approves the measures and who oversees whether they work?
Name decision rights, reporting lines and escalation paths. “IT is responsible” is not a governance model.
- 03
What evidence would withstand scrutiny?
A policy may show intent. Testing records, decisions, incidents, training, supplier reviews and corrective actions show whether the system operates.
- 04
How does supplier risk enter procurement and contracts?
Critical dependencies need criteria, due diligence, contractual expectations, monitoring and a response when assurance is weak.
- 05
How do incidents and continuity decisions reach leadership?
Reporting deadlines matter, but so do thresholds, rehearsed roles and the ability to make fast decisions with incomplete information.
Compliance is an outcome of a working system
A mature response to NIS2 should leave behind more than a compliance folder. It should create a common language for risk, a visible map of accountability, better supplier decisions, tested continuity arrangements and a reliable chain of evidence.
This is why I see NIS2 as a management redesign. The directive may begin with cyber risk, but implementation reveals how the organisation actually governs decisions across functions. The strongest programmes will use that visibility to improve resilience—not only to demonstrate conformity.
Primary sources