NIS2 requires organizations to implement ten categories of cybersecurity risk-management measures (Article 21 of the directive), report significant incidents under a 24/72-hour regime, and ensure that management bodies personally oversee and approve these measures. This isn’t a list of recommendations – it’s a catalog of obligations that supervisory authorities can hold an organization to directly.
In this article we break these requirements down – what NIS2 is, who it covers, and most importantly: exactly what needs to be implemented in each key area. If you are just starting to organize this space, read our article on GRC – what is Governance, Risk & Compliance first.
What Is NIS2?
NIS2 (Directive (EU) 2022/2555 of the European Parliament and of the Council) is an EU regulation from 14 December 2022 that replaced the earlier 2016 NIS directive. It entered into force on 16 January 2023, and member states had until 17 October 2024 to transpose its provisions into national law.
The directive sets a common, minimum level of cybersecurity for organizations operating in sectors critical to the functioning of the economy and society across the European Union – regardless of which member state they operate in.
Why Was NIS2 Introduced?
The original 2016 NIS directive proved insufficient against the scale and pace of evolving cyber threats – too narrow a scope of covered entities, too much interpretive freedom left to member states, and a lack of real sanctions meant the level of cybersecurity varied significantly across EU countries.
NIS2 addresses these weaknesses by: significantly expanding the number of covered sectors and entities, introducing a specific, minimum catalog of required technical and organizational measures (instead of general recommendations), harmonizing the incident reporting regime, and – most keenly felt by boards – introducing real, personal management accountability for oversight of compliance.
Which Organizations Does NIS2 Apply To?
The directive covers public and private entities operating in highly critical sectors (including energy, transport, banking, healthcare, digital infrastructure, public administration) and other critical sectors (including manufacturing, postal services, waste management, digital service providers), classified as essential entities or important entities depending on sector and company size.
The detailed breakdown of sectors and size thresholds under the Polish implementation is covered in our KSC/NIS2 article – here, what matters more is what follows: exactly what obligations result from that classification. If you want to quickly check your organization’s status, use the free NIS2/KSC self-assessment tool.
What Are the Key Requirements of NIS2?
At the heart of the directive is Article 21, which requires the implementation of appropriate and proportionate technical, operational and organizational measures to manage cybersecurity risk. Proportionality means the scope and sophistication of these measures depends on the organization’s size, its degree of exposure to risk, and the potential severity of incidents – a small ICT service provider doesn’t need to implement exactly the same mechanisms as a large energy operator, but both must address every one of the areas below.
Article 21(2) lists ten categories of required measures:
Below we expand on the five areas that, in practice, generate the most implementation work.
Cybersecurity Risk Management
This is the foundation the rest of the catalog rests on – without a solid risk analysis, it’s impossible to select proportionate measures across the other nine areas. In practice, this means identifying critical processes and assets, assessing threats and vulnerabilities, and then documenting a link between every identified risk and a specific remediation measure. NIS2 treats this as a continuous process, not a one-off project – hence the requirement to regularly assess the effectiveness of implemented measures (point f).
Vendor and Supply Chain Security
An organization is responsible not only for its own infrastructure, but also for the quality of its vendors’ security practices – especially ICT service providers. In practice, this means: inventorying critical vendors, assessing their risk before signing a contract and cyclically afterward, including security requirements in contracts, and paying particular attention to high-risk vendors. This is one of the elements that most distinguishes NIS2 from the earlier NIS directive, where vendor risk wasn’t formalized in this way.
Incident Management
Article 23 of the directive introduces a harmonized, three-stage regime for reporting significant incidents: an early warning within 24 hours of detection, an incident notification within 72 hours with an assessment of its severity, and a final report within one month. This requires ready-made, rehearsed detection and escalation procedures – 24 hours isn’t enough time to figure out who’s responsible for what after the fact. How reporting works in the Polish implementation (System S46, CSIRT) is covered in our article on the KSC Register.
Business Continuity and Organizational Resilience
Point (c) of Article 21 explicitly requires backup management, disaster recovery plans, and crisis management. This area overlaps in practice with business continuity management (BCM) – an organization needs to know which processes are critical, what the acceptable downtime is (RTO/RPO), and what the plan is for switching to a backup environment in the event of a serious incident.
Management Accountability
This is one of the most groundbreaking elements of NIS2 compared to the earlier directive. Article 20 requires management bodies of essential and important entities to approve risk-management measures and oversee their implementation – not simply delegate the task to the IT department. The directive also introduces mandatory cybersecurity training for the board itself and the possibility of holding its members personally accountable for gross negligence, including the risk of a temporary ban from management functions in extreme cases.
How to Prepare Your Organization for NIS2
Practical implementation is best broken down into stages:
- Classification and gap analysis – determining the organization’s status and comparing current security posture against the ten areas of Article 21.
- Building or updating the risk management system – a risk register, security policies, linking risks to remediation measures.
- Addressing vendor risk – inventorying, assessing, and adding security clauses to contracts.
- Preparing incident reporting procedures – rehearsed, with clear ownership, capable of meeting the 24-hour deadline.
- Engaging the board – formal approval of policies, participation in training, establishing an oversight mechanism.
- Ongoing effectiveness reviews – NIS2 doesn’t end at implementation; it requires regularly checking whether measures actually work.
BCMLogic expert commentary: organizations most often neglect this last point – treating implementation as a one-off project closed out by an audit, instead of an ongoing, maintained process. The ten areas under Article 21 are a living system, not a checklist to tick off once a year.
NIS2 vs. KSC – What’s the Difference?
In other words: learning the requirements in this article means learning what applies across the entire European Union. The details of the Polish implementation – deadlines, fine amounts, the KSC Register process – are covered in our articles on KSC/NIS2 in Poland and the KSC Register. In the financial sector, the DORA regulation plays a similar role for ICT risk.
Common Mistakes When Implementing NIS2
- Treating NIS2 purely as an IT project – when Article 20 explicitly requires board engagement and accountability.
- Skipping effectiveness reviews (point f) – implementing safeguards without cyclically verifying they actually work.
- Superficial vendor assessment – a one-off questionnaire instead of ongoing monitoring of supply chain risk.
- No rehearsed incident procedures – the 24/72-hour deadlines require readiness, not improvisation after the fact.
- Confusing NIS2 with KSC – which makes it harder to understand which requirements are common across the EU and which are specific to the Polish implementation.
FAQ
How does NIS2 differ from the earlier NIS directive?
NIS2 significantly expands the scope of covered sectors and entities, introduces a specific, minimum catalog of required measures (Article 21) instead of general recommendations, harmonizes the incident reporting regime, and introduces real, personal board accountability.
Does NIS2 apply directly to my company?
Not directly – NIS2 is an EU directive that requires transposition into national law. In Poland, obligations arise from the National Cybersecurity System Act (KSC), which implements this directive.
How many security areas does Article 21 of NIS2 require?
Ten categories of measures, labeled (a) through (j) in the directive – from risk analysis and incident handling to supply chain security, cryptography, and multi-factor authentication.
Is the board really personally accountable for NIS2 compliance?
Yes. Article 20 of the directive requires management bodies to approve risk-management measures and oversee their implementation, and personal liability for board members is possible in cases of gross negligence.
Does NIS2 implementation end after a single audit?
No. The directive explicitly requires cyclical assessment of the effectiveness of implemented measures (Article 21(2)(f)) – it’s a continuous process, not a one-off project.
Summary
NIS2 isn’t a list of good advice – it’s a specific, enforceable catalog of ten security areas, a three-stage incident reporting regime, and explicitly assigned board accountability. The biggest practical mistake is treating it as solely an IT department’s task, when the directive is designed from the ground up as an organizational responsibility, approved and overseen at board level.
Read Also
- NIS2 2026 – Who Does the New Law Apply To and What Obligations Does It Impose?
- KSC Register – Who Must Register and How to Submit an Entry?
- GRC – What Is Governance, Risk & Compliance and How Does It Work in Practice?
See What This Could Look Like for Your Organization
If your organization is organizing risk, vendor and incident management around NIS2 requirements, it’s worth seeing what this looks like on a single GRC platform. BCMLogic Solutions helps financial and technology companies manage operational risk, business continuity and regulatory compliance – in line with ISO 22301, ISO 27001 and requirements such as DORA and NIS2/KSC.
