Can I reuse my GDPR or ISO 27001 risk assessment for NIS2?

Yes, there's significant overlap. If you already have ISO 27001 risk assessments, you can reuse much of that work for NIS2, though you must ensure critical services are specifically addressed. The main difference is focus: NIS2 concentrates on risks to critical service continuity and societal impact, while ISO 27001 covers all information assets and GDPR focuses on personal data protection. You can maintain one integrated risk assessment that meets multiple requirements.

What's the difference between probability and impact in risk assessment?

Probability is how likely a threat is to occur (typically rated 1-5 or Low/Medium/High), based on factors like threat actor capability, existing vulnerabilities, and current controls. Impact is the consequence if the threat does occur (also rated 1-5), considering service disruption duration, safety implications, financial costs, reputational damage, and regulatory penalties. Risk level is typically calculated as Probability × Impact, helping you prioritise which risks to address first.

Do I need special software to conduct a NIS2 risk assessment?

No, you can use spreadsheets for basic risk assessments. However, dedicated GRC (Governance, Risk, and Compliance) software significantly helps with tracking risks, documenting dependencies, assigning actions, monitoring implementation, and generating reports. Software becomes especially valuable when managing risks across multiple critical services, keeping assessments up to date, and demonstrating compliance to authorities. The complexity and size of your organisation will determine whether software is a good investment.

What are the main steps in a NIS2 risk assessment?

The seven main steps are: 1) Map your critical services and their importance, 2) Identify all supporting IT/OT systems and processes, 3) Map internal and external dependencies including suppliers, 4) Identify realistic cyber, physical, and human threats, 5) Assess probability and impact for each threat, 6) Determine risk treatment (mitigate, transfer, accept, or avoid) and create action plans, 7) Document everything and establish monitoring for regular updates. Each step builds on the previous one to create a comprehensive view of your risk landscape.

Who should be involved in the risk assessment process?

Risk assessments should involve multiple stakeholders: operations staff who understand critical services and their importance, IT and OT teams who manage the technical systems, business leaders who can prioritise risks and allocate resources, procurement or vendor management for supply chain risks, and security professionals to identify threats and controls. Avoiding siloed assessments by security teams alone ensures the assessment is realistic, comprehensive, and leads to actionable improvements.

What defines a critical service under NIS2?

A critical service is one whose disruption would have significant negative consequences for society, the economy, or public safety. This includes services essential for maintaining critical societal or economic activities. When identifying critical services, consider who depends on them, what would happen if disrupted for various time periods (1 hour, 4 hours, 24 hours, 1 week), and any regulatory or contractual service level obligations. The key test is whether the service is essential or important for the sectors and society you serve.

How detailed should my risk assessment be?

Your risk assessment should be detailed enough to drive meaningful security improvements but not so detailed that it becomes unmanageable. For critical services, be very specific about threats, systems, and dependencies. For supporting systems, you can group similar items. Avoid generic threats like just 'ransomware'—instead specify 'ransomware targeting SCADA servers in water treatment plant.' The level of detail should match the criticality: highest detail for critical services, moderate detail for important supporting systems, lighter detail for less critical areas.

What happens if I don't conduct a proper NIS2 risk assessment?

Failure to conduct proper NIS2 risk assessments can result in significant penalties: up to €10 million or 2% of global annual turnover for essential entities, and up to €7 million or 1.4% of turnover for important entities. Beyond financial penalties, there's personal liability for management, reputational damage, and most importantly, increased likelihood of security incidents that could disrupt your critical services and harm the people and organisations that depend on them. The assessment is required compliance, not optional.

NIS2 › NIS2 Compliance

NIS2 Risk Assessment: Complete Guide to Compliance

Q: How often should I update my NIS2 risk assessment?

You should conduct a full review at least once per year. Additionally, update your assessment whenever there are significant changes such as deploying new critical systems, changing service providers, experiencing a security incident, becoming aware of new major threats, or undergoing organisational restructuring. Some organisations use a rolling quarterly review to cover the entire organisation annually without overwhelming resources.

Learn the 7-step process for conducting NIS2-compliant risk assessments. Practical examples, templates, and tools to protect your critical services and meet regulatory requirements.

A flat vector illustration showing a navy blue shield with a 3×3 risk matrix in pastel colours — green, yellow, and red — representing low, medium, and high risk levels. Surrounding the shield are icons for compliance checklists, document search, risk monitoring, continuous review, and a bar chart. The text

The NIS2 Directive requires organisations in critical and important sectors to conduct thorough risk assessments of their cybersecurity posture. This isn't just a compliance checkbox—it's about systematically understanding where your organisation is vulnerable and taking concrete steps to protect your critical services.

In this guide, we'll walk through the complete process of conducting a NIS2-compliant risk assessment, from identifying your critical services to creating actionable risk mitigation plans. We'll use practical examples throughout to show exactly how this works in practice.

What is a NIS2 Risk Assessment?

A NIS2 risk assessment is a systematic process for identifying, analysing, and evaluating cybersecurity risks to your organisation's critical services and infrastructure. It's one of the core requirements in Article 21 of the NIS2 Directive.

The assessment helps you understand:

Which services are critical to your operations
What systems and processes support these services
What threats could disrupt these systems
How likely these threats are to occur
What the impact would be if they did occur
What controls you need to implement to reduce risk

Unlike a general information security risk assessment, a NIS2 risk assessment specifically focuses on risks that could affect the continuity of your critical services and, by extension, the sectors and society you serve.

Who Must Conduct NIS2 Risk Assessments?

If your organisation is classified as an essential or important entity under NIS2, you must conduct regular risk assessments. This includes organisations in sectors such as:

Energy (electricity, oil, gas, hydrogen)
Transport (air, rail, water, road)
Banking and financial market infrastructure
Health (healthcare providers, research, pharmaceuticals)
Digital infrastructure (DNS, cloud computing, data centres)
Public administration
Space
Waste management
Manufacturing (critical products)
Food (production and distribution)
Postal and courier services

The key criterion is whether your organisation provides services that are essential or important for maintaining critical societal or economic activities. If you're unsure whether NIS2 applies to you, consult your national implementation of the directive.

NIS2 Risk Assessment vs Other Risk Assessments

You might already be conducting risk assessments for other frameworks like GDPR, ISO 27001, or general cybersecurity. Here's how NIS2 risk assessments differ:

Aspect	NIS2 Risk Assessment	GDPR DPIA	ISO 27001 Risk Assessment
Primary Focus	Critical service continuity	Personal data protection	Information security
Scope	Critical services and their dependencies	High-risk personal data processing	All information assets
Impact Focus	Service disruption, societal impact	Rights and freedoms of individuals	CIA (Confidentiality, Integrity, Availability)
Frequency	Annually + when significant changes	When required for high-risk processing	Regularly (at least annually)
Mandatory Reporting	To authorities if required	To supervisory authority in some cases	Not mandatory

The good news is that much of the work overlaps. If you already have ISO 27001 risk assessments, you can reuse significant portions for NIS2, though you'll need to ensure critical services are specifically addressed.

The 7-Step NIS2 Risk Assessment Process

Here's the comprehensive process for conducting a NIS2-compliant risk assessment. We'll use a fictional water utility company, "AquaTech Services," to illustrate each step.

Step 1: Map Your Critical Services

Start by identifying which services your organisation provides that are critical—those whose disruption would have significant negative consequences for society, the economy, or public safety.

Example - AquaTech Services identifies:

Critical Service 1: Clean water supply to 500,000 residents
Critical Service 2: Wastewater treatment for the region
Critical Service 3: Emergency water supply management

For each critical service, document:

What the service does
Who depends on it (customers, other sectors)
What would happen if it was disrupted for 1 hour, 4 hours, 24 hours, 1 week
Regulatory or contractual obligations related to service levels

Step 2: Identify Supporting Systems and Processes

For each critical service, map out all the IT systems, OT (Operational Technology) systems, processes, and assets that support it.

Example - For AquaTech's water supply service:

System Type	Specific Systems	Function
SCADA Systems	WaterControl Pro v8.2	Monitors and controls water treatment plants
Sensors/IoT	Flow meters, pressure sensors, quality monitors	Real-time water quality and distribution data
Network Infrastructure	Industrial network, wireless links to remote stations	Connects plants, pumping stations, and control centre
Business Systems	Asset management software, maintenance scheduling	Tracks infrastructure health and planned maintenance
Communication Systems	Emergency notification system, internal comms	Alerts during incidents and coordinates response

This creates your "value chain" from critical service down to individual technical components.

Step 3: Map Dependencies

Identify what your critical systems depend on—both within your organisation and from external providers.

Example - AquaTech's SCADA system dependencies:

Internal dependencies:
- Data centre hosting the SCADA servers
- Network connectivity between sites
- Backup power systems
- IT support team availability
External dependencies:
- Internet connectivity from ISP "NetConnect"
- Cloud backup service from "SecureCloud Ltd"
- SCADA software support from vendor "IndustrialSoft"
- Electricity supply from energy provider

This step is crucial because NIS2 specifically requires you to address supply chain security. A vulnerability in a critical supplier can be just as damaging as one in your own systems.

Read more about vendor audits and assessments.

Step 4: Identify Threats

For each system and dependency, identify realistic threats that could disrupt it. Consider both cyber and physical threats.

Example threats to AquaTech's SCADA system:

Cyber threats:
- Ransomware attack encrypting SCADA servers
- Unauthorised access via stolen credentials
- DDoS attack on network infrastructure
- Malware introduced via USB device
- Supply chain attack through software update
Physical threats:
- Power outage affecting data centre
- Fire or flood at primary facility
- Physical intrusion and sabotage
Human threats:
- Insider threat (malicious or negligent employee)
- Social engineering attack on operators
- Lack of trained personnel during incident

Don't just think about sophisticated cyberattacks—simple mistakes like misconfigured systems or unpatched software cause many real-world incidents.

Step 5: Assess Probability and Impact

For each identified threat, assess:

Probability: How likely is this threat to occur?
Impact: If it did occur, what would the consequences be?

Use a consistent scale, typically 1-5 or Low/Medium/High/Very High.

Example - AquaTech assesses ransomware threat:

Threat: Ransomware attack on SCADA servers

Probability: Medium (3/5)
Reasoning: Water utilities are increasingly targeted. We have some protections but not comprehensive endpoint security on all industrial systems.

Impact: Very High (5/5)
Reasoning: Would prevent remote monitoring and control of water treatment. Manual operation possible but significantly degraded. Could affect water quality monitoring. Estimated recovery time: 3-7 days.

Risk Level: High (3 × 5 = 15)

Consider impact across multiple dimensions:

Service continuity: How long would the critical service be disrupted?
Safety: Could it endanger public health or safety?
Financial: What are the costs (recovery, fines, lost revenue)?
Reputational: What's the damage to public trust?
Legal/Regulatory: Are there compliance violations or penalties?
Data: Is sensitive or personal data compromised?

Step 6: Determine Risk Treatment

For each risk, decide how to treat it:

Mitigate: Implement controls to reduce probability or impact
Transfer: Use insurance or outsource to a provider
Accept: Consciously accept the risk (with management approval)
Avoid: Stop the activity that creates the risk

For high-priority risks, create detailed action plans.

Example - AquaTech's ransomware mitigation plan:

Risk: Ransomware attack on SCADA (Risk Level: High)

Treatment: Mitigate

Actions:

Deploy endpoint detection and response (EDR) on all SCADA servers (Q1 2026)

Implement application whitelisting on industrial systems (Q1 2026)

Segregate SCADA network from corporate network with firewall (Q2 2026)

Establish offline backups of SCADA configuration (Q1 2026)

Conduct security awareness training for operators (Ongoing)

Test backup restoration quarterly (Ongoing)

Target Risk Level: Medium (after controls)

Owner: IT Security Manager

Budget: €85,000

This creates a clear roadmap for improving your security posture based on actual risks to critical services.

Step 7: Document and Monitor

NIS2 requires that you document your risk assessment and keep it up to date. This documentation should include:

List of critical services
Supporting systems and dependencies
Identified threats and vulnerabilities
Risk ratings (probability × impact)
Risk treatment decisions and action plans
Residual risk after controls
Approval from management

The assessment isn't a one-time exercise. You must:

Review and update it at least annually
Update it whenever there are significant changes (new systems, new threats, incidents)
Track implementation of risk mitigation actions
Monitor whether controls remain effective
Report to management regularly

Using risk management software can help automate tracking and ensure nothing falls through the cracks.

How Often Should You Update Your NIS2 Risk Assessment?

The NIS2 Directive requires regular risk assessments, but doesn't specify an exact frequency. Best practice is:

Annual review: Conduct a full review at least once per year
After significant changes: Update when you:
- Deploy new critical systems
- Change service providers
- Experience a security incident
- Become aware of new major threats
- Undergo organisational restructuring
Continuous monitoring: Track whether implemented controls remain effective

Some organisations use a rolling review approach, assessing different critical services each quarter so the entire organisation is covered annually without overwhelming resources.

Common Mistakes to Avoid

Based on observing many organisations implementing NIS2, here are pitfalls to avoid:

1. Being Too Generic

Don't just list generic threats like "ransomware" or "DDoS." Be specific to your systems and context. "Ransomware targeting SCADA servers running Windows Server 2019 in the water treatment plant" is much more useful.

2. Ignoring OT/Industrial Systems

Many organisations focus heavily on IT systems and overlook operational technology. If you operate industrial processes, these systems are often the most critical and may have unique vulnerabilities.

3. Forgetting Supply Chain Dependencies

A sophisticated risk assessment of your own systems means nothing if a critical cloud provider or software vendor is compromised. Always map and assess your key dependencies.

4. Assessing Impact Unrealistically

Be honest about impact. Don't downplay risks to make your organisation look better. The point is to genuinely understand where you're vulnerable so you can protect what matters most.

5. Creating a "Shelf Document"

The worst outcome is a risk assessment that looks great on paper but doesn't drive actual security improvements. Make sure action plans have owners, budgets, and deadlines, and track them to completion.

6. Not Involving the Right People

Risk assessments shouldn't be done in isolation by security teams. Involve:

Operations staff who understand the critical services
IT and OT teams who manage the systems
Business leaders who can prioritise risks
Procurement/vendor management for supply chain risks

Tools and Templates for NIS2 Risk Assessment

You don't need to start from scratch. Several resources can help:

Risk Assessment Frameworks:

ISO 27005: International standard for information security risk management
NIST Cybersecurity Framework: Provides risk assessment guidance
ENISA Threat Landscape: Annual report on cybersecurity threats

Software Tools:

GRC platforms: Integrated tools for governance, risk, and compliance like .legal's Information Security module
Risk registers: Spreadsheet or database tools to track risks
Threat intelligence feeds: Stay updated on emerging threats

Read more about when you need compliance software for risk management.

Linking Risk Assessment to Other NIS2 Requirements

Your risk assessment isn't isolated—it should inform other aspects of your NIS2 compliance:

Security measures (Article 21): Risk assessment identifies which of the 10 security measures to prioritise
Incident response: Helps you prepare for the most likely and impactful incidents
Business continuity: Informs your continuity and disaster recovery plans
Supply chain security: Identifies which suppliers need additional scrutiny
Reporting to authorities: Provides context if you need to report an incident

Think of risk assessment as the foundation that supports all other security activities.

How .legal Helps with NIS2 Risk Assessment

At .legal, we've built our Frameworks module specifically to support NIS2 compliance, including risk assessment:

Pre-built risk library: Start with common NIS2-relevant threats and controls
Service mapping: Map critical services to supporting systems and dependencies
Automated risk scoring: Calculate risk levels based on probability and impact
Action tracking: Assign and monitor risk mitigation tasks with deadlines
Integration: Link risk assessments to ISO 27001 and other frameworks
Reporting: Generate risk reports for management and authorities

Book a demo to see how we can streamline your NIS2 risk assessment process.

Next Steps: From Assessment to Action

Once you've completed your NIS2 risk assessment, the real work begins—implementing the controls and mitigations you've identified. Here's what to do next:

Prioritise high-risk items: Focus on risks that threaten critical services
Create a roadmap: Develop a realistic timeline for implementing controls
Assign ownership: Each risk and action needs a responsible person
Secure budget: Present the business case to leadership for funding
Track progress: Regularly review what's been implemented
Test effectiveness: Verify that controls actually reduce risk as expected
Update documentation: Keep your risk register current as things change

Remember, NIS2 compliance isn't just about checking boxes—it's about genuinely protecting the critical services that society depends on. A thorough risk assessment helps you focus your security efforts where they matter most.

Frequently Asked Questions about NIS2 Risk Assessment

What is a NIS2 risk assessment?

A NIS2 risk assessment is a systematic process of identifying, analysing, and evaluating cybersecurity risks to your critical services. It focuses on how cyber incidents could disrupt your service delivery to end users and what measures you need to reduce that risk to acceptable levels.

How often should I update my NIS2 risk assessment?

NIS2 risk assessments should be reviewed at least annually and updated whenever there are significant changes to your IT environment, services, threat landscape, or after a security incident. Regular reviews ensure your risk picture stays current and actionable.

Who is responsible for conducting a NIS2 risk assessment?

Management bears ultimate responsibility for NIS2 risk assessments. In practice, the CISO or IT security team conducts the assessment, but management must approve the risk acceptance criteria, review results, and ensure adequate resources for risk mitigation.

What methodology should I use for NIS2 risk assessment?

NIS2 does not mandate a specific methodology. Common approaches include ISO 27005, NIST Risk Management Framework, and OCTAVE. The key is to use a structured, repeatable process that identifies threats, vulnerabilities, and impacts to your critical services systematically.

What is the difference between a NIS2 risk assessment and an ISO 27001 risk assessment?

Both follow similar principles, but a NIS2 risk assessment specifically focuses on risks to network and information systems supporting critical services and their impact on service delivery. ISO 27001 risk assessments are broader, covering all information assets. A NIS2 assessment may require additional focus on supply chain risks.

How do I identify critical services for NIS2?

Map your organization's services that fall under NIS2 sectors, determine which services would have significant impact on users or society if disrupted, identify the IT systems and networks supporting those services, and document the dependencies between services and systems.

What should a NIS2 risk register contain?

A NIS2 risk register should contain identified risks with descriptions, likelihood and impact ratings, affected critical services and systems, current controls in place, residual risk levels, risk owners, and planned mitigation actions with timelines.

How do I assess supply chain risks under NIS2?

Identify your critical suppliers and their access to your systems, evaluate their security posture, assess the impact of supplier compromises on your services, include contractual security requirements, and monitor supplier security status on an ongoing basis.

What risk mitigation measures does NIS2 require?

NIS2 Article 21 requires measures including risk analysis policies, incident handling procedures, business continuity and crisis management, supply chain security, network security, vulnerability handling, cybersecurity hygiene practices, cryptography policies, access control, and multi-factor authentication.

Can I use existing risk assessments to meet NIS2 requirements?

Yes, if you have existing risk assessments from ISO 27001 or other frameworks, these can form the foundation. You will need to ensure they specifically cover NIS2 elements including critical service impact, supply chain risks, and alignment with Article 21 requirements.

Still unsure?

Ask Johannes directly, he runs most demos personally

Book him here

.legal compliance platform Streamline Your NIS2 Risk Assessment Process

A systematic risk assessment is at the heart of NIS2 compliance. Use .legal to identify critical services, assess threats, document controls, and maintain a living risk register that satisfies auditors.