Article 21 of the NIS2 Directive, Directive (EU) 2022/2555, sets the minimum cybersecurity measures that essential and important entities must take. It reads like a list of headings, which leaves a lot of room for interpretation about what "good enough" looks like. This post walks through each measure in practical terms, then covers the reporting deadlines in Article 23.
This is a reading of the Directive itself. Each Member State implements it through national law, which can add detail, so check the rules and the competent authority in each country where you operate.
Does it apply to you?
NIS2 generally covers medium-sized and large organisations in the sectors listed in its Annexes I and II. Size follows the EU SME definition, under which a small enterprise has fewer than 50 staff and turnover or balance sheet of up to EUR 10 million. In practice, if you have 50 or more staff, or both turnover and balance sheet above EUR 10 million, you are at least medium-sized.
Some entities are covered regardless of size under Article 2(2). Examples include providers of public electronic communications networks or services, trust service providers, top-level domain registries and DNS service providers.
Entities are either essential or important (Article 3). The measures in Article 21 are the same for both. The difference shows up in supervision, which for important entities is mainly after the fact (Article 33), and in the maximum fines under Article 34. For essential entities, Member States must set a maximum of at least EUR 10 million or 2% of worldwide annual turnover, whichever is higher. For important entities, the figures are EUR 7 million or 1.4%.
Two points matter for readers outside the EU, including in Türkiye. Under Article 26(3), certain digital providers must designate a representative in the EU if they offer services there without being established in it. These include cloud, data centre, managed service and managed security service providers. And suppliers to in-scope entities will feel Article 21 through their customers' contracts and questionnaires.
The ten measures in Article 21(2)
Article 21(1) requires measures that are "appropriate and proportionate". They must take into account the state of the art, relevant standards, cost, the entity's size and exposure to risk, and the likelihood and severity of incidents. Article 21(2) says they must follow an all-hazards approach and include at least the following.
(a) Risk analysis and information system security policies
Write down what you need to protect, what could go wrong and what you have decided to do about it. For a 200-person company, that means an asset list, a risk register reviewed at least yearly, and a short security policy that management has signed.
(b) Incident handling
Have a written process for detecting, triaging and responding to incidents, with named people and out-of-hours contacts. Include the Article 23 reporting steps, so nobody has to work out the deadlines during an incident.
(c) Business continuity, backups, disaster recovery and crisis management
Know which services matter most and how long you can be without them. Keep backups that an attacker with administrator rights cannot delete, and test restores on a schedule. Run at least one tabletop exercise with management.
(d) Supply chain security
List the suppliers and service providers that can affect your systems, such as your MSP, cloud and SaaS providers and software vendors. Article 21(3) asks you to consider each direct supplier's specific vulnerabilities, product quality and security practices, including secure development. In practice, put security requirements and incident notification duties into contracts.
(e) Security in acquisition, development and maintenance, including vulnerability handling and disclosure
Patch on a defined schedule, track vulnerabilities in what you build and buy, and give outsiders a way to report issues to you. A published security.txt file and a simple disclosure policy cover the last point.
(f) Assessing the effectiveness of these measures
Check that controls work, rather than assuming they do. Internal audits, vulnerability scans, penetration tests and restore tests all count, as long as findings are tracked to closure.
(g) Basic cyber hygiene and training
Cover the basics everywhere: updates, secure configuration, least privilege and removing unused accounts. Train all staff regularly, with phishing awareness as a minimum. Article 20(2) separately requires members of management bodies to follow training.
(h) Cryptography and encryption
Decide where encryption is required, such as laptops, backups, data in transit and sensitive data at rest. Decide which algorithms and protocol versions are acceptable, and who manages keys and certificates.
(i) Human resources security, access control and asset management
Run joiner, mover and leaver processes that actually remove access on the last day. Review privileged accounts regularly. Keep an asset inventory that someone owns and updates.
(j) Multi-factor or continuous authentication, secured communications and emergency communications
Use multi-factor authentication for remote access, email, cloud administration and privileged accounts. Agree an emergency communication channel that does not depend on your own email or chat, because those may be down or watched during an incident.
Management is accountable
Article 20 requires management bodies to approve the risk-management measures and oversee their implementation. Management bodies can be held liable for the entity's infringements of Article 21. Their members must follow training, and Member States must encourage entities to offer similar training to employees regularly.
In practice, put cybersecurity on the board agenda at least quarterly. Record decisions, including risks that management has accepted.
The reporting clock in Article 23
A significant incident is one that has caused, or could cause, severe operational disruption or financial loss for the entity, or considerable material or non-material damage to others. These incidents must be reported to the CSIRT or competent authority in stages:
| Stage | Deadline | Content |
|---|---|---|
| Early warning | Within 24 hours of becoming aware | Whether unlawful or malicious action is suspected, and possible cross-border impact |
| Incident notification | Within 72 hours of becoming aware | Update of the early warning, initial assessment of severity and impact, indicators of compromise where available |
| Intermediate report | On request | Relevant status updates |
| Final report | Within one month of the incident notification | Detailed description, likely root cause, mitigation applied and ongoing, cross-border impact |
| Progress report | If the incident is still ongoing at the final report deadline | Status, followed by a final report within one month of handling the incident |
Trust service providers have a shorter deadline. For incidents affecting their trust services, the notification in the second row is due within 24 hours. Where appropriate, entities must also inform recipients of their services about significant incidents that may affect them.
These clocks run alongside other duties. A ransomware attack that affects personal data may also need a GDPR Article 33 notification to the data protection authority, where feasible within 72 hours.
Proportionate, documented, evidenced
Article 21 does not prescribe a specific standard. If you already run ISO/IEC 27001, mapping its controls to the ten measures is a sensible place to begin. For certain digital providers, Commission Implementing Regulation (EU) 2024/2690 sets out detailed technical requirements, and ENISA's technical implementation guidance from June 2025 offers examples of evidence and mappings. Even if that regulation does not apply to you, the guidance shows what evidence looks like.
Whatever you choose, keep evidence: policies with approval dates, training records, test reports, restore logs and the risk decisions management made. Under Article 21(4), an entity that finds it is not compliant must take corrective measures without undue delay.
Where to start
- Confirm whether you are in scope, and whether as an essential or important entity, under your national law.
- Run a gap assessment against the ten measures above. One page per measure is enough to start.
- Fix the high-impact gaps first, for example missing MFA, untested backups or no incident reporting procedure.
- Write the Article 23 reporting steps into your incident plan, with contact details for your CSIRT or authority.
- Brief management, record their approval and schedule their training.
Our consulting team can help with a NIS2 gap assessment, and SecAudit maps WordPress security findings to Article 21 measures in its compliance reports.
