Under NIS2, the board must approve, oversee and be able to prove it

NIS2 places accountability for security where the decisions are made. The directive requires the management body to approve risk management, oversee it, undergo training itself, and be able to evidence what it has decided. This article sets out what that means in practice, and where the line runs between having documentation and having control.

Most boards have a settled routine for information security. Once a year a briefing appears on the agenda, usually from the head of IT or an outside supplier. The slides are mostly green, with a few amber items already in hand. The board asks a couple of questions, and the minutes record that the matter was noted.

That routine has been good enough for years. Under NIS2 it is not. Not because the technical requirements are dramatically higher, but because the directive moves a specific duty from the line organisation to the board table, and requires that the duty can be evidenced.

What the directive actually requires of management

Article 20 uses three words for the management body's role: approve, oversee, and be held liable. They mean three different things.

Approve is an active decision. The management body approves the risk-management measures; it does not merely receive them. That presupposes an approver who understands what is being approved, and a decision paper setting out the options that were weighed.

Oversee is a continuing duty. A decision taken in March says little about the position in November. Oversight means asking for status, comparing it with the plan, and reacting when the gap widens.

Liability means the duty survives delegation. The work can be delegated; responsibility for seeing that it is done cannot. How liability is enforced is left to national law, and the directive expressly leaves existing liability rules for public bodies and public officials untouched.

The competence requirement lands on people, not functions

Article 20 also sets a requirement that is still unusual: members of the management body must themselves undergo training, so that they can identify risks and judge what security measures mean for the services the entity provides. Entities are separately encouraged to offer comparable training to their staff on a regular basis. For the board it is an obligation; for everyone else it is an encouragement. Financial firms will recognise the pattern from DORA, which requires the management body to keep its own ICT knowledge current.

This is where the distance shows. Roger Ison-Haug, who owns and leads Berigo, has researched the relationship between the number of adverse cyber incidents and the competence of senior management. Among Norway's 50 largest companies on the Kapital list, one had executives with formal education in cybersecurity. In the Forbes Global 500 the figure was around ten out of 500. As he puts it: “There is a gap between senior executives' responsibility and their actual competence in cybersecurity.”

The point is not that directors should become technologists. They should not. But they own the strategic choices and the priorities, and that requires them to be capable clients and controllers: to know what to ask for, how to follow it up, and what a good answer sounds like.

The ten measures the board approves

Article 21 sets out the minimum measures. A board asked to approve them should know what the list contains:

  • policies on risk analysis and information system security
  • incident handling
  • business continuity, such as backup management, disaster recovery and crisis management
  • supply chain security, including the relationship with direct suppliers and service providers
  • security in acquisition, development and maintenance, including vulnerability handling and disclosure
  • procedures to assess whether the measures actually work
  • basic cyber hygiene practices and security training
  • policies on the use of cryptography and, where appropriate, encryption
  • human resources security, access control and asset management
  • multi-factor or continuous authentication, secured voice, video and text communication, and secured emergency communications, where appropriate

The requirement is not that everything be secured to the maximum. Article 21 asks for measures that are appropriate and proportionate, judged against the state of the art, the cost of implementation, the size of the entity and how exposed it is. The approach has to cover all hazards, including physical protection of the environment the systems sit in, not only digital attack.

Proportionality is a judgement, and a judgement has to be made by someone with the authority to make it. That judgement is what the board approves, not the list itself. A board that cannot describe the risk it has accepted has not, in any practical sense, approved anything.

Essential or important decides how you are supervised

The directive divides entities into essential and important ones, broadly by sector and size. The distinction matters little for which measures apply, since Article 21 covers both, and a great deal for how supervision is carried out.

Essential entities can be supervised on the authority's own initiative: on-site inspections, regular and targeted security audits, security scans, and requests for evidence that policies have been implemented. For important entities, supervision is in principle after the fact. Authorities step in when they have an indication or information pointing to non-compliance, typically after an incident or a report.

The difference is a practical one. An essential entity has to be able to produce its documentation without warning. An important entity usually has to produce it in the worst possible week: the one straight after an incident.

The clock runs regardless of what the board knows

Article 23 sets three deadlines for a significant incident. An early warning within 24 hours and a fuller notification within 72 hours, both counted from the moment the entity became aware of the incident, not from the moment it understands it. The final report is due within one month, but that month runs from the 72-hour notification, not from the incident. The authority may also ask for a progress report along the way.

Alongside notifying the authority or the CSIRT, the entity must inform the recipients of its services, without undue delay, of incidents likely to affect the service they receive. Telling customers is a duty in its own right, not something a regulator has to order.

Where the incident also involves personal data, a parallel 72-hour deadline runs to the data protection authority under Article 33 GDPR. Two regimes, two recipients, one incident. The directive expects the authorities to coordinate, and it rules out a NIS2 fine for conduct already fined under the GDPR. It relieves nobody of the duty to notify both.

So the assessment of what counts as significant, and the authority to notify, have to be settled before the incident happens. An organisation that convenes the board to decide whether to notify spends the deadline on the decision itself.

The difference between having documentation and having control

This distinction decides how an inspection unfolds. Documentation is a photograph of a decision that was taken. Control is the ability to take that same decision again, to the same standard, once the circumstances have changed.

Three questions separate them:

  1. Does the document describe how the organisation actually works, or how it intended to work?
  2. Can somebody other than the author act on it without calling the author?
  3. Does it record a decision, with an option that was rejected, or only a description?

Supervisory authorities can require evidence that policies have been implemented. The question is therefore rarely whether the organisation has a document. It is whether it can show the document works.

What a supervisory authority can do

The fine levels are the most quoted figures in the directive, and they are usually quoted a little loosely. Article 34 requires Member States to provide for maximum fines of at least EUR 10 million or 2 per cent of total worldwide annual turnover for essential entities, and at least EUR 7 million or 1.4 per cent for important entities, whichever is higher in each case. That is a floor under the ceiling, not an estimate of what any given fine will be.

The measures that arrive first are different ones. An authority can issue warnings, binding instructions to remedy the deficiency, orders to implement the recommendations of a security audit, orders to inform customers about a significant cyber threat, and orders to make aspects of the infringement public.

For essential entities the authority may also appoint a monitoring officer to oversee compliance for a defined period. And as a last resort, once the other measures have failed, a certification or authorisation can be suspended temporarily, and a person at chief executive or legal representative level can be temporarily barred from exercising managerial functions in that entity. Both last until the deficiency is remedied. Neither reaches non-executive directors as such, and neither applies to important entities. It is serious enough without amplification, and the precision is worth carrying into the boardroom along with the numbers.

What reaches the board in practice is simpler: whether it can show what it knew, when it knew it, and what it did about it.

Where this stands in Norway

The deadline for EU Member States was 17 October 2024. NIS2 is marked as EEA-relevant, and Norwegian implementation depends on the directive being incorporated into the EEA Agreement and then carried into national law. As of September 2026, NIS2 has not been incorporated into the EEA Agreement or implemented in Norwegian law. The Norwegian authorities have announced that NIS2 will be implemented through new legislation, coordinated with the CER Directive. No date has been set for when NIS2 will apply in Norway. The Norwegian Digital Security Act implements the first NIS Directive in Norwegian law and entered into force on 1 October 2025. The scope of NIS2 is considerably wider than the scope of the Digital Security Act.

One question will only be settled by the national implementation. The directive places the duties on the “management body”, a term that does not map neatly onto Norwegian company law, where responsibility is split between the board and the chief executive. Until that split is clarified, the safe reading is to treat approval, oversight and training as the board's and execution as the chief executive's. A board that has done so will not be caught out by the wording of the act.

For many organisations the requirements arrive ahead of the legislation. Customers, parent companies and public purchasers already write NIS2-derived clauses into contracts and tenders, and a supplier into a European group meets those requirements through the contract whatever Norwegian law says at the time. In practice the supply chain sets the deadline.

A board with this in place does not spend more time on security than other boards. It spends it differently: on fewer slides, and on more decisions that can still be evidenced a year later.