NIS2 Technical Implementation: A Practical Guide to the Governance Layer
Table of contents
Whether in business, technology or everyday life, abbreviations are ubiquitous. However, I personally think they are overused, spelled out too rarely, and inconsistent even within a given domain. Admittedly, abbreviations have their use cases like keeping complex tables concise. When reading ENISA’s NIS2 Technical Implementation Guidance, however, I became convinced that it might make sense to create an inventory of the most important abbreviations within the given security context.
To improve my own understanding, and perhaps yours, I will not only list the abbreviations but provide a bit of context, and explain how the concepts relate.
What follows is not the complete picture of NIS2 but a concise top-down guide on important governance 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 will focus on the governance layer in this post and write another post on the operational layer later on.
The Governance Layer
Governance deals with the policies, responsibilities and processes that define how an organisation is managed. When subject to regulations like NIS2, governance becomes a cornerstone that helps an organisation to comply. Effective governance ensures compliance but is not consumed by it, because it helps employees to work effectively and provides the tools to do so.
Governance, Risk, and Compliance (GRC)
At its core, NIS2 is about requiring operators of services in “critical” sectors to treat cybersecurity as a fundamental strategic business risk. This is done quite directly by making cybersecurity the responsibility of the top management of an organisation. Therefore, cybersecurity becomes part of the governance of an organisation, and thus, part of how an organisation does its business.
One of the things that policies, responsibilities, and processes need to ensure when implementing NIS2 is to make risk management a top priority. Companies handle all kinds of risks, for example legal risks, already but NIS2 puts the focus on cybersecurity risks which need to be identified, assessed and mitigated. The risk assessment is a central activity in this context. It forms the basis for understanding cybersecurity threats and vulnerabilities, which then leads to managing the resulting risks with security measures.
NIS2 lists several specific cybersecurity risk-management measures (in Article 21) in order to achieve compliance. These include, for example, risk assessment, policies and procedures, business continuity, incident handling and reporting, third‑party risk management, encryption and logging, among others. To what extent the measures need to be implemented is decided based on the risk management described in the previous paragraph.
In short, governance ensures that risk management is prioritized, and risk management informs which actions are needed for compliance. Due to this tight relationship, governance, risk management and compliance are increasingly abbreviated together as GRC, and there are even “GRC tools” out there to support this cluster of activities. For example, Eramba is available in a free community edition with “source available”1.
Third-Party Risk Management (TPRM) & Supply-Chain Risk Management (SCRM)
One of the cybersecurity risk-management measures required by NIS2 (in the previously mentioned Article 21) is supply chain security. NIS2 requires that entities address supply‑chain and third‑party risks relevant to their services, typically your direct suppliers and outsourced providers, with proportionate measures that also consider transitive risks where relevant. ENISA’s NIS2 Technical Implementation Guidance further clarifies that this requirement is about developing a supply chain policy as well as keeping an inventory of suppliers. The policy shall, e.g., include supplier selection criteria and require (where applicable) risk assessments and service level agreements (SLAs). The inventory shall be kept up to date and suppliers classified according to criteria like volumes and risk, while monitoring changes.
These topics are usually covered by Third-Party Risk Management (TPRM) processes which, briefly speaking, cover handling who you enter a supply-chain relation with and managing it using contracts, access controls, audits, SLAs, onboard/offboarding, etc.
There is also the area of Supply-Chain Risk Management (SCRM) which usually looks into the things that you buy or depend on, how they are built and delivered. SCRM is a whole discipline of its own but we will only focus on cybersecurity here. For software cybersecurity, SCRM is managed by a diverse set of tools and processes: reviewing Software Bill Of Materials (SBOMs), running Software Composition Analysis (SCA), validating firmware and build provenance (verifiable metadata about a build), tracking transitive dependencies and patch‑management lifecycle, and requiring vendor attestations or secure‑build practices. Even in cybersecurity, SCRM does not only cover software but also hardware, firmware, cloud services and other components (physical or virtual). Broadly speaking, the Cyber Resilience Act (CRA) is more concerned about product security requirements, though, where NIS2 focuses on operators of services.
TPRM and SCRM are complementary: TPRM covers contractual and organisational management of suppliers, while SCRM focuses on the technical integrity, availability and provenance of the products and components you procure. Controls such as SBOMs, SCA and build provenance help implement SCRM and can be required contractually via TPRM.
In smaller organisations, TPRM can be managed with spreadsheets and ticketing but the bigger the supplier network gets, the more complex this task will be. At some point, it will make sense to employ a dedicated TPRM tool (there are several cloud-based out there). In many cases, I would expect TPRM to be handled effectively as part of tooling that already exist at a company like GRC or general risk management. TPRM might also integrate with Identity and Access Management which I will describe in the next post of this series.
Business Continuity Management (BCM)
Let’s suppose your organisation does everything it can to keep risks low: risk assessments, mitigations, incident handling, cybersecurity awareness, etc. The fact is, there is no perfect cybersecurity and despite a low probability, you can still end up in some kind of disaster or crisis. Therefore, NIS2 requires proportionate “business continuity, such as backup management and disaster recovery, and crisis management” (Article 21). Depending on the organisation, Business Continuity Management (BCM) can include business continuity and disaster recovery plans.
The business continuity plan (sometimes abbreviated BCP) is one of the main results of BCM. It deals with keeping the organisation and its services operating despite disruptions like a cyberattack. Based on a risk assessment and a business impact analysis (BIA), it shall outline proper responses to different disruptions that can impact the organisation’s business. It shall identify critical business operations that are prioritised in their recovery in order to minimize the impact of the disruption.
The disaster recovery plan (sometimes abbreviated DR) depends on what kind of disaster are considered relevant for the organisation but often focuses on restoring IT systems and services after a disruption (which can be caused by physical damage, software failure, ransomware, misconfiguration, or cloud-provider incidents). In any case, it is about recovering from disruptions where the infrastructure (or parts of it) is lost. This can include determining a (physical or virtual) failover site as well as preparations (such as off-site backups and redundancy) and restore procedures to get it up and running as quickly as possible.
Depending on the organisation, BCM could look very differently in extent and design. Fortunately, there is guidance in the form of ENISA’s NIS2 Technical Implementation Guidance and the ISO 22301 standard. I would argue, though, that putting some thought into a BCP makes sense for any business, even small ones. Even a minimal BCM ensuring tamper-resistant backups, communication during a crisis, and the minimum infrastructure that you need to get back on your feet, can make a big difference.
Conclusion
NIS2 is not a single checklist but about treating cybersecurity as a board-level responsibility. At the governance layer, this includes three practical priorities: embed risk management into decision-making (GRC), get a clear handle on what and what you depend on (TPRM and potentially SCRM), and plan for the inevitable disruption (BCM). Doing the basics well (like an up-to-date risk register and supplier inventory, tamper-resistant backups as well as a communication plan) will go a long way.
It is important to note that all measures must be proportionate to your organisations size, risk profile, and sector. However, even if you are not covered by NIS2 directly, your business partners will have growing interest in keeping their supply chain secure and formulate their contracts accordingly.
In the next post, I will move to the operational layer and look at a new bunch of abbreviations like IAM, PAM, SIEM, EDR,… 🙂
-
Eramba’s community edition is “source available” but does not meet open-source redistribution requirements in most open-source definitions. ↩︎