Understanding the river¶
NIS2 expects measures that are appropriate and proportionate. That means understanding two things: what the law requires, which is the regulatory current, and what your own risks demand, which are the hazards in your particular crossing. You cannot build the right vessel until you understand both.
What the law requires¶
Article 21 sets out mandatory minimum measures for every entity within scope. These are not optional and not something to postpone. They include risk analysis and security policies, incident handling capabilities, business continuity and crisis management, supply chain security, secure development practices, assessment of control effectiveness, encryption, human resources security, access control and asset management, multifactor or continuous authentication, and secured communications, including emergency systems where relevant.
Article 20 adds governance requirements. These include board approval and oversight of security measures, management accountability for failures, training for leadership and staff, and participation in coordinated vulnerability disclosure programmes.
Article 23 defines incident reporting timelines. The law requires an early warning within 24 hours of becoming aware of an incident, a detailed notification within 72 hours, and a final report within one month. These are legal obligations with specific deadlines.
Some sectors have additional expectations beyond this baseline. Energy may need operational technology controls, healthcare may have patient safety considerations, and digital infrastructure providers may have availability guarantees. Check with your supervisory authority for sector specific requirements.
What specific risks demand¶
Once the legal current is mapped, you must chart your own hazards. Identify the most likely threats in your sector, like ransomware in healthcare, DDoS attacks on infrastructure, supply chain compromises in manufacturing. Consider which assets are most critical. Evaluate what would cause severe disruption and identify single points of failure (systems and personnel).
Analyse likelihood and impact together. A theoretical, low-impact threat can be noted, but a probable threat with cascading consequences requires immediate attention. Assess dependencies: what breaks when a single system fails? Consider both cyber threats and operational disruptions (vendor and supply chain risks).
Plan treatments that map risks to controls. NIS2 mandatory measures cover many common risks, but where baseline controls are insufficient, add proportionate measures. Document any residual risks you consciously accept.
Compare current state to requirements¶
Conduct a structured gap analysis in three areas.
Technical gaps reveal missing or weak controls, such as missing or weak security controls, insufficient monitoring or logging, weak or absent authentication mechanisms, inadequate encryption of sensitive data, and incomplete or untested backup and recovery capabilities. Be specific. For example, “no MFA on administrative accounts” is far more actionable than “authentication needs improvement”.
Organisational gaps highlight missing or outdated policies and procedures, insufficient governance or unclear responsibilities, lack of tested incident response capabilities, poor security awareness, and incomplete asset inventories that leave you uncertain about what you are meant to protect.
Compliance gaps focus on NIS2-specific requirements, such as missing incident reporting procedures, incomplete supply chain security assessments, inadequate documentation to demonstrate compliance, and insufficient board oversight or evidence of governance.
Prioritise remediation based on risk and effort, and develop a roadmap with realistic timelines and dependencies.
Output¶
By the end of this stage, you have a regulatory requirements matrix, a risk register, a gap analysis, and a prioritised remediation plan.