What NIS2 Article 21(1) asks for and why proportionality is the hard part
Article 21(1) requires an essential or important entity to take appropriate and proportionate technical, operational and organizational measures to manage risks to its network and information systems, and to prevent or minimize the impact of incidents on its service recipients and on other services. The duty applies to the whole entity, not to one system or one department, and it is judged against the entity's own risk profile. Technical measures are the controls built into systems and networks, operational measures cover how those systems are run day to day, and organizational measures cover the policies, roles, decisions and governance around them. A supervisor will look for all three, and a strong firewall estate with no owner for risk decisions will not meet the test.
The measures must reflect the state of the art, relevant European and international standards where applicable, and the cost of implementation. Those three tests pull against each other. Proportionality depends on the entity's risk exposure, its size, and the likelihood and severity of incidents, including their societal and economic impact. Recital 79 makes the scope all-hazards, so the risk picture must include theft, fire, flood, telecommunication or power failures and unauthorized physical access, not only cyber intrusion. The hard part is justifying the level chosen: a documented risk assessment, a stated rationale for each measure, and evidence that the spend matches the risk. Confirm with your national competent authority how it expects that reasoning to be recorded, because guidance varies by Member State.
Article 21(4) adds a continuing duty. If an entity finds that it does not comply with the Article 21(2) measures, it must take all necessary, appropriate and proportionate corrective measures without undue delay. Plan for this before an assessment finds the gap. Keep a register of identified gaps with owners, dated corrective actions and the management decisions that approved them, because a supervisor will ask how quickly you acted once you knew. The ten minimum measures that Article 21(2) lists are covered in the sibling sections of this guide.
Which entities, systems and risk factors set the proportionality bar
Article 21(1) does not give one fixed control set. It asks each essential and important entity to size its measures to its own exposure, size, incident likelihood and severity, and wider societal and economic impact. The decisions below are where that sizing becomes concrete work, and both essential and important entities carry the same duty.
Essential and important entities share one duty
Essential and important entities face the same Article 21 risk-management obligation. The difference lies in supervision: essential entities face ex ante supervision and important entities ex post supervision (Articles 32 and 33). Classification therefore changes when an authority looks at your measures, not what the measures must cover. Confirm your classification with your national competent authority or legal counsel before you size the program, because the same proportionality analysis applies to both categories.
Risk exposure and incident impact
Article 21(1) ties proportionality to how exposed the entity is and how severe a failure would be for its service recipients and for society. An entity that runs critical customer-facing services or depends on a few shared platforms usually needs deeper controls than a peer with a narrow footprint. Document the threat sources you considered, the services you rely on and the societal and economic consequences of disruption, so an assessor can see how the risk picture set the level of each measure.
Scope of network and information systems
Proportionality starts with which network and information systems the measures cover. Map the systems that support the entity's in-scope services, including identity providers, backup platforms, logging pipelines and administrative tooling, because a gap in any of them can defeat the controls elsewhere. Scoping too narrowly is a common reason an assessor finds the risk analysis incomplete. Record the boundary and the reasons for each inclusion or exclusion.
Sector-specific rules and displacement
Some sectors already have binding rules on security or resilience. Where sector-specific EU law sets equivalent or stricter requirements, it can displace parts of NIS2 for the relevant entities, and national law may add obligations under Article 5. Before you decide how far the Article 21 measures reach, check whether another regime already governs the same systems, and identify which requirements it covers so you avoid duplicated or conflicting work. Confirm the position with your sector regulator.
Group entities and shared platforms
Entities that belong to a group often run shared identity, network or cloud platforms that serve several legal entities. Decide which entity owns each control, how responsibilities are split, and how the group-level policy is applied locally. Where one parent operates the platform, the subsidiaries still need to show how they meet their own Article 21 duty. Ask who holds the evidence for each shared control and how quickly it can be produced for a supervisor.
Third-party and managed services
Outsourced hosting, managed security, software providers and cloud services change where risk sits but do not remove the entity's own duty. Proportionality here means deciding how deeply to verify each provider, which contract terms to require, and which monitoring to keep in-house. Include the services that could halt your operations if they failed, and record why the depth of review matches the dependency. Confirm each provider's own security evidence before relying on it.
How to build a proportionate measures baseline step by step
This sequence turns the Article 21(1) duty into a documented baseline: a defined scope, a risk basis for proportionality, measures chosen against the state of the art, recorded cost decisions, named owners and a corrective path under Article 21(4). Each step leaves an artifact an assessor or supervisor can read.
Confirm entity scope and classification
Start by confirming that NIS2 applies to the organization, which Annex I or Annex II sector it falls under, and whether it is classified as essential or important. Legal or compliance staff should confirm this with the national transposition law of each Member State where the entity operates, since the national rules determine jurisdiction and supervision. The output is a short scope statement naming the entities, services, networks and information systems in scope. The step is done when management has approved that statement.
Document the risk basis for proportionality
Record the factors Article 21(1) asks you to weigh: risk exposure, entity size, the likelihood and severity of incidents, and their societal and economic impact. Include all-hazards events such as fire, flood, power or telecommunications failure and unauthorized physical access, not only cyber threats. The output is a risk assessment register that explains how each factor was scored and why. The step is done when the scoring method is written down well enough that a supervisor could repeat it.
Select measures against state of the art and standards
Map the identified risks to candidate technical, operational and organizational measures. Check each candidate against the state of the art and against relevant European and international standards where they apply, and check whether Implementing Regulation (EU) 2024/2690 sets a requirement for your sector. Where the regulation qualifies a requirement with wording such as 'where appropriate' and you decide not to apply it, write the reasoning down. The output is a measures register linking each risk to selected controls, with the rationale for each exclusion.
Record cost-based decisions
Article 21(1) allows implementation cost to shape the measures, but the reasoning must be visible. For each measure you defer, substitute or scale back, record the cost estimate, the residual risk and the decision owner who accepted it. Ask vendors and internal teams for itemized costs for licenses, hosting, staff time and external services, and separate one-time costs from recurring ones. The output is a decision log that shows a cost-driven choice was made deliberately and approved at the right level.
Assign owners and approval paths
Give every measure in the register a named owner, a backup, and a reviewing body. Management must approve and oversee the measures, so record that approval in the minutes or governance record. Owners should be able to show current evidence for their measures, such as configuration exports, policy versions or test results. The output is a responsibility matrix with owners, approvers and evidence sources. The step is done when no measure lacks an accountable person.
Compare the baseline with current state
Test the existing environment against the measures register and record every gap in a gap log. For each gap, note the affected systems, the severity, the owner and the planned fix. Where a gap cannot be closed immediately, document the interim safeguard and who accepted the residual risk. The output is a gap log with owners and target actions, reviewed by management. Confirm the findings with system owners rather than relying on documentation alone.
Set the Article 21(4) corrective action path
When the entity finds that it does not meet an Article 21(2) measure, it must take all necessary, appropriate and proportionate corrective measures without undue delay. Define how gaps are detected, who decides on corrective action, how fixes are verified and when management is informed. Link this path to the gap log and the decision log so each correction leaves a trail. The output is a written corrective action procedure and a tracked remediation queue. The step is done when a test finding can be followed from detection to verified closure.
How a supervisor tests proportionate measures
This table sets out the four questions a national competent authority is likely to ask about Article 21(1), the evidence it will request for each, and the findings that most often lead to follow-up. Read each row as a test a supervisor applies to the documented record, not only to the systems themselves.
| Test question | Evidence the supervisor requests | Common finding |
|---|---|---|
| Is there a documented risk basis? | Risk assessment method, current risk register, risk owners, approval record from the management body | Risk assessment is dated, covers only IT systems, or does not reference the entity's services and sectoral context |
| Do measures trace back to identified risks? | Measure register mapping each technical, operational and organizational measure to the risks it treats | Generic measure list copied from a template with no link to any identified risk |
| Were state of the art, standards and cost considered? | Decision records showing options considered, standards referenced, cost and effort assumptions, and reasons for rejecting alternatives | No record of cost or state-of-the-art reasoning, so proportionality cannot be shown |
| Is known non-compliance corrected without undue delay? | Gap register, remediation plan with owners and dates, change or ticket history, and evidence that closed items were verified | Gaps are known from audits or tests but no corrective action or timeline is recorded |
| Does the record hold up over time? | Review history showing risk assessments and measures were updated after incidents, audits or significant changes | Documents are signed once and never revisited, so they no longer match the environment |
| Where the implementing regulation allows discretion, is the reasoning written down? | Documented justification for any requirement marked 'where appropriate' or 'to the extent feasible' that was not applied | Discretion is claimed in the measure register without any reasoning on file |
How proportionality is judged when no fixed checklist exists
Article 21(1) sets no fixed checklist, so the entity itself must show why its measures are appropriate and proportionate. The test is not whether a control exists but whether the set of measures fits the entity's risk exposure, size, the likelihood and severity of incidents, and their possible societal and economic impact. A supervisor will look for a traceable line from those factors to the choices made, so the reasoning matters as much as the outcome. Management should record the risk drivers it considered, the alternatives it rejected and the reason each decision was taken.
Three inputs shape that reasoning. The state of the art asks whether a measure is current practice for the entity's kind of system, not merely what was installed years ago. Relevant European and international standards apply where they are applicable, so an entity that uses a recognized management system as its backbone has a ready reference point for its choices. Implementation cost is also a legitimate factor, but it is weighed against risk rather than used to exclude a measure that the risk clearly requires. Confirm with your national competent authority how it reads these factors, because transposition laws and supervisory practice differ between Member States.
Where Implementing Regulation (EU) 2024/2690 uses qualifiers such as 'where appropriate', 'where applicable' or 'to the extent feasible', Article 2(2) requires documented reasoning if the entity decides not to apply the requirement. That record is the practical proof of proportionality. The non-binding technical guidance ENISA published on 26 June 2025 gives examples of the evidence supervisors may expect, which is a useful starting point for deciding what to keep. Treat each documented decision as a living record: review it when the risk picture, the systems or the regulation change, and correct any non-compliance without undue delay under Article 21(4).
Evidence that shows measures are proportionate and current
Article 21(1) is judged on reasoning as much as on controls. The six artifacts below link the risk picture, the measures chosen, the decisions made about them and the corrections taken, so a supervisor can trace each measure back to a risk. Each record only holds value if it is refreshed between formal reviews.
Documented risk assessment
This is the starting point for proportionality. It records the assets and services in scope, the threats considered (including all-hazards events such as fire, flood, power or telecommunication failures and unauthorized physical access), the likelihood and severity of each scenario, and the societal and economic impact on service recipients. Between reviews, log new services, major changes, significant incidents and threat intelligence that alters a likelihood score, and date each change so the trail is visible.
Measures register linked to risks
A register lists each technical, operational and organizational measure, its owner, its implementation status and the risk entries it addresses. Proportionality is shown when a higher-risk scenario has stronger or more frequently tested measures than a lower one. Keep the register live by updating status and owner whenever a control changes, and check each entry against the current risk list at least once per quarter so that orphaned measures and unmitigated risks are caught early.
Decision records for qualified or non-applied measures
Where an implementing requirement is qualified by wording such as "where appropriate", "where applicable" or "to the extent feasible" and the entity decides not to apply it, the reasoning must be documented in a comprehensible manner. Each record should name the requirement, the decision, the risk and cost factors weighed, the compensating measure and the approver. Review each record whenever the underlying risk or technology changes, because a decision that was sound for one architecture may not hold for the next.
Cost and state-of-the-art rationale
Article 21(1) requires measures to reflect the state of the art, relevant European and international standards where applicable, and implementation cost. This record explains why the chosen measures are current and why spending on them is proportionate, citing the standards consulted and the options considered and rejected. Refresh it when a standard is revised, when a technology reaches end of support or when the budget decision changes, and confirm the standard versions you cite against the publisher's current edition.
Article 21(4) corrective action log
Article 21(4) requires an entity that finds it does not comply with the Article 21(2) measures to take all necessary, appropriate and proportionate corrective measures without undue delay. The log records each gap, when it was found and by what means (self-assessment, audit, scan or incident), the corrective action, the owner, the target date and closure evidence. Keep it current as a working document rather than a yearly report, and make sure each closed item links back to the register entry it changed.
Review and approval records
Management approval and periodic review show that the measures are kept under oversight. Records include the date of each review, the inputs considered, the changes approved and the management body's sign-off. Article 20 places approval and oversight of the Article 21 measures with the management body, so the minutes should show who decided and on what basis. Schedule reviews at a defined interval and also trigger them after significant incidents, major changes or new threat information, and confirm the interval with your national authority's guidance.
Covering cyber and non-cyber hazards under the same duty
Recital 79 of NIS2 lists theft and unauthorized physical access among the events an entity's measures should cover. The point is that an attacker who walks into a server room, takes a laptop or copies a backup drive can achieve the same loss of confidentiality or integrity as a remote intruder. Article 21(1) asks for appropriate technical, operational and organizational measures, so physical controls belong inside the same risk assessment as cyber controls rather than in a separate facilities file.
- Site and room controls: access rules, badge or key management, visitor logging and escort rules for data centers, network rooms and records storage.
- Asset custody: where laptops, removable media and backup media are kept, and how their loss is detected and reported.
- Monitoring: cameras, intrusion alarms and guard coverage, with retention periods that match the entity's incident records.
- Joiner and leaver steps: physical access revoked on the same trigger as logical access.
Before a supervisor visit, confirm that physical access logs and asset custody records can be matched to the same identities and incident records used for cyber events.
Fire and flood are named in Recital 79 as examples of events that can disrupt network and information systems. They are usually treated as facilities or business continuity risks, yet they affect the same availability and recovery commitments that NIS2 expects the entity to manage. A risk assessment that ignores the server room above a water main, or the single rack that shares a power circuit with a fire-suppression system, leaves a gap that a supervisor may question.
- Site risk review: location hazards such as flood plains, adjacent fuel storage and building age, recorded against each critical system.
- Detection and suppression: smoke, heat and water sensors with alerting routed to people who can act, and documented suppression systems.
- Offsite copies: backups and recovery environments kept far enough from the primary site to survive the same event.
- Test records: evidence of drills, sensor tests and recovery exercises, not only the design drawings.
Ask the facilities team and the platform team to confirm that the same site list drives both the risk register and the continuity plans.
Telecommunication and power failures are the third category in Recital 79. Many outages that look like cyber incidents start as loss of power, network circuits or carrier services, and a security team cannot respond to an attack on systems it cannot reach. Supervisors commonly look for dependency mapping that shows which systems depend on which utilities and providers, and what happens when one of them fails.
- Dependency map: power feeds, network carriers, DNS and telephony providers linked to each essential service.
- Redundancy evidence: documented alternate feeds, uninterruptible power and failover paths, with the last recorded test.
- Out-of-band access: a way to reach administrative consoles and the incident team when the primary network is down.
- Supplier clauses: contractual service levels and notification duties from utility and telecom providers, linked to the supply chain register.
Check that power and carrier outages are classified and reported through the same incident process used for cyber events.
NIS2 does not prescribe an org chart, but the management body remains accountable for the Article 21 measures, and each hazard category needs a named owner. In many organizations, cyber risk sits with the security team, physical and site risks with facilities or corporate security, and utility and telecom dependencies with infrastructure or operations. Gaps appear where no one owns the boundary, such as the cabling between a building and a rack. A single risk register with clear owners per hazard category makes the overlap visible.
- Named owners: one accountable person per hazard category, recorded in the risk register and approved under the governance process.
- Shared register: cyber, physical and utility risks scored on the same scale so they can be compared.
- Joint reviews: periodic sessions where security, facilities and operations walk through the same scenarios.
- Documented handoffs: how an event moves between teams during an incident and who decides on escalation.
Confirm with the management body which person signs off the combined risk picture, and how that approval is evidenced.
Supervisors assess whether an entity's measures are proportionate and actually operate, so they usually ask for records rather than descriptions. For physical and utility risks, the evidence should look like the evidence for cyber risks: a documented assessment, assigned owners, implemented controls, tested recovery and records of the last review. National competent authorities set their own inspection practices under national transposition laws, so the exact requests will vary by Member State and sector. The safest approach is to build one evidence trail that covers all hazard types.
- Risk assessment entries: each hazard listed with likelihood, impact and the treatment chosen.
- Control records: access logs, sensor test results, maintenance records and dependency reviews.
- Test and exercise results: drills and recovery tests with dates, participants and findings.
- Corrective actions: tracked fixes under Article 21(4) with owners and closure dates.
- Management approval: minutes or sign-offs showing the combined risk picture was reviewed.
Ask your national competent authority or sector regulator which records they expect for physical and utility risks, and store them in the same system as cyber evidence.
What meeting Article 21(1) costs in money and effort
This table lists the cost components of meeting the Article 21(1) duty, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request, since no price or duration for this work is published in the researched facts.
| Cost component | Who is paid or who spends time | One-time or recurring | Main cost drivers |
|---|---|---|---|
| Risk assessment effort | Internal risk owners and external risk specialists, if engaged | One-time setup, then recurring reviews | Number of systems, service dependencies, sector and changes in threat exposure |
| Internal staff time | Security, IT, operations and legal staff, plus management time for approval | Largely recurring | Entity size, number of teams involved, and how much documentation already exists |
| Tooling and licenses | Vendors of commercial GRC, scanning or monitoring tools | Usually recurring subscriptions or maintenance | Number of users and assets, and whether modules are bundled or priced separately |
| Self-hosted open-source tooling | Infrastructure costs in the client's environment, plus setup and operations staff | Mostly one-time setup, with recurring hosting and upkeep | Hosting capacity, integration work and the staff available to run the platform |
| External review | Independent assessors or consultants who challenge the measures | Periodic, tied to review cycles or audits | Scope breadth, sector expectations and whether the review covers evidence or only design |
| Evidence upkeep | Control owners who collect and retain records | Recurring | Frequency of required evidence, retention rules and the number of controls in scope |
| Corrective work under Article 21(4) | Technical teams, vendors and sometimes managed service providers | Triggered, irregular and sometimes large | Size of the gap found, age of legacy systems and the urgency set by the entity's own timeline |
| Proportionality decisions | Management body and risk owners documenting why a measure is or is not applied | One-time per decision, revisited on change | Number of qualified requirements invoked and the clarity of the rationale recorded |
How CISO Assistant can hold the proportionality evidence
Article 21(1) asks entities to justify their measures against risk, state of the art and cost, so the reasoning matters as much as the controls. The cards below describe the records a GRC tool such as CISO Assistant can hold, and what the team must confirm before relying on it for that purpose.
Framework library and NIS2 mapping
CISO Assistant ships more than 200 frameworks, including NIS2, and maps requirements between them automatically. For Article 21(1), this lets a team show one set of measures answering several obligations at once, such as NIS2 alongside ISO 27001 or DORA. Confirm which NIS2 requirement set is loaded and whether the mapping matches the scope your competent authority expects.
Risk basis register
Proportionality starts with a documented view of risk exposure, entity size, and the likelihood and severity of incidents, including societal and economic impact. A risk register in the tool can record these inputs, owners and treatment decisions so each measure traces back to a stated risk. Check whether the register supports the scoring method you have chosen and whether risk entries can be versioned.
Measures register with justifications
Each Article 21(2) measure needs a record of its status, owner and the risk it addresses. Where the implementing regulation allows an entity to skip a requirement qualified by 'where appropriate' or 'to the extent feasible', the reasoning must be documented in a comprehensible way. Use the measures register to hold that justification next to the decision, and confirm the tool keeps the rationale attached when a status changes.
Assessment records and evidence links
Assessments show whether measures work in practice, and supervisors will ask for dated results. CISO Assistant can run audits and compliance assessments against loaded frameworks and store evidence against each requirement. Confirm that assessment history is retained as separate snapshots, so an earlier result is not overwritten when a control is later reassessed.
Corrective action tracking
Article 21(4) requires entities that find a gap to correct it without undue delay. Tracking findings as actions with owners, due dates and closure evidence turns that duty into a record a supervisor can review. Confirm how the tool handles overdue actions, reopened findings and risk acceptance, since these are the points where proportionality decisions are most often challenged.
Licensing and fit checks
CISO Assistant is licensed under AGPL-3.0-only. That license governs how the software may be used, modified and distributed, and it may affect how you deploy or extend it inside your organization. Have legal and procurement review the license terms, then test the workflows against your own risk method and assessment process before treating the tool as the system of record.
Who decides proportionality, who builds the evidence and who assesses it
The management body and risk owners decide what proportionate means for the entity. Article 21(1) ties the measures to risk exposure, entity size, the likelihood and severity of incidents, and their societal and economic impact, and the entity must be able to show how those factors were weighed. No vendor, consultant or assessor can accept that risk on the organization's behalf, so these decisions stay with the people who can answer for them.
- Risk acceptance. Name who accepts residual risk for each service and record the threshold above which a risk returns to the management body.
- Proportionality decisions. Record why each measure is applied in full, scaled down or not applied. Where Implementing Regulation 2024/2690 uses qualifiers such as "where appropriate" or "to the extent feasible", Article 2(2) requires comprehensible reasoning for any decision not to apply the requirement.
- Corrective action. Under Article 21(4), decide which corrective measures close a gap against the Article 21(2) measures, set deadlines and name who signs off closure.
- Budget and people. Approve the money and staff the measures need, since implementation cost is one of the factors Article 21(1) names.
- Governance records. Keep minutes and approvals that show the management body reviewed the measures, because supervisors will ask for them.
Check that every proportionality decision has a named owner, a date and a written rationale before an authority or assessor asks to see it.
An implementation partner does the technical and documentary work that produces evidence. For a self-hosted open-source platform, that can mean deploying the platform inside the client's own cloud accounts, data centers or air-gapped networks, configuring logging and access controls, setting up backups, drafting procedures and loading risk records into a governance tool. The partner prepares systems and evidence. It does not decide proportionality and it does not certify anything.
- Build and configuration. Deploy and harden the platform, and record a configuration baseline so the entity can show what was running on a given date.
- Evidence preparation. Collect configuration exports, access reviews, test results and change records in a form the entity's own staff can keep up after handover.
- Documentation drafting. Draft policies and procedures for management to review and adopt. Adoption and ownership remain with the entity.
- Governance tooling. Set up a tool such as CISO Assistant, which is licensed under AGPL-3.0-only and ships frameworks including NIS2, to hold risk assessments and control status. Confirm in the project's documentation which features you need before relying on them. CISO Assistant on GitHub
- Knowledge transfer. Train internal owners so they can run the evidence process without the partner in the room.
Ask any partner which artifacts it will hand over, who keeps the source of truth and what the entity must run itself once the engagement ends.
Each Member State designates national competent authorities that supervise compliance with the risk-management duties. Essential entities face ex ante supervision, so the authority can act before a problem surfaces, while important entities face ex post supervision, so action follows evidence that something is wrong (Articles 32 and 33). The authority tests what the entity claims. NIS2 creates no certificate of compliance, so no document is issued to say that an entity passed.
- Supervisory tools. Inspections, security audits, security scans and information requests, as set out in Articles 32 to 34.
- Penalties. Administrative fines under Article 34, as applied through national transposition law. Confirm the figures in your Member State's law rather than relying on secondary summaries.
- Competent authority identity. Identify the authority that supervises you and the national rules that transposed NIS2, since national law can add requirements.
- Typical requests. Expect requests for the risk analysis, policies, incident records and the trail that shows the Article 21(2) measures operating over time, not only at one point.
- Multi-country exposure. Entities that operate in several Member States may face more than one authority, so map where you are established and where you provide services.
Confirm which authority supervises you, what the national law adds and how supervision is exercised before you prepare evidence.
An independent assessor tests whether the measures work and reports what it found. That role must stay separate from the partner's role. An assessor that designed or operated the controls it then tests has a conflict of interest, so a sound engagement keeps the two apart. An entity may commission an assessment for assurance or to answer a customer's request, but an independent report is not a NIS2 certificate and does not replace supervision by the authority.
- Independence. The assessor should not have built the systems or written the evidence it tests.
- Scope. Agree in writing which entities, systems, periods and Article 21 measures the assessment covers.
- Framework fit. If the entity uses a standard as its assurance route, confirm the assessor is authorized to assess against that standard and check its scope with the assessor and the standard's owner.
- Findings and reports. Only the assessor issues findings, reports and any certificate. The entity answers those findings with corrective action under Article 21(4).
- Records. Keep the assessor's report and the entity's response together so they can be shown to the authority.
Before signing, ask which parts of the work the assessor will not perform for you, and put that boundary in the engagement letter.
Where entities usually fall short on Article 21(1)
Most Article 21(1) findings are not missing tools. They are missing decisions: why a measure fits the entity's risk, why its cost and the state of the art were weighed, why a measure was left out, and how gaps were corrected. Each card names one gap and a concrete way to close it before a supervisor asks.
Generic measures not tied to risk
Many programs adopt a standard control set copied from a template and never link it to the entity's own risk assessment. Article 21(1) ties the measures to risk exposure, entity size, and the likelihood and severity of incidents, including societal and economic impact. To close the gap, map each measure to a named risk in the register, record the exposure it addresses, and drop or add measures where the link is missing. Check that the register covers physical events such as fire, flood and power failure, not only cyber threats.
No record of cost or state-of-the-art reasoning
Article 21(1) requires measures to reflect the state of the art, relevant European and international standards where applicable, and implementation cost. Few entities write down how they weighed these factors, so a supervisor sees a decision with no reasoning behind it. Keep a short decision record for each major measure that states the options considered, the standard or guidance consulted, the cost trade-off, and the date of review. Confirm which standards apply to your sector with your supervisor or the national transposition law.
Undocumented non-application decisions
The implementing regulation lets entities skip some requirements where they are qualified by wording such as 'where appropriate' or 'to the extent feasible'. Under Article 2(2), an entity that decides not to apply such a requirement must document its reasoning in a comprehensible manner. Gaps appear when teams quietly skip a requirement and never write why. Maintain a register of non-applied requirements with the justification, the risk accepted, the approver and a review date, and link each entry to the affected system.
No Article 21(4) correction trail
When an entity finds it does not meet an Article 21(2) measure, Article 21(4) requires all necessary, appropriate and proportionate corrective measures without undue delay. Many entities fix problems informally, so no record shows when the gap was found, what was done and when it closed. Open a finding for each gap with an owner, a corrective action, a target date and a closure check. Keep the tickets, retest results and sign-off together so the trail can be shown to a supervisor.
Management not reviewing measures
Article 21 measures are approved and overseen by the management body under Article 20, so a program the board has never reviewed is hard to defend. Reviews often happen inside technical teams and never reach the decision makers who carry liability. Put the Article 21 measures, open findings, accepted non-applications and cost decisions on a recurring management agenda. Record the minutes, the decisions taken and the questions asked, and keep the evidence that directors received the material.
Risk register and measures drift apart
Risk registers are often refreshed once a year while systems, suppliers and threats change monthly. When the register and the measure set diverge, the proportionality argument in Article 21(1) no longer holds, even if each document looks complete on its own. Set a trigger for review, such as a major system change, a new supplier, a significant incident or a new vulnerability class, and require the register and the measure list to be checked together. Confirm the review cadence with your own governance policy.
Questions buyers ask about Article 21(1) cost, effort and outside help
How much effort does proportionate risk management under Article 21(1) take?
The effort depends on how many systems are in scope, how mature current security processes are, and how exposed the entity is to incidents. Proportionality is the legal test, so the work starts with a documented view of risk exposure, entity size, incident likelihood and severity, and societal or economic impact. Effort rises with the number of network and information systems, the number of sites and suppliers, and the gap between existing evidence and what an assessor will ask for. Reducing scope through clear service boundaries and an honest asset inventory usually shortens the work. No fixed figure is supplied for this, so ask any provider to break its estimate into inventory, risk analysis, control gap review and evidence preparation.
Can we do the Article 21(1) work in-house?
Yes, many organizations do the core work internally, provided they have people who understand both the systems and the regulation. Internal teams are well placed to own the asset inventory, business context and the decisions about risk treatment. Gaps usually appear in independent challenge, in mapping controls to the implementing regulation's requirements, and in producing evidence that a supervisor can test without help. A practical split is to keep decisions and ownership in-house and bring in outside help for specific gaps, such as a gap analysis or a technical review of a system.
What does Article 21(1) require from management?
Management must approve the measures and oversee their implementation, because the duty is owned at the level of the management body under the NIS2 governance rules. In practice, leaders need to approve the risk assessment outcomes, accept residual risk, fund the corrective work and receive regular reports on whether measures work. Delegating the technical work is possible, but accountability is not. Ask your legal team to confirm how the national transposition law assigns these duties in your Member State.
Is there a NIS2 certificate that proves compliance with Article 21(1)?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Some organizations also seek external assessments against recognized standards to support their evidence, but those are voluntary and do not replace supervision. Only an independent auditor or certification body can issue a report or certificate against a standard, and an implementation partner cannot.
What can an implementation partner handle for Article 21(1), and what stays with us?
An implementation partner can prepare systems and evidence: deploying self-hosted open-source platforms for asset inventory, risk registers, policy workflows and monitoring, hardening them, documenting configurations and organizing evidence for supervisors. DeployOpen plans, implements, integrates, hardens and documents these platforms inside your own infrastructure, and runs security testing that feeds the risk analysis. The organization keeps ownership of its controls, risk acceptance, policy approval and management decisions. Any independent assessment is performed by an external auditor, not by the partner.
How long does this take, and what drives the duration?
No fixed duration is supplied for this work, and it depends on scope. The main drivers are the number of systems and sites in scope, the state of the asset inventory, how many suppliers and service providers must be considered, whether existing risk analysis is documented, and the availability of decision-makers for approvals. Organizations that already run a mature security management process usually move faster than those starting from undocumented practices. Ask any provider for a timeline that is tied to named deliverables and dependencies.
How should we scope a quote for this work?
Scope the quote by listing the entities and sites covered, the network and information systems in scope, the existing documents you already have, the evidence you need to produce, and the decisions management must take. Ask the provider to state deliverables, exclusions, assumptions, who performs each task and what is one-time versus recurring, such as ongoing support or periodic reviews. Compare quotes on the same written scope, not on headline totals. DeployOpen works on fixed-scope engagements agreed in writing before work starts, and a quote follows from that written scope.
How DeployOpen prepares Article 21(1) evidence
DeployOpen starts this work with a written scope that names the entity, the systems in the network and information system boundary, the sites and cloud accounts involved, and the deliverables. Once the scope is agreed, DeployOpen helps the organization document its risk basis and a measures register: the list of technical, operational and organizational measures, the risk each one addresses, the owner, and the review date. The organization makes the decisions behind that register, including how it weighed the state of the art, implementation cost, entity size and the likely impact of incidents. DeployOpen can prepare the drafts, but management approval and ownership stay with the organization.
On the technical side, DeployOpen implements and hardens the self-hosted open-source platforms inside the client's own infrastructure, whether that is their cloud accounts, data centers or an air-gapped network. The aim is that the platforms generate the records an assessor will ask for: configuration baselines, access logs, change records, backup job results and monitoring output. Where Article 21(4) applies because a measure is found to be missing or weak, DeployOpen can document the corrective work, the owner and the date it was completed, so the entity can show the correction was made without undue delay. Ask for a clear list of which platform produces which record before work starts.
DeployOpen prepares systems, controls and evidence for assessment. It does not issue audit reports, attestations or certifications. Those come only from the independent authorities or assessors that the relevant Member State designates or the organization engages for a recognized assessment. Before you commit to a scope, confirm with your national competent authority or your assessor which evidence they expect, how they want it packaged, and whether any part of the work must be independent of the party that implemented it. NIS2 itself creates no certificate of compliance, so a readiness engagement should be measured by how well the records hold up under the assessor's review.
