What Article 21 asks an entity to do
Article 21 of the NIS2 Directive is where the directive stops defining who is in scope and starts saying what those organisations must actually do. Paragraph 1 requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage the risks to the network and information systems they use to run their operations or deliver their services. The same measures must prevent incidents, or minimise their impact, both on the people who receive those services and on other services that depend on them.
The obligation is written as risk management, not as a fixed checklist, and that choice shapes everything else in the article. The measures must take account of the state of the art, relevant European and international standards where they apply, and the cost of implementation. When a supervisor judges whether they are proportionate, the directive tells it to consider the entity's exposure to risk, its size, how likely incidents are and how severe they would be, including their societal and economic impact. In practice, two organisations in the same sector can end up with quite different control sets and both be compliant, provided each can show how its own risk analysis led to its choices.
Proportionality is not a way out of the obligation. A 60 person managed service provider will not run the same programme as a national water utility, but it still has to cover every area the article lists, and it has to explain its decisions in writing. The recitals make the reasoning explicit: measures should be proportionate so that they do not impose a disproportionate burden, but they should still give a complete picture of the security of the systems, including the human factor. A supervisor reading a risk analysis expects to see why a control was judged sufficient, not just that it exists.
Paragraph 2 then requires an all hazards approach that protects network and information systems and their physical environment. Recital 79 spells out what that covers: theft, fire, flood, telecommunications or power failures, and unauthorised physical access, alongside cyberattacks. A risk analysis that only considers hackers misses half of what the directive asks for. The paragraph closes with ten areas, points (a) to (j), that the measures must include at minimum. Those ten points are what most people mean when they talk about NIS2 requirements, and each is broad enough to contain a programme of work in its own right.
Who has to apply the measures
Article 21 applies to essential and important entities as defined in Article 3, by sector, by size and through a small number of special cases. Our guide to NIS2 essential and important entities explains how an organisation ends up in one category or the other. The distinction matters for supervision, but it does not change the content of the obligation: the ten measures are identical for both.
What changes is how the authority checks them. Essential entities are subject to proactive supervision under Article 32, which includes audits, onsite inspections and requests for evidence before anything has gone wrong. Important entities are supervised after the fact under Article 33, typically when an incident, a complaint or other evidence suggests they are not complying. An important entity can therefore go a long time without a supervisor asking for anything, but when the request comes it is usually because something has already happened, which is the worst moment to discover that the evidence does not exist.
Because NIS2 is a directive, the obligation reaches a company through the national law that transposes it, and the competent authority, the registration process and the sanction procedures are national. Article 21 sets a minimum, so a national law can add detail or require more, but every transposition has to include the ten areas. For Spanish companies, our article on NIS2 in Spain covers who is in scope and how the obligations arrive. Recital 83 adds a point that is easy to miss: the obligations apply whether an entity runs its systems internally or has outsourced them. Outsourcing IT moves the work, not the responsibility.
The ten minimum measures in Article 21(2)
The ten points are easier to work with in four groups, because the measures within each group depend on one another and are usually run by the same people.
Governance, risk analysis and effectiveness: points (a) and (f)
Point (a) requires policies on risk analysis and information system security, and it underpins the other nine. The entity needs a documented method for identifying the risks to its systems, assessing their likelihood and impact, and deciding how each is treated, with an owner who is accountable for the decision. It also needs a security policy, approved by management, that sets the rules the rest of the programme follows. Without a risk analysis there is no basis for arguing that any later measure is proportionate, which is why supervisors usually ask for it first.
The annex of Implementing Regulation (EU) 2024/2690, which applies directly to certain digital providers, shows the level of detail regulators consider adequate. It separates the security policy, the definition of roles and responsibilities, and a risk management framework with its own policy and review cycle. A risk register written once for a certification project and never revisited does not meet that standard, because it cannot show that current measures are driven by current risks. The date on the last review is one of the first things a supervisor looks at.
Point (f) closes the loop by requiring policies and procedures to assess whether the measures are effective. This is what turns a set of documents into a managed programme. Assessment can combine internal audits, technical tests such as vulnerability scans and penetration tests, metrics tracked over time, and automated checks that controls are still in place. What a supervisor wants to see is the sequence: the plan, the results, and what changed because of them. Our article on continuous compliance monitoring explains how the last of these works in practice.
Organisations with an ISO 27001 information security management system already do most of this work, because the risk assessment and the performance evaluation clauses ask for the same thing. Our guide to running an ISO 27001 risk assessment walks through the method. The difference under NIS2 is the audience: the results now have to reach the management body, which is responsible for them under Article 20.
Incidents, continuity and crisis management: points (b) and (c)
Point (b) requires incident handling, meaning the ability to detect, analyse, contain and recover from incidents. It connects directly to Article 23, which sets three reporting deadlines for a significant incident: an early warning within 24 hours of becoming aware of it, an incident notification within 72 hours, and a final report within one month. Those deadlines are impossible to meet without a working way of spotting incidents and deciding quickly whether they are significant.
A written incident procedure is therefore only the start. The measure needs a source of alerts, such as endpoint detection and log monitoring, people who review those alerts, severity criteria agreed in advance, a decision path for notification that names who can make the call out of hours, and records of past incidents and what was learned from them. The most common failure is not the absence of a procedure but a procedure nobody has ever run. Our article on NIS2 and DORA incident reporting deadlines sets out what each report must contain.
Point (c) covers business continuity, including backup management and disaster recovery, and crisis management. The question it asks is whether the entity can keep providing its service, or restore it, when its systems are unavailable. That requires knowing which services are critical, how long each can be down before the impact becomes unacceptable, and how each will be recovered. The implementing regulation expects a business continuity and disaster recovery plan built on that analysis, with recovery objectives for each critical service.
The evidence here is concrete and easy to test, which is why gaps show up quickly. A supervisor will ask for the backup policy, logs proving backups ran, the results of restore tests and the record of at least one crisis exercise. Backups that have never been restored are the most frequent weak point, because the failure only appears on the day they are needed. A ransomware scenario that also encrypts the backups is the exercise most organisations should run first.
Suppliers and secure development: points (d) and (e)
Point (d) requires supply chain security, covering the security aspects of the relationship between the entity and its direct suppliers and service providers. For most companies that means cloud providers, managed IT and security providers, software vendors and anyone else with access to systems or data. Recital 85 explains why the directive gives this its own point: many serious incidents have come through vulnerabilities in third party products and services rather than through the victim's own systems.
Paragraph 3 says how to judge which supplier measures are appropriate. Entities must take into account the vulnerabilities specific to each direct supplier, the overall quality of its products and its cybersecurity practices, including its secure development procedures, as well as the results of coordinated EU supply chain risk assessments under Article 22(1). That rules out sending the same questionnaire to every vendor and filing the answers. A managed service provider with administrative access to production needs a much deeper review than an office supplies vendor, and the entity should be able to explain why each critical supplier was judged acceptable. Recital 85 also encourages writing security requirements into contracts, and recital 86 asks for particular diligence when choosing a managed security service provider, because their access makes them an attractive target in their own right. Our guide to third party risk management under DORA and NIS2 covers how to tier suppliers so the effort goes where the risk is.
Point (e) covers security in the acquisition, development and maintenance of systems, including vulnerability handling and disclosure. It applies whether the entity writes software or only buys and configures it, because patching, secure configuration, change control and testing all fall here. Vulnerability handling means a process that finds weaknesses, rates them, fixes them within defined timeframes and records the result. Disclosure means giving outsiders a way to report a vulnerability they have found, such as a published security contact.
For companies with systems facing the internet, the starting point is knowing what is exposed, and that inventory is usually less complete than people assume. Our article on the external attack surface explains why. Organisations that develop their own software also need secure development practices and security testing before each release, which our guide to application security testing covers in detail.
People, access and technical safeguards: points (g) to (j)
Point (g) pairs basic cyber hygiene with cybersecurity training. Recital 89 lists what hygiene means in practice: zero trust principles, software updates, device configuration, network segmentation, identity and access management and user awareness, including training on phishing and social engineering. These are the everyday controls that prevent most incidents, and they are the first things a supervisor checks because they are easy to verify. Training records alone are weak evidence; a stronger programme shows induction training, periodic refreshers, specific training for people with privileged access and some measure of whether behaviour changed, such as phishing simulation results over time.
Point (h) requires policies and procedures on cryptography and, where appropriate, encryption. The policy should state where encryption is required at rest and in transit, which algorithms and key lengths are acceptable, and how keys are generated, stored, rotated and revoked. The usual gaps are not in cloud services, which encrypt by default, but around them: laptops without disk encryption, backups copied to unencrypted storage, keys stored next to the data they protect, and certificates that expire because nobody owns them. The policy only counts if it describes what the organisation actually does.
Point (i) groups human resources security, access control and asset management, three disciplines that fail together. The implementing regulation treats each in detail, from procedures for changes and terminations of employment to an access control policy and the classification and handling of assets. What links them in practice is the leaver process: if HR, IT and the owners of each SaaS application do not share one process, former staff and contractors keep their access for months. A supervisor will typically sample access reviews, the asset inventory and a few recent leavers to see whether their accounts were removed on time.
Point (j) requires, where appropriate, multifactor or continuous authentication, secured voice, video and text communications, and secured emergency communications within the entity. Multifactor authentication on email, remote access, administrative accounts and critical applications is now the baseline expectation, and the exceptions need a documented reason. The emergency communications element is the one most often forgotten. If the main email and messaging platform is compromised during an incident, the response team needs another way to coordinate, agreed in advance and tested in a crisis exercise. It costs little and closes a gap that otherwise appears at the worst moment.
Management approval and liability under Article 20
Article 20 turns the measures into a management responsibility rather than an IT project. The management bodies of essential and important entities must approve the cybersecurity risk management measures taken to comply with Article 21 and oversee their implementation, and they can be held liable for infringements. Their members must also follow training so they can identify risks and assess cybersecurity management practices, and entities are encouraged to offer similar training to employees regularly.
In practice the board or leadership team needs three things on record: a decision approving the measures, regular reporting on how they are working, and its own training. A security programme that runs entirely below leadership leaves the entity exposed under Article 20 even when every technical control is in place, because the directive is explicit that approval and oversight sit at the top. It also changes the conversation inside the company. Requests for budget, for exceptions or for accepting a risk now have to reach the people who are accountable for them.
The most useful format is usually a short quarterly report: the status of each of the ten areas, open gaps with owners and dates, significant incidents and near misses, and decisions the management body needs to take. It gives leadership what Article 20 requires and gives the supervisor a clear trail of oversight.
Stricter detail for digital infrastructure and digital providers
Article 21(5) asked the Commission to adopt implementing acts setting technical and methodological requirements for a group of digital entities, and Implementing Regulation (EU) 2024/2690 does so. It covers DNS service providers, TLD name registries, cloud computing and data centre service providers, content delivery network providers, managed service providers and managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers. Its annex turns each of the ten areas into detailed requirements.
For those entities the regulation applies directly and leaves much less room for interpretation than the directive. For everyone else it is still a practical reference, because it shows the level of detail regulators consider adequate: a supplier directory, a business continuity and disaster recovery plan with defined contents, procedures for termination of employment, an asset classification scheme. Managed service providers deserve particular attention. Many mid sized European IT and security firms fall into that category without ever having thought of themselves as regulated, and they discover it when a customer asks for their NIS2 position.
Using ISO 27001 as the base
Most of Article 21 maps closely onto an ISO 27001 information security management system, and the recitals point to the ISO 27000 series as a reference for the all hazards approach.
- Risk analysis: Clauses 6.1 and 8.2
- Incident handling: Annex A 5.24 to 5.28
- Continuity: Annex A 5.29, 5.30 and 8.13
- Suppliers: Annex A 5.19 to 5.22
- Development and vulnerabilities: Annex A 8.8 and 8.25 to 8.29
- Effectiveness assessment: Clause 9
- Training: Annex A 6.3
- Cryptography: Annex A 8.24
- Access and assets: Annex A 5.9, 5.15 to 5.18, and 6.1 to 6.5
- Authentication: Annex A 8.5
An organisation with a working ISMS is rarely starting from zero, and the sensible route is to extend it rather than build a parallel NIS2 programme. The gaps are specific. ISO 27001 does not impose the Article 23 reporting deadlines, so the incident process needs a notification step with named decision makers. It does not create management liability, so the governance has to be lifted to the management body. And it does not register the entity with a national authority.
A certificate is also not a substitute for compliance. NIS2 does not require ISO 27001, and a certificate does not prove that the national law is met, although it is strong evidence that most of the measures exist and are maintained. The practical approach is a single control set that serves every framework the company needs, which our article on running ISO 27001 and ENS as a single programme describes for Spanish organisations.
What happens when a measure is missing
Paragraph 4 says that an entity which finds it does not comply with a measure in paragraph 2 must take all necessary, appropriate and proportionate corrective measures without undue delay. Finding a gap is not the problem in itself; leaving it open is. A gap register with owners, target dates and progress is exactly the evidence this paragraph expects, and it is far more persuasive to a supervisor than a programme that claims to have no gaps at all.
Article 34 sets the penalties for infringements of Articles 21 and 23. Member States must provide maximum fines of at least €10 million or 2% of total worldwide annual turnover for essential entities, and at least €7 million or 1.4% for important entities, whichever is higher in each case. National laws set the final amounts and procedures. Fines are not the only tool: supervisors can issue binding instructions, order audits and order entities to inform the recipients of their services about a significant cyber threat and the protective measures they can take. For essential entities they can also temporarily suspend certifications or authorisations.
Where Qalea fits
Article 21 is easier to meet when the ten areas run as one programme rather than ten separate projects. The Qalea platform maps NIS2 to the same control set used for ISO 27001, ENS and DORA, so each control and its evidence are recorded once and serve every framework the company needs. Qalea's team guides the work, from the risk analysis to the reporting the management body needs under Article 20, and companies that already run their programme elsewhere can bring their existing material across.
Several of the measures depend on security work that runs every day rather than on documents: incident detection, vulnerability handling, effectiveness testing and training. Qalea covers these with EDR, SIEM and a SOC for monitoring, attack surface management and penetration testing for exposure, and awareness training with phishing simulation, so the evidence a supervisor asks for comes from controls that are actually operating. Our NIS2 topic page has more on the directive.
