Decree No. 409/2025 Coll. Places risk analysis first: it is item No. 1 of the 13 mandatory security measures under Act No. 264/2025 Coll. Without a performed and documented risk analysis, you cannot claim compliance with NIS2. The regulator (NÚKIB) will require it as one of the first documents during an inspection.
Good news: risk analysis is not rocket science. With the right methodology and a structured template, even an internal team without specialised training in cybersecurity can handle it. This article will guide you through the entire process.
Why risk analysis is the foundation of NIS2 compliance
NIS2 takes a systematic approach to security: first understand your risks, then implement proportionate measures. This approach is reflected in the structure of Decree 409/2025 Coll., other areas of measures (access control, cryptography, incident detection...) all stem from the conclusions of the risk analysis.
In practice, this means that without a risk analysis:
- Do you know which measures are critical for you and which are above standard?
- You cannot justify why you chose specific security measures.
- During a NÚKIB inspection, you will not have the legally required documentation.
- You risk investing in less critical areas while neglecting key risks.
Risk analysis methodology for NIS2
We recommend a five-step process that fully complies with the requirements of Decree 409/2025 Coll. And respects international standards (ISO 27005, NIST SP 800-30).
Step 1: Asset Identification
First, you must know what you are protecting. Compile an inventory of assets relevant to your key services (see our NIS2 audit guide). For each asset, record:
- Asset name and description
- Asset owner (responsible person)
- Classification: confidentiality / integrity / availability (scale 1-5)
- The total value of the asset (average or maximum of three values)
Examples of assets: production SCADA system, customer database, email server, VPN access, data backups, process documentation.
Step 2: Threat Identification
For each asset or group of assets, identify the relevant threats. A threat is a potential cause of an undesirable event. Use threat catalogues, for example, the NÚKIB catalogue or the ENISA Threat Landscape.
Typical threat categories for regulated entities:
- Cyber attacks: ransomware, phishing, DDoS, exploitation of vulnerabilities, man-in-the-middle
- Internal threats: employee error, intentional damage, failure to comply with policy
- Physical threats: theft of equipment, unauthorised access to the server room, fire, flood
- Technical failure: hardware failure, software error, power outage
- Supply risk: compromised supplier (supply chain attack), SaaS service outage
Step 3: Identification of vulnerabilities
A vulnerability is a weakness that a threat can exploit. For each threat, identify the vulnerabilities in your environment:
- Unpatched software (missing patch management)
- Weak or shared access credentials
- Missing multi-factor authentication (MFA)
- Unencrypted data transmission
- Insufficient employee awareness of phishing
- Lack of network segmentation
- Improperly configured access rights (principle of least privilege violated)
Step 4: Risk Assessment (Probability × Impact)
For every combination of asset, threat and vulnerability, assess the risk. We use a qualitative scale of 1–5:
- Probability (P): 1 = very low, 2 = low, 3 = medium, 4 = high, 5 = very high
- Impact (D): 1 = negligible, 2 = low, 3 = medium, 4 = high, 5 = catastrophic
- Risk value (R): R = P × D (resulting value 1–25)
Prioritisation based on result:
- R = 1-5: Low risk: accept or monitor
- R = 6-12: Medium risk: remediation plan, implementation within 12 months
- R = 13-19: High risk: immediate measures, implementation within 6 months
- R = 20-25: Critical risk: priority action, implementation within 3 months
Step 5: Selection of measures and acceptance of residual risk
For each risk, decide on a management strategy:
- Reduce: Implement measures that reduce the likelihood or impact (MFA, encryption, training...).
- Transfer: Insure yourself and transfer the risk to the supplier (SLA, cyber risk insurance).
- Avoid: Discontinue the activity or system that poses a risk.
- Accept: Consciously accept residual risk (must be documented and approved by management)
Examples of specific risks for different sectors
Healthcare
- Ransomware attack on hospital information system → disruption of patient care (R=25 - critical)
- Leak of medical documentation via an unsecured connection (R=20 - critical)
- Failure of backup systems (R=15 - high)
Energy and Industry
- Compromise of OT/SCADA systems via IT/OT interfaces (R=25 - critical)
- Attack on suppliers with access to control systems (R=20 - critical)
- Physical access by an unauthorised person to the control room (R=12 - medium)
Digital infrastructure and IT services
- DDoS attack on the operation of key services (R=20 - critical)
- Compromise of customer data in cloud storage (R=20 - critical)
- Third-party failure (SaaS provider) without a backup plan (R=16 - high)
What a risk analysis must contain according to Decree 409/2025
The decree does not require a specific format, but the output documentation must demonstrate:
- A systematic approach to identifying and assessing risks
- Taking account of the specifics of your sector and environment
- Linking risks to specific assets and key services
- Risk mitigation plan for identified risks
- Documented approval by the organisation's management (residual risk must be approved by a statutory representative).
- Document processing date and version
NIS2 Risk Analysis Template (Excel)
We have prepared a clear Excel template containing:
- Page 1: Asset Inventory: Table for asset inventory with CIA classification
- List 2 - Risk Register: Asset, threat, vulnerability, P × D calculation, resulting value
- List 3: Action Plan: Prioritised list of remedial measures with deadlines and owners
- List 4 - Approval: Overview of residual risks for management approval
You will receive the template after registering on secureon.cz SecureOn.cz or directly via the online audit tool on nis2ok.czwhere risk analysis is part of the structured NIS2 compliance process.
How to keep risk analysis up to date
A risk analysis is not a one-off document: the law requires regular review. We recommend:
- Annual inspection: Complete inspection of the entire risk analysis, reassessment of all risks
- After every security incident: Update of affected risks and measures
- In case of environmental changes: New system, new supplier, reorganisation, new location
- Following regulatory changes: Update of the methodology and threat catalogue
Version and archive every update: the regulator may require proof of your security status development history.