Why this lands on the board's table

For most of the last two decades, cybersecurity was something boards received a report about. The CISO presented a slide deck once or twice a year, the audit committee asked a few questions, and the matter was minuted and closed. NIS2 and DORA end that arrangement. Both frameworks place responsibility for cyber risk management explicitly on the management body, and both expect that body to understand, approve and oversee what the organisation is doing, not simply to be informed of it.

I spend a great deal of time in boardrooms across Greece, the Gulf and the United States, and the most common reaction I hear is a version of: "We have a CISO, we have ISO 27001, surely we are covered." That is a reasonable starting point, but it is not the same thing as what the regulators are asking for. Below is how I explain the difference, and what I recommend boards actually do.

What the two frameworks say, in plain terms

NIS2 (Directive (EU) 2022/2555) applies to a much broader set of sectors than its predecessor, including energy, transport, banking, health, digital infrastructure, ICT service management, public administration and a long list of "important" sectors such as manufacturing, postal services and food. Member states have transposed it into national law, so the precise obligations depend on the jurisdiction, but the core is consistent. Article 20 requires management bodies to approve the cybersecurity risk-management measures, oversee their implementation, and be held liable for infringements. It also requires members of management bodies to follow training. Article 21 sets out the minimum measures, from risk analysis and incident handling to business continuity, supply chain security, cryptography and access control. Article 23 introduces staged incident reporting: an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month.

DORA (Regulation (EU) 2022/2554) is a regulation, not a directive, so it applies directly across the EU financial sector, and it has applied since 17 January 2025. It covers banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and others, and it brings critical ICT third-party providers under direct oversight. Article 5 is explicit: the management body defines, approves, oversees and is responsible for the ICT risk management framework, and bears ultimate responsibility for managing ICT risk. DORA adds structured requirements for ICT-related incident classification and reporting, digital operational resilience testing (including threat-led penetration testing for in-scope entities), and detailed contractual and register requirements for ICT third parties.

Neither framework is primarily about technology. Both are about governance, accountability and evidence.

The shift: from being informed to being accountable

The practical consequence is that a board can no longer delegate the topic and consider its duty discharged. Under NIS2, national authorities can, in defined circumstances, hold members of the management body personally accountable, and for essential entities can even seek temporary bans on individuals exercising managerial functions. Under DORA, supervisors will look for evidence that the management body has genuinely engaged with ICT risk: that it approved the strategy, allocated budget, reviewed incidents and understood its third-party exposure.

In my experience, the question a supervisor or an investigator asks after an incident is rarely "did you have a policy?" It is "show me how the board knew, what it decided, and when." The minutes, the risk appetite statement and the record of challenge become the evidence.

What boards actually need to do

Strip away the consultancy language and the work comes down to a short list. I recommend boards treat these as standing agenda items rather than a one-off compliance project.

• Confirm scope and entity classification. Establish, in writing, which entities in the group fall under NIS2 (essential or important) and which fall under DORA, and in which jurisdictions. Groups that span several member states and non-EU locations frequently get this wrong.

• Approve a cyber risk appetite. Not a generic statement, but one that says which services cannot be down for how long, which data cannot leave the organisation, and what level of third-party concentration is tolerable.

• Own the risk-management framework. The board should formally approve the framework and the measures required under NIS2 Article 21 or DORA's ICT risk management requirements, and review them at a defined cadence.

• Get trained, and record it. Board members need enough fluency to challenge management. Short, scenario-based sessions work far better than slideware, and the attendance record is itself evidence.

• Rehearse the reporting clock. The 24-hour, 72-hour and one-month NIS2 reporting stages, DORA's incident reporting timelines and the GDPR's 72-hour personal data breach notification can all run at once. Someone must know who decides, who drafts and who signs.

• Look hard at the supply chain. Both frameworks expect you to know your critical ICT providers, to have contractual rights that work in practice, and to have exit options. DORA in particular requires a register of information covering ICT third-party arrangements.

• Fund it deliberately. If the board approves the framework but not the resources to implement it, that gap will be visible after an incident.

The questions I encourage directors to ask

Directors do not need to become engineers. They do need to ask questions that expose whether the organisation is resilient or merely documented. The ones I find most revealing are:

• If our most important service went down tonight, who would call me, and how long before I knew?

• What are our three most critical third-party dependencies, and what happens if one of them fails for a week?

• When did we last test our recovery from backup end to end, and did it work within the time we promised the business?

• Which incidents in the last twelve months came close to being reportable, and what did we learn?

• Who has privileged access to our crown-jewel systems, and how often is that list reviewed?

If the answers are vague, the gap is not a technology gap. It is an oversight gap, and that is precisely what these regulations target.

Common mistakes I see

The first is treating NIS2 and DORA as separate projects run by separate teams. For a financial group that also operates digital infrastructure or other in-scope services, the overlap is significant, and duplicated controls, inconsistent incident classification and conflicting reporting chains create real risk during a crisis. DORA is generally treated as the more specific regime for the financial entities it covers, but the group still needs one coherent view.

The second is equating certification with compliance. ISO 27001 is a strong foundation, but it does not by itself demonstrate management-body accountability, threat-led testing or the reporting discipline these frameworks require.

The third is leaving the board out of exercises. I have run tabletop exercises for a major banking group where the technical response was excellent, but the executive layer had never practised the decision of whether and when to notify a regulator, a customer base or the market. That decision cannot be improvised at three in the morning.

A practical first 90 days

For a board starting from a policy-heavy, evidence-light position, I suggest a simple sequence. In the first month, confirm scope, appoint a clear executive owner and commission an honest gap assessment against the relevant articles. In the second month, approve a risk appetite and a remediation roadmap with named owners and budget, and complete a first board-level training session. In the third month, run a realistic tabletop exercise that includes the regulatory reporting decision, and review the critical third-party register. After that, put cyber resilience on the agenda at every scheduled meeting, even if only for fifteen minutes.

The bottom line

NIS2 and DORA are not asking boards to become security experts. They are asking boards to govern cyber risk the way they already govern financial and legal risk: with a stated appetite, informed challenge, adequate resources and a record of decisions. The organisations that handle this well are not the ones with the thickest policy binders. They are the ones whose directors can explain, calmly and specifically, what would happen on the worst day, and what they have done to make it survivable.