NIS2 Technical Implementation: A Practical Guide to the Operational Layer

• 2026-01-06
• 15-minute read

Table of contents

When I started writing my last post on the NIS2 Governance Layer, I originally gathered cybersecurity-relevant abbreviations like SIEM, XDR and IDS which belong to the operational layer. Quickly they became too many and I needed to split the posts.

So this post is a concise top-down guide on important operational concepts that you can encounter when implementing the “Network and Information Systems Directive 2” (Directive (EU) 2022/2555), or short NIS2, in an organisation. I had the idea when reading ENISA’s NIS2 Technical Implementation Guidance. This post (or series) does not provide a complete picture on NIS2 but can be seen as a cheat sheet when reading ENISA’s guidance.

The Operations Layer

While the governance layer establishes policies, responsibilities and processes, the operational layer deals with the daily technical execution including monitoring, detection and response. In a well-working organisation, governance and operations work closely together. Otherwise, you can have the nicest policies and processes, but the people who should implement and bring life to them might not see them as relevant or fitting to their way of working.

It is unfortunately common to see policies being set top-down, when effective governance starts with looking at how operations are working and solving their problems today. In many cases, you might be closer to meeting a compliance requirement than you think. Operational people usually know their assets pretty well, take care of them and know their weak spots. This means that conceptually, governance and operations might be distinct layers but they should cooperate tightly.

One of the foundations to having secure operations is knowing who accesses your assets and setting different privileges for different users. This is covered by Identity and Access Management (IAM).

Identity and Access Management

Identity and Access Management (IAM) & Privileged Access Management (PAM)

Simply put, Identity and Access Management (IAM)¹ is about ensuring that only authorized users or systems have appropriate access to your assets, which can include systems, data, or applications. IAM involves processes, policies and technologies, and thus, has one foot within the Governance Layer. The process and policy part of IAM governs how user accounts are registered and login credentials provided. It further governs how to assign access rights that are appropriate for what they need to achieve. There should also be processes for handling expiry of user accounts, e.g., when an employee leaves, or a policy which enforces Multi-Factor Authentication (MFA), as discussed in the next section.

During operations, users need to be identified, e.g., using an email address, and authenticated, e.g., using password and MFA. Once authenticated, the user’s access to assets is controlled according to the assigned access rights. Finally, actions taken by privileged accounts should be logged (and audited) to ensure accountability.

Privileged Access Management (PAM) is a specific type of IAM that focuses on accounts with elevated permissions. These accounts are high-value targets for attackers, because a single successful attack can give wide-ranging access to critical infrastructure, sensitive data or other high-impact systems. Due to the increased risks for catastrophic incidents, PAM employs additional stricter controls for privileged accounts than the more general IAM. The controls can include session monitoring and anomaly detection, as well as temporary and least-privilege access. This can for example be 15min. admin access to a specific database, just enough to fix the issue.

From my limited point of view (Sweden), the cloud-based Microsoft Entra ID is by far the most used IAM solution and it is probably considered a safe choice because “everyone else is using it”. It is important to remember, however, that even widely used solutions like Entra ID have outages and vulnerabilities. These are risks that need to be considered when choosing an IAM solution. Especially given the global political climate, it makes sense to evaluate European solutions.²

Multi-Factor Authentication (MFA)

Multi-Factor Authentication (MFA) is a form of authentication where a single type of evidence, e.g., only password, is not sufficient. There are different ways to implement MFA but they usually combine two or more distinct types of evidence: something the user has (e.g., USB stick or bank card), knows (e.g., a password) or is (biometrics like fingerprint). MFA is very effective against compromised authentication, there are studies which estimate a risk reduction of over 98.5%, even when credentials are leaked³. Not having MFA in place can have drastic consequences, so it is no surprise that NIS2 explicitly mentions it (Article 21(2)(j)).

A form of MFA that is easy to use and getting very common is time-based one-time password (TOTP). Again, there are different ways to use TOTP, but as a user it usually looks like this: When you setup TOTP authentication, you scan a QR code with an app on your smartphone (the shared secret between app and server). The app will then periodically (e.g., every 30 seconds, no need for network connection) generate a password consisting of 6 numbers. When you want to authenticate, you need to put in your usual password (first factor) and the currently valid TOTP (second factor). There are numerous apps that can generate TOTP. Personally, I like the free and open source Aegis on Android.

Server-side, it is preferable to handle MFA centrally as part of your IAM (discussed in the previous section). As a minimum, TOTP should be required as a second factor, which is supported by any reputable IAM solution. For even stronger security, many organizations are moving towards FIDO2, which replaces phishable codes with hardware-backed cryptographic keys that verify the user via a physical touch or biometric scan.

This covers our short introduction to Identity and Access Management. In the following, we will dig deeper top-down into the operational concepts.

Security Operations Center (SOC) Fundamentals

The Security Operations Center (SOC) is the part of an organization that is tasked with protection against cyber threats. This includes monitoring, networks and applications as well as investigating potential incidents. Detected cyber attacks need to be remediated, and documented for improving the protection.

While NIS2 itself does not mention SOC explicitly, Article 21(2)(b) “incident handling” and (e) “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” cover typical tasks of a SOC. Further, ENISA’s NIS2 Technical Implementation Guidance explicitly mentions the tools discussed in the following sections as examples of evidence for compliance with Article 21(2)(b) and (e). A central tool from the toolset of SOCs are Security Information and Event Management systems.

Security Information and Event Management (SIEM)

NIST defines Security Information and Event Management (SIEM) as an “Application that provides the ability to gather security data from information system components and present that data as actionable information via a single interface.”. A SIEM is the central system of record and compliance dashboard that a SOC uses to understand the current state of cybersecurity of the observed organisation. The information presented by SIEM applications is based on log and event data gathered in real-time from endpoints (computers, smartphones, …), network devices, applications, and other sources that is parsed and normalised into a common format.

SIEM is a term that was coined in 2005, which combines Security Information Management (SIM) and Security Event Management (SEM):

• Security Information Management (SIM): Collects, stores, and analyzes log data for long-term retention, forensic investigations, and compliance reporting (e.g., tracking user access logs for audits).
• Security Event Management (SEM): Analyzes real-time events to detect threats using techniques like correlation rules, anomaly detection, and machine learning. For example, SEM can flag unusual network traffic patterns or repeated failed login attempts.

While the SIM and SEM concepts help to understand SIEM, the distinction is today rarely ever made.

SIEM systems are particularly important in the context of NIS2 for fulfilling requirements (if applicable) of continuous monitoring, logging, and the formal assessment of suspicious events to determine if they are actual incidents. They further provide functionality which support incident handling including documentation of incident responses, and monitoring of access attempts which supports access control. The data and documentation gathered by a SIEM are crucial to understand the state of cybersecurity of an organisation and can provide evidence of compliance with NIS2.

A popular free and open-source SIEM is Wazuh. Wazuh combines SIEM and XDR functionality in a single application, and it can further be integrated with SOAR tools of increased automation. XDR and SOAR will be introduced in the following sections.

Extended Detection and Response (XDR)

Extended Detection and Response (XDR) monitors cybersecurity threats and provides automated response to incidents. Similar to SIEM, XDR gathers data from numerous sources to detect cybersecurity incidents. XDR systems have a deeper integration into the monitored systems, however, and take a more active role in stopping incidents: SIEM systems historically focus on analysing log data using rule sets. XDR systems gather structured telemetry data that is gathered from sensors, e.g., endpoint, network, cloud or identity sensors, that gather specific information (more details in the following sections). The gathered data is stored centrally and translated into a common language which is analysed using machine learning for suspicious patterns that can cross different domains, e.g., linking an endpoint and cloud alert from separate sensors.

In contrast to SIEM, XDR does not only monitor and alert but it also includes automated response capabilities like killing a process. It can also integrate more powerful response mechanisms that are referred to as Security Orchestration, Automation, and Response (SOAR), which will be introduced in the next section.

The previously mentioned Wazuh is not only a SIEM system but integrates XDR as well. Generally speaking, the line between SIEM and XDR is becoming less sharp as SIEM systems increasingly integrate XDR features, e.g., automated responses. At the same time, XDR systems add SIEM features like analysis of third-party logs that do not come from the XDR’s sensor integrations. The main distinction is still that SIEM systems are generalists that gather any logs, while XDR have specific sensors that provide rich and structured data. This allows XDR to perform automated correlation of data across different types of sensors, without the need for a human to stitch together alarms to understand what has happened.

XDR have become the most important tool of SOCs today to improve the cybersecurity of an organisation. Having an XDR in place and documenting the system’s reports can help provide evidence of compliance with NIS2.

Security Orchestration, Automation, and Response (SOAR)

Security Orchestration, Automation, and Response (SOAR) does not have a similarly direct relation to NIS2 as the previously mentioned concepts, however, it does have a direct relation to both SIEM and XDR. Further, it can support and document incident-management workflows that can provide evidence of compliance with NIS2. A SOAR system collects alerts and security incidents from a SIEM and/or XDR system and performs automated responses that typically go beyond the response of an XDR in terms of possible actions and tool orchestration.

The automated responses performed by SOAR systems are defined by so-called playbooks. How these playbooks are defined is product specific, e.g., YAML files or graphical editors, but generally any API or command line interface can be called by a playbook to enable responses across different tools. To give a rough example, this could mean isolating an endpoint, revoking privileged access of an account and deploying a mitigation across different services as a response to the same incident. Most SOAR systems ship template playbooks that cover common incident scenarios (e.g., phishing, ransomware, lateral movement). These templates can be customized to the specific APIs and processes of an organisation’s environment. Through automation, SOAR provides workload reduction for SOCs that see an increasing number of daily incidents. The playbook will need to be maintained, however.

Increasingly common is AI functionality that is highlighted in SOAR products, e.g., for labeling and prioritizing incidents. An example of an open-source platform that can be used for implementing SOAR is the “AI-native” automation platform tracecat.

Network Detection and Response (NDR)

Network Detection and Response (NDR) focuses, as the name suggests, on detecting cybersecurity threats by focusing on the network. This includes analysis of network traffic, both internal and external, as well as infrastructure. NDR typically operates on so-called flow records to obtain a high-level picture of network behaviour, e.g., source and destination of traffic.

In more advanced deployments, deep‑packet inspection can reveal hidden content such as encrypted payloads or protocol anomalies. Of course, most traffic is encrypted today, which renders deep-packet inspection less effective. Therefore, Encrypted Traffic Analysis (ETA) is often employed which analyses the metadata (packet size, timing, …) to find malicious behaviour without decrypting the packet.

Similar to what I mentioned for XDR, NDR often uses machine learning to detect suspicious patterns in network traffic and behaviour. Once an incident is detected, an NDR can respond with, e.g., blocking IPs, rate-limiting traffic or isolating network segments.

At this point, you might wonder what the difference to XDR is. An XDR provides a more holistic threat detection that often contains an NDR as one type of sensor that focuses on the network. An NDR system can work standalone, however, and there might be use cases where an organisation mainly works with a mature SIEM and is looking for quickly improving its detection capabilities. Then, adding an NDR and an EDR can be an effective path forward, but before I explain what an EDR is, we will have a look at more traditional network protection concepts: IDS and IPS.

Intrusion Detection System (IDS) & Intrusion Prevention System (IPS)

While Intrusion Detection System (IDS) and Intrusion Prevention System (IPS) are related to NDR, they are more fundamental network security technologies that respectively focus on detecting and blocking specific threats based on known patterns and behavioral anomalies.

An IDS is a passive monitoring tool that can run on a network device (network intrusion detection system, NIDS) or endpoint (host-based intrusion detection system, HIDS). Detection is primarily based on signatures, i.e., known bad patterns or anomalies. When an incident is detected, an IDS does not take action but generates an alert.

Essentially, an IPS is an IDS with the capability to take action. Compared to NDR, IPS has a more local point of view. An IPS looks at individual bursts of packets in isolation and decides whether they are allowed to pass. An NDR looks at behavioral patterns across the entire network, which is enabled by analysing flow records (as explained in the previous section). Further, an IPS is implemented “in line” with traffic flowing through, while an NDR is “off side” observing patterns.

In reality, the line between IPS and NDR is increasingly blurry and traditional IPS are extended and rebranded into NDR systems. Zeek, Snort and Suricata are examples of popular open-source IDS/IPS, Zeek and Suricata are sometimes categorized as NDR. All three can be found as part of proprietary NDR products.

Finally, we will move on to EDR, which an NDR can complement.

Endpoint Detection and Response (EDR)

Endpoint Detection and Response (EDR) focuses on endpoints like laptops, smartphones, or IoT devices. An EDR agent runs locally on the endpoint and monitors activities of the operating system as well as applications on the particular endpoint, which can include process trees, file changes, drivers, memory snapshots or authentication events. The gathered information is analysed for potential incidents using heuristics and machine learning. If an incident is detected, IT administrators are alerted. Commonly, EDR are combined with EPP (Endpoint Protection Platform) functionality which can perform preventive blocking of applications and activities. EPP tools are more traditionally called “Antivirus”.

Similar to an NDR, EDR can perform limited responses. An EDR response could be the termination of a process, taking a memory dump for later analysis (forensics) or isolating the endpoint from connecting to a network.

Again similar to NDR, an EDR system can work standalone or be integrated as one type of sensor into an XDR for holistic threat detection. Many XDRs contain EDR functionality, like the previously mentioned Wazuh. There is also the free and open-source velociraptor EDR.

Discussion – Do I need all of this?

After reading through this gathering of acronyms (IAM, PAM, SIEM, XDR, SOAR, NDR, EDR, …) you might feel overwhelmed. If you are a small or medium-sized enterprise falling under NIS2, you might be asking: “Do I really need to buy and maintain ten different software products?”

The short answer is: No, but you do need working and documented cybersecurity.

NIS2 is not a prescriptive checklist that requires you to buy specific tools or systems. Instead, it requires you to manage risks relative to your size and the criticality of your services. Following ENISA’s NIS2 Technical Implementation Guidance, an action plan could start with establishing IAM with MFA to protect access to your infrastructure and services, and EDR to protect endpoints. Then, an XDR system, which today often combines SIEM, EDR and NDR under a single interface, can provide the centralized overview necessary to meet the 24-hour incident reporting requirements of NIS2. It will further provide auditable documentation of how cybersecurity is handled. Finally, it is important that cybersecurity is not just about tools but they make the life of your SOC easier. If having an in-house SOC is unfeasible, you can consider buying this service as a so-called Managed Detection and Response (MDR).

This concludes my short series on NIS2 Technical Implementation for now. Writing it helped me to clarify the most important acronyms in this context, and I am sure I will need to revisit this post sometime. Well, if you have read until here, I hope it helped you, too!

Posts in this series

• NIS2 Technical Implementation: A Practical Guide to the Operational Layer
• NIS2 Technical Implementation: A Practical Guide to the Governance Layer