The NIS2 Directive

Members of the management body are required to follow training, and the entity is expected to put comparable training in front of its employees regularly. The stated purpose sets the standard: the training has to leave the body able to identify risks and to assess cybersecurity risk-management practices and the effect those practices have on the services the entity provides. That is a judgement bar, not an attendance bar. Generic awareness content aimed at all staff will not reach it, because a board member is being asked to challenge a risk treatment decision rather than avoid a phishing email. Training also needs refreshing as the body changes; a director appointed after the last session is untrained for the purposes of this Article. The employee limb is expressed as an encouragement on Member States to require, so its national transposition is worth reading, but the entity-level expectation is regular and repeated rather than on induction only.

The first of the ten minimum measure categories requires both a method for analysing risk and the security policy set that the analysis feeds. Risk analysis has to be an actual repeatable method with criteria for assessing and accepting risk, applied to the network and information systems the entity relies on for its operations and for delivering its services, with results that are recorded and revisited. The information system security policies are the codified decisions that follow: what is protected, to what level, who owns each decision, and what happens when the policy cannot be met. Both limbs are needed. A risk register with no policy leaves nothing binding on the organisation, and a policy library with no risk analysis behind it cannot show why it says what it says.

Incident handling here is the internal capability to detect, triage, contain, eradicate, recover from and learn from incidents. It is separate from the reporting duty in Article 23: reporting tells the authority what happened, handling is what the entity does about it. The capability needs defined severity levels, an escalation path that reaches decision makers out of hours, named responsibilities, and evidence that it functions rather than exists on paper. Post-incident review matters because it is the link back to Article 21(2)(f), where the effectiveness of the measures is assessed. The classification scheme deserves particular attention, because the same triage has to be able to recognise a significant incident under Article 23(3) and start the 24-hour clock.

This category asks the entity to be able to keep providing its services, or to restore them, when systems fail or are attacked. Backup management means backups that are taken, protected against the same event that takes out production, and demonstrably restorable, which is why restore testing rather than backup success rate is the evidence that counts. Disaster recovery means recovery objectives that were derived from what the service can actually tolerate, and infrastructure and procedure capable of meeting them. Crisis management is the decision-making layer above both: who declares a crisis, who can commit the organisation, how the entity communicates while under pressure. Because NIS2 is concerned with continuity of service to recipients, recovery objectives set purely from internal convenience are the usual weak point.

The Directive scopes this deliberately at direct suppliers and service providers, which makes the first artefact an inventory of who those parties are and which of them touch the network and information systems behind the service. From there the entity has to manage the security-related aspects of each relationship: what the supplier may access, what security obligations bind it, what happens on incident, and what happens at exit. Contract terms are the enforcement mechanism, so contracts that predate NIS2 and carry no security clauses are a live gap rather than a legacy inconvenience. Managed service providers and managed security service providers deserve separate attention because they hold privileged access into the estate, which makes their compromise the entity's incident.

Two duties travel together in this point. The first is that security is built into how systems are acquired, developed and maintained: security requirements set before purchase or build, secure development practice, change control, and maintenance that does not quietly reintroduce weakness. The second is vulnerability handling and disclosure, meaning the entity can receive a vulnerability report about its own products or systems, triage it, fix it on a timescale that reflects severity, and handle disclosure. A published route for a finder to reach the entity is the part most often missing, and its absence is visible from outside. Note that the coordinator role and the European vulnerability database in Article 12 belong to the CSIRTs and ENISA; what binds the entity is its own handling and disclosure capability.

The entity has to be able to say whether its measures work, not merely that they exist. That calls for a defined assessment approach with a schedule, someone sufficiently independent of the people who operate the control doing the assessing, criteria for what effective means, and a route by which findings become tracked remediation. Testing, measurement and independent review all count; a maturity self-score does not, because it measures opinion. This point is the one that closes the loop back to Article 21(4), since the corrective-action duty is triggered by the entity finding it does not comply, and effectiveness assessment is how it finds out.

Cyber hygiene is the common baseline the Directive expects everywhere: keeping software and hardware updated, managing configuration of devices, controlling and limiting administrator-level accounts, managing new installations, changing credentials, segmenting networks and backing up data. The recitals also point at zero-trust principles and user awareness as part of the same baseline. Training here is the workforce limb, distinct from the management body training in Article 20(2), and it needs to reach the roles that actually handle the risk rather than being one annual module for everyone. The value of this category to an auditor is that it is measurable: patch currency, privileged account counts and training completion are all countable, and a claim of good hygiene that cannot produce those numbers is not evidenced.

The obligation is to have decided, in writing, where cryptography is used and how it is governed. That covers which algorithms and key lengths are permitted, where data is encrypted at rest and in transit, how certificates and keys are generated, stored, rotated and revoked, and who may access key material. Encryption is qualified by where appropriate, which means the entity is expected to reach a reasoned position rather than encrypt everything or nothing. Key management is where this obligation usually fails in practice, because encryption can be deployed correctly while the keys sit somewhere that removes the protection. Expired certificates and forgotten key owners are also the common route by which an availability incident starts.

Three linked disciplines sit in one point because they fail together. Human resources security covers screening proportionate to the role, security terms in employment, and the leaver process. Access control policy covers how identities are created, what rights they carry, how privileged access is granted and reviewed, and how rights change when a person moves internally. Asset management covers knowing what the entity has, who owns it, how it is classified and what happens at disposal. The join between them is where evidence is usually thin: a leaver process that reclaims the laptop but not the cloud account, or an access review run against a directory that does not include the systems that matter. Internal movers are a sharper test than leavers, because accumulated rights are rarely removed.

This point pulls together the authentication and communications controls the Directive names explicitly. Multi-factor authentication, or continuous authentication solutions in its place, is expected where appropriate, and the interesting question is always coverage: remote access, administrative access, and access to the systems behind the essential service are where absence matters most. Secured voice, video and text communications within the entity is the second limb. The third, secured emergency communication systems, is the one most often absent, and it is the one that decides whether the entity can coordinate during an incident in which its normal collaboration and directory services are unavailable or untrusted. A crisis plan that runs on the corporate messaging platform does not satisfy this if that platform is what has been compromised.

Deciding what supply chain measures are appropriate is not left to general judgement. The entity has to take into account the vulnerabilities specific to each direct supplier and service provider, and the overall quality of those parties' products and cybersecurity practices including their secure development procedures. Separately, it must take into account the results of the Union level coordinated security risk assessments of critical supply chains carried out under Article 22(1). That second limb creates an external input the entity has to watch for and respond to: when a coordinated assessment lands on a technology the entity uses, the outcome has to reach the supplier risk decisions rather than stop at a policy team. Evidence of consideration is what is being asked for, including reasoned decisions not to change anything.