NIS2 (Directive (EU) 2022/2555) has been a headline topic in European information-security publications for two years now, and most of what has been written focuses on the breadth of the scope. That matters — many more organisations are in-scope than were under the original NIS Directive — but it underplays what is genuinely different in substance.
For organisations that already have a working information security management system, much of NIS2 reads as a reformulation of existing good practice. Risk management, incident handling, business continuity, supply chain security — these are not new categories of requirement. An organisation with a mature ISMS will find that perhaps 70-80% of the NIS2 control set is already covered by existing controls.
What is new, in our reading, breaks into three categories.
First, the personal accountability provisions for senior management (Article 20). Under NIS2, members of management bodies of essential and important entities can be held personally responsible for ensuring compliance with the cybersecurity risk-management requirements. This is a significant shift from the original NIS Directive, where accountability flowed primarily to the legal entity. In practice, it means the board and executive committee need direct involvement in security governance in a way many of them have historically delegated.
Second, the incident-notification timelines (Article 23). The 24-hour early-warning and 72-hour incident-notification timeline is tighter than what most organisations have rehearsed for. The 24-hour clock starts at "becoming aware" — a definition with substantial interpretation latitude, but a high-stakes one to test in a real incident. We have run tabletop exercises with clients where simply identifying when the 24-hour clock should be deemed to have started took longer than the 24 hours themselves.
Third, the supply-chain documentation expectations (Article 21(2)(d)). The requirement to assess the cybersecurity practices of suppliers, and to document the assessment, is not new in spirit but is new in degree. NIS2-essential entities are increasingly expected to maintain a current supplier-risk register with ICT-specific assessment, and to incorporate supplier-security clauses into procurement contracts. Most clients we work with underestimate the scale of this work — the supplier inventory is often larger than the security team realises, and applying the methodology to every supplier is a substantial multi-month workstream.
What is repackaged: most of the technical control categories in Article 21(2). The list reads as a competent summary of mainstream information-security practice, and any organisation with a working ISO 27001 ISMS will find that the technical controls are substantially mapped. What changes is the documentation expectation and the regulatory traceability — the controls have to be documented in a form that survives regulatory scrutiny.
Our practical recommendation for in-scope clients without a mature ISMS: treat NIS2 as the opportunity to build an ISO 27001-aligned management system, with NIS2 documentation as a derivative artefact. The standalone NIS2 documentation approach produces a document set that exists for the regulator and is updated only when prodded. The ISO 27001 approach produces a management system that operates and produces the NIS2 documentation as a by-product.
Our recommendation for in-scope clients with a mature ISMS: a focused gap analysis against the three categories above (personal accountability, incident-notification timeline, supply-chain documentation) is normally sufficient to identify the residual work. The other 70-80% of NIS2 requirements you already meet.
We have published a downloadable detailed mapping of NIS2 Article 21 requirements against ISO 27001:2022 controls on the press page. It is available without registration.