This document is a template provided as a starting point for your compliance documentation. It does not constitute legal advice and should be reviewed by a qualified legal professional before use. Viktoria Compliance accepts no liability for the use of this template.
NIS2 Cybersecurity Risk Assessment — Template
Customize Template
Fill in your organisation details below. The preview updates in real time.
Version 1.0.0 — Last updated 2026-04-25
1. Executive Summary
This Cybersecurity Risk Assessment ('Assessment') has been conducted by [companyName] in fulfilment of Article 21(1) and (2)(a) of Directive (EU) 2022/2555 (the 'NIS2 Directive'), and is intended to evidence the risk-based approach underpinning the cybersecurity risk-management measures adopted by [companyName]. [companyName] is classified as a [entityClassification] entity in the [sectorClassification] sector. The Assessment was conducted by [assessorName] under the supervision of [cisoName] using the [methodology] methodology, with an assessment date of 2026-04-26 and the next scheduled review on [reviewDate]. The findings, treatment plan and residual risk position summarised in this section are detailed in Sections 6–9.
2. Scope and Methodology
Scope: this Assessment covers the network and information systems supporting [companyName]'s essential or important services within the meaning of Annexes I and II of the NIS2 Directive, including supply-chain dependencies relevant under Article 22 and the cybersecurity measures listed in Article 21(2). Methodology: the Assessment follows [methodology] (typically ISO/IEC 27005 adapted for the all-hazards approach required by the NIS2 Directive, addressing physical, environmental and supply-chain threats alongside cyber threats). The methodology comprises six steps: context establishment, risk identification, risk analysis, risk evaluation, risk treatment, and risk monitoring and review. Out of scope: legacy systems scheduled for decommissioning before the next review date, where compensating controls and exit plans are documented separately.
3. Risk Criteria
Impact is rated on a four-point scale (1 Low, 2 Medium, 3 High, 4 Critical) across financial, operational, regulatory, reputational and data-subject dimensions, with the highest dimension determining the overall impact rating. Likelihood is rated on a four-point scale (1 Unlikely, 2 Possible, 3 Likely, 4 Almost Certain) considering threat capability, threat motivation, vulnerability exposure and existing controls. Risk score = Impact × Likelihood and maps to risk levels of Low (1–3), Medium (4–8), High (9–12) and Critical (13–16). Risk-acceptance criteria: Critical risks must be treated to High or below within thirty (30) days; High risks within ninety (90) days; Medium risks at the next planning cycle; Low risks may be accepted with sign-off by the CISO. Acceptance of any High or Critical residual risk requires sign-off by the management body.
4. Asset Identification
Assets in scope are inventoried and classified into four categories: information assets (databases, code repositories, document stores, including personal data within the meaning of Article 4(1) GDPR); technology assets (servers, endpoints, network devices, cloud workloads, identity systems, security tooling); operational assets (manufacturing, OT/ICS, building-control systems where applicable to the [sectorClassification] sector); and people and process assets (key roles, third-party dependencies, documented procedures). Each asset is recorded with: owner, location, classification (Confidential / Internal / Public), criticality (Critical / High / Medium / Low), and dependencies. The asset inventory is the foundation of this Assessment and is reviewed at least quarterly.
5. Threat Analysis
Threats are analysed across five categories aligned with the all-hazards approach of the NIS2 Directive: (a) cyber attacks (ransomware, credential theft, phishing, web application attacks, denial-of-service, supply-chain compromise); (b) human factors (insider error, insider malice, social engineering, lack of training); (c) system and software failure (hardware failure, software defects, capacity exhaustion, expiry of cryptographic material); (d) natural and environmental events (fire, flood, prolonged power loss, regional disruption); (e) third-party and supply-chain risks within the meaning of Article 22 (vendor compromise, dependency on critical software providers, geopolitical concentration risk). Threat actors are profiled by motivation, capability and observed activity using current threat intelligence, including bulletins from the national CSIRT and ENISA.
6. Vulnerability Assessment
Technical vulnerabilities are identified through a combination of automated vulnerability scanning, configuration review, penetration testing and code review, and are scored using CVSS v3.1 or later. Organisational vulnerabilities are identified through control reviews against the measures listed in Article 21(2) of the NIS2 Directive, training-completion data, audit findings, supplier-assessment results, and incident-history analysis. Critical and High technical vulnerabilities on internet-facing or business-critical systems are remediated according to a defined service level (typically fourteen (14) days for Critical, thirty (30) days for High). Persistent vulnerabilities that cannot be remediated within SLA are documented as accepted risks with compensating controls and reviewed at the next assessment.
7. Risk Analysis
For each significant pairing of threat and vulnerability, a risk statement is produced of the form 'There is a risk that <threat actor / event> will exploit <vulnerability> resulting in <impact on assets and data subjects>'. Each risk is analysed for likelihood and impact using the criteria of Section 3, taking account of existing controls. The output is the inherent risk register attached as Appendix B, prioritised by risk score. Risks affecting personal data are flagged for parallel handling under [companyName]'s GDPR Data Protection Impact Assessment process where the threshold of Article 35 GDPR is met.
8. Risk Treatment
Each identified risk is treated through one of four options: (a) Mitigate — implement or improve controls to reduce likelihood, impact or both, with a target residual risk score and a defined owner and deadline; (b) Transfer — transfer all or part of the risk through cyber insurance or contractual indemnities, recognising that liability for breaches of the NIS2 Directive cannot be transferred away from [companyName] as the regulated entity; (c) Accept — accept the residual risk with documented justification and sign-off in accordance with the risk-acceptance criteria of Section 3; (d) Avoid — discontinue the activity giving rise to the risk where the risk-reward balance is unacceptable. Treatment plans are tracked monthly by the CISO; missed deadlines and overdue actions are escalated to the management body.
9. Residual Risks and Acceptance
After treatment, the residual risk register is presented to the management body for formal acceptance in accordance with Article 20(1) of the NIS2 Directive. Residual risks rated Medium or below within risk appetite are signed off by the CISO; residual risks rated High or Critical require explicit acceptance by the management body, which may impose additional compensating controls or shorten the next review interval. The signed residual risk register is retained as evidence of the risk-based approach required by Article 21(1) and is made available to the supervisory authority [supervisoryAuthority] on request.
10. Recommendations and Next Steps
Priority recommendations are summarised in Appendix C with proposed actions, owners, target dates and expected impact on the residual risk position. Long-term recommendations include any structural improvements identified during this Assessment that exceed the current cycle: organisational changes, capability uplifts, technology modernisation, supplier consolidation. The next full risk assessment is scheduled for [reviewDate]; an interim review is triggered by any significant change to operations, threat landscape, regulatory environment, or material incident. The Assessment is owned by [cisoName] and signed off by the management body of [companyName].
This document is a template provided as a starting point for your compliance documentation. It does not constitute legal advice and should be reviewed by a qualified legal professional before use. Viktoria Compliance accepts no liability for the use of this template.