Board Cyber Governance: What NIS2, DORA and the UK Code Require

Cyber security used to reach the board as an IT update. It now arrives as a legal obligation, and in two regimes it attaches personally to the people in the room. For directors, audit committee members and the finance professionals who prepare their papers, the question has shifted from whether the board is informed to whether it can evidence that it governed. Our CPD course library covers governance, risk and compliance.

NIS2 puts the duty on the management body

The EU's NIS2 Directive is the most direct change. For entities in scope, the management body must approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for failures to comply. Members of management bodies are also required to undergo training, and entities are expected to offer comparable training to staff.

Read that carefully, because it is unusual. The obligation is not to have measures; it is for the board to approve them, supervise them, and be trained. A board that received a presentation and noted it has not discharged an approval duty. Our guide to NIS2 for finance teams sets out the scope questions.

DORA does the same for financial entities

For EU financial entities, the Digital Operational Resilience Act places ultimate responsibility for the ICT risk-management framework with the management body. Again the duty is active: defining, approving, overseeing and being accountable, not simply being briefed.

The two regimes overlap in practice, and a financial entity operating across several member states may be in scope of both. The useful question is not which applies but whether the board's minutes would satisfy either.

The UK route is through internal control

The UK has no equivalent cyber statute, and it reaches the same place by a different road. Under the 2024 UK Corporate Governance Code, Provision 29 requires the board to make a declaration on the effectiveness of material controls, applying to financial years beginning on or after 1 January 2026.

Where IT controls are material to financial reporting — and in most organisations they are — a cyber failure is a control failure, and the declaration has to be supportable. That makes evidence of control operation, not assurance that risk was discussed, the relevant output. The audit side of this is covered in cyber risk in the audit.

What good board reporting actually contains

Most cyber board packs report activity: training completion percentages, phishing test results, patches applied. Those are inputs. A board exercising oversight needs measures that would have predicted an incident.

• Detection coverage and hours. What is monitored, by whom, and at what times. A board that does not know whether monitoring runs overnight does not know its exposure.
• Dwell time assumptions. How long would unusual activity plausibly go unnoticed, and what evidence supports that estimate.
• Restore testing. Not whether backups are taken, but when a restore was last performed, how long it took, and what failed.
• Privileged access review. When administrative accounts were last reviewed, by whom, and what exceptions arose.
• Third-party and connected-entity exposure. Which external connections exist and what a compromise at the other end would reach.
• Unsupported systems holding personal data. A count, with a replacement plan and dates.

Why a risk register is not a defence

The 2021 attack on Ireland's Health Service Executive is the case study every board should read, because the governance was present on paper.

Cyber risk sat on the corporate risk register. The audit and risk committee was briefed in February 2020 and again in March 2021, two months before the attack. Internal audits in 2018 and 2019 had identified unsupported software and weak backup standards, and those findings were accepted. Monitoring nevertheless ran 8am to 6pm on weekdays, and an infection on 18 March went undetected until ransomware was executed on 14 May.

Every element of conventional oversight was in place. What was missing was any mechanism that converted an accepted audit finding into a completed remediation with a date and an owner. That is a governance failure rather than a technical one, and it is the failure a board is uniquely placed to prevent.

Questions a committee can ask without technical expertise

Boards often hesitate here because the subject feels specialist. It is not, if the questions are about management rather than technology.

Which recommendations from our last security audit remain open, and what are their dates? When did we last test a restore, and how long did it take? If our largest connected partner were compromised tonight, what of ours would be reachable? Who would make the decision to disconnect our network, and have they practised it? And which of our systems still hold personal data on unsupported software?

None of those requires knowing what a firewall is. All of them produce answers a board can hold management to.

Frequently asked questions

Does the board need a cyber expert among its members?

Neither NIS2 nor the UK Code requires a named cyber expert. What they require is approval, oversight and, under NIS2, training of management body members. Access to expertise matters; a dedicated seat is not mandated.

Can cyber oversight be delegated to the audit committee?

Committee delegation is normal and sensible, but it does not transfer the management body's duties under NIS2 or DORA. The board remains accountable, so the reporting line back from committee to board has to be real.

What should minutes record?

Enough to show the duty was discharged: what was approved, on what information, what challenge was made, what actions were set, with owners and dates, and how previous actions were followed up. Noting a presentation is not evidence of approval.

How does this interact with the accounting consequences of a breach?

A serious incident creates provisions, contingent liabilities and possible impairment, which the board approves through the financial statements. We cover that in accounting for a cyber incident.