NIS2 Article 21 control baseline

The baseline should cover all ten Article 21(2) measure groups. It is not limited to technical controls: it also needs governance, incident handling, business continuity, supplier security, secure acquisition and development, effectiveness testing, cyber hygiene and training, cryptography, human resources security, access control, asset management, and appropriate authentication and secure communications.

Do not flatten those requirements into a one-row statement that the entity has a security policy. Article 21 requires an all-hazards approach covering the network and information systems and their physical environment, so the baseline must address malicious acts, accidental failures, people, facilities, utilities, suppliers, and service dependencies where they can create an incident. A reviewer should be able to see which control family maps to each Article 21 point and which systems, services, owners, and evidence records support it.

Article 21 is risk-based, but that does not make the baseline optional. The Directive says the level of security must be appropriate to the risks posed, taking account of state of the art, relevant European and international standards where applicable, implementation cost, risk exposure, entity size, incident likelihood, incident severity, and societal or economic impact.

Regulation (EU) 2024/2690 applies this detail only to DNS providers, TLD registries, cloud, data centre and CDN providers, managed and managed security service providers, online marketplaces, online search engines, social networking services platforms, and trust service providers. Where its annex uses 'where appropriate', 'where applicable', or 'to the extent feasible', a covered entity that does not apply the requirement must document its reasoning in a comprehensible manner.

Evidence should prove both design and operation. For example, a policy alone may show intent, but Article 21 evidence should also show risk treatment, role assignment, testing, supplier review, asset classification, training, and remediation where those items are relevant to the entity's services.

For its named provider types, the implementing regulation requires detail such as management-body approval, topic-specific policies, risk treatment plans, event monitoring, supplier policies and contract clauses, security testing, patch management, access policy, asset inventory, and assigned cybersecurity roles. It also requires at least annual review of the security policy, risk assessment, and risk-treatment plan, plus event-driven review after significant incidents or significant changes to operations or risks. Other sectors can use these as examples, but the Regulation's annex is not automatically binding on them.

A certification or standards mapping can support evidence, but it does not by itself establish compliance with Article 21. The entity still needs to cover the Directive's measure groups, proportionality factors, supplier-specific vulnerabilities, operational evidence, and corrective measures.

Another common gap is overlooking the physical environment, supplier relationships, and direct service impact. Article 21 uses an all-hazards approach for network and information systems and their physical environment, and it requires supplier-security decisions to consider vulnerabilities specific to each direct supplier and service provider.

This checklist helps turn Article 21 into a reviewable control baseline. Each item should produce an evidence record, not only a statement that the control exists.

If the entity is in a sector covered by Commission Implementing Regulation (EU) 2024/2690, check the applicable technical and methodological requirements in that regulation as part of the same baseline review.