NIS2 Directive

Sets out what the Directive does: lay down measures to achieve a high common level of cybersecurity across the Union, obliging Member States to adopt national strategies and designate authorities, laying down risk-management and reporting rules for entities in the sectors listed in Annexes I and II, and establishing rules on information sharing, supervision and enforcement.

• No entity artefact. Retained so the modelled Directive is complete and so the reader can see this article was considered and excluded.
• Reason recorded on the node: Scoping article addressed to the Union legal order. It states what the instrument covers and imposes nothing an entity can comply with.

• Treating a scoping or definitional article as a control, which inflates the denominator every coverage percentage divides by.

Determines which entities the Directive applies to, by sector, size and entity type, together with the exceptions and the cases in which Member States may bring smaller or additional entities in. The consequences of falling inside scope are carried by the obligation articles rather than by this one.

• No entity artefact. Retained so the modelled Directive is complete and so the reader can see this article was considered and excluded.
• Reason recorded on the node: Scoping article addressed to Member States. An entity uses it to determine applicability, and the resulting duties are modelled at Article 3(4) and in Chapter IV.

• Treating a scoping or definitional article as a control, which inflates the denominator every coverage percentage divides by.

Classifies in-scope entities as essential or important, requires Member States to establish and maintain the list of those entities by 17 April 2025 and to review it at least every two years, and requires competent authorities to report entity numbers to the Commission and the Cooperation Group. The one entity-facing duty in this Article, submitting and updating registration information, is carried separately at Article 3(4).

• No artefact of its own. The entity-facing paragraph inside this article is modelled as a separate control and carries the evidence.
• Reason recorded on the node: Classification and Member State list-keeping article. The entity-facing paragraph is modelled as the separate obligation Article 3(4), so counting this node as well would double count it.

• Counting both the article and its entity-facing paragraph, which double counts one obligation.

An entity inside scope must give its national competent authority the identifying information the Member State needs to place it on the list of essential and important entities: legal name, address and current contact details including email addresses, telephone numbers and the IP ranges it uses, the Annex I or Annex II sector and subsector it falls under where one applies, and the list of Member States in which it provides services covered by the Directive. Where the entity is a domain name registration service provider it registers on that basis rather than as an Annex I or II operator. Any change to those details has to reach the authority without delay and in no case later than two weeks after the change takes effect, which makes this a standing data-maintenance duty rather than a one-off filing. Member States were required to build their lists by 17 April 2025 and to refresh them at

• The registration submission as filed with the national competent authority, dated
• The internal determination of essential or important status and of the Annex I or II sector and subsector relied on
• The current list of Member States in which in-scope services are provided, and how it is kept current
• The IP ranges declared, and the process that reconciles them against what the entity actually announces
• A change log showing each amendment notified and the date it was sent, evidencing the two-week limit

• Registered once at go-live and never updated after a merger, rebrand or address change
• IP ranges declared from a stale inventory that no longer matches production
• Cross-border service provision not declared, so only the home Member State knows the entity exists
• No owner named for the filing, so the two-week change window has nobody watching it

Governs the relationship with sectoral Union acts. Where a sectoral act imposes cybersecurity risk-management or reporting requirements at least equivalent in effect to those of this Directive, the sectoral act applies instead, which is how DORA displaces NIS2 for financial entities.

• No entity artefact. Retained so the modelled Directive is complete and so the reader can see this article was considered and excluded.
• Reason recorded on the node: Conflict of laws rule addressed to the Union legal order. It changes which instrument binds an entity but imposes no requirement of its own.

• Treating a scoping or definitional article as a control, which inflates the denominator every coverage percentage divides by.

Confirms that Member States may adopt or maintain provisions ensuring a higher level of cybersecurity than the Directive requires, provided they remain consistent with Union law.

• No entity artefact. Retained so the modelled Directive is complete and so the reader can see this article was considered and excluded.
• Reason recorded on the node: Harmonisation clause addressed to Member States. It permits stricter national law rather than imposing anything itself.

• Treating a scoping or definitional article as a control, which inflates the denominator every coverage percentage divides by.

Defines the terms the Directive uses, including network and information system, security of network and information systems, incident, near miss, significant cyber threat, entity, managed service provider and the other terms the obligation articles rely on.

• No entity artefact. Retained so the modelled Directive is complete and so the reader can see this article was considered and excluded.
• Reason recorded on the node: Definitional article. Terms are used throughout the obligation set and carry no separate compliance action.

• Treating a scoping or definitional article as a control, which inflates the denominator every coverage percentage divides by.

Requires Member States to designate or establish one or more CSIRTs covering the sectors in Annexes I and II, to resource them adequately and to ensure they can communicate securely.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Duty on Member States to stand up CSIRTs. It creates the recipient of the Article 23 notifications rather than an obligation on the notifier.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Specifies what CSIRTs must be able to do, including monitoring cyber threats, providing early warning and alerts, responding to incidents, performing dynamic risk analysis and participating in the CSIRTs network.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Duty on Member States and their CSIRTs. It describes the capability an entity can call on, not one it must have.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires each Member State to designate a CSIRT as coordinator for coordinated vulnerability disclosure, acting as trusted intermediary between finders and vendors, and requires ENISA to develop and maintain the European vulnerability database.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Duty on Member States, their CSIRTs and ENISA. The entity-facing vulnerability handling and disclosure duty sits in Article 21(2)(e).

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires the competent authorities, single points of contact and CSIRTs of a Member State to cooperate with each other, and with national data protection, law enforcement and financial authorities as relevant.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Duty on national authorities to coordinate among themselves. No entity conduct is prescribed.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires each Member State to adopt a national cybersecurity strategy setting objectives, governance, resources, policies and measures, and to review it at least every five years.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Duty on Member States to set national policy. No conduct is required of a regulated entity.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires each Member State to designate competent authorities responsible for cybersecurity and for supervisory tasks, and a single point of contact exercising a liaison function across Member States.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Duty on Member States to build the national regulatory apparatus. The entity's dealings with those bodies arise under the obligation articles.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires Member States to designate authorities responsible for managing large-scale cybersecurity incidents and crises, and to adopt a national response plan covering objectives, capabilities, roles and procedures.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Duty on Member States to establish national crisis machinery. The entity's own crisis capability is required by Article 21(2)(c).

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Establishes the Cooperation Group of Member State, Commission and ENISA representatives, and sets its tasks including strategic guidance, exchange of practice, and the coordinated supply chain risk assessments under Article 22.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Establishes a Union body and its work programme. Entities are affected only through outputs, which reach them via Article 21(3).

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Establishes the network of national CSIRTs to support coordinated operational cooperation, and sets its tasks including exchange of incident information and coordinated response support.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Establishes a Union operational network of authorities. It imposes nothing on a regulated entity.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Establishes EU-CyCLONe to support coordinated management of large-scale cybersecurity incidents and crises at operational level, and defines its composition and tasks.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Establishes a Union crisis liaison network of Member State authorities. No entity duty arises.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Allows the Union to conclude international agreements with third countries or international organisations enabling their participation in particular activities of the Cooperation Group, the CSIRTs network and EU-CyCLONe.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Union external competence provision. It binds the Union and Member States, not entities.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires ENISA to adopt a biennial report on the state of cybersecurity in the Union, covering risk assessment, capability levels, cyber hygiene awareness and a cybersecurity index.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Reporting duty on ENISA. It produces intelligence for policy makers rather than an entity obligation.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Establishes peer reviews between Member States of the effectiveness of their cybersecurity policies, with methodology set by the Cooperation Group and reports submitted to it.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Review mechanism operating between Member States. Entities are not subjects of a peer review.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Above the enumerated list in Article 21(2) sits a duty to size the whole programme correctly. Measures must be technical, operational and organisational together, must protect both the network and information systems and the physical environment those systems sit in, and must aim at preventing or minimising incident impact on the recipients of the entity's services and on other services downstream. Proportionality is defined rather than left open: the entity weighs the state of the art, relevant European and international standards where they apply, and the cost of implementation against its own degree of exposure to risk, its size, and the likelihood and severity of incidents including their societal and economic impact. The auditable artefact is therefore the reasoning, not just the control set. An entity that deployed a generic baseline can satisfy Article 21(2) point by point and sti

• A written proportionality rationale citing exposure, size, and incident likelihood and severity
• Scope documentation covering the physical environment of the systems, not the logical estate alone
• The standards and technical specifications relied on, and why they fit this entity
• Analysis of impact on recipients of the service and on dependent services, feeding the measure selection
• Review records showing the calibration is revisited as the entity or its risk changes

• A vendor baseline adopted wholesale with no entity-specific proportionality reasoning
• Physical environment left out of scope because the programme was framed as IT security
• Cost of implementation used to justify gaps without any exposure assessment on the other side
• Downstream impact on service recipients never assessed, so severity is judged internally 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.

• The documented risk analysis method, including risk criteria and acceptance thresholds
• The current risk assessment output covering the in-scope network and information systems
• The approved information system security policy set, with owners and review dates
• Traceability from assessed risks to the policy provisions and treatments that answer them
• Records of reassessment following material change or incident

• Risk register maintained as a list of findings with no method or acceptance criteria behind it
• Policies inherited from a template and never reconciled to the entity's own assessed risks
• Risk analysis performed once at certification and left static
• Exceptions granted informally, so the policy no longer describes what is actually in place

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.

• The incident handling procedure with severity levels, roles and escalation paths
• Incident records for a representative period showing detection, containment and recovery times
• Evidence of out-of-hours coverage and of how escalation reaches decision makers
• Post-incident review outputs and the actions they generated, with closure evidence
• The mapping from internal severity levels to the Article 23(3) significance threshold

• A response plan that has never been exercised against a realistic scenario
• Severity classification that has no defined bridge to the reporting threshold
• Lessons learned recorded but never turned into tracked remediation
• Detection coverage assumed rather than tested, so incidents are found by third parties

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.

• Business impact analysis deriving recovery time and recovery point objectives from service tolerance
• Backup configuration showing isolation or immutability against destructive attack
• Restore test results, dated, covering the systems that carry the essential service
• The crisis management plan naming decision authority, activation criteria and communications routes
• Exercise reports for both technical recovery and crisis decision making, with follow-up actions

• Backups verified as completed but never restored end to end
• Backup repositories reachable with the same credentials as production, so ransomware takes both
• Recovery objectives asserted without a business impact analysis behind them
• Crisis plans that assume the corporate email and telephony they depend on are available

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.

• Inventory of direct suppliers and service providers, flagged for access to in-scope systems
• Risk assessment per supplier proportionate to the access and criticality involved
• Contractual security clauses, including incident notification obligations and audit or assurance rights
• Ongoing monitoring evidence rather than onboarding-only assessment
• Exit and data return provisions, and evidence they have been exercised or tested

• Inventory built from the procurement system, so shadow and free-tier services are missing
• Assessment performed at onboarding and never repeated across a multi-year contract
• Legacy contracts left unamended because reopening them is commercially awkward
• Privileged remote access held by service providers with no session control or review

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.

• Security requirements applied in procurement and in the development lifecycle, with gate evidence
• Secure development practices in use, such as design review, code analysis and dependency scanning, with output
• Change and maintenance control records for in-scope systems
• A published contact route for vulnerability reports, and the triage procedure behind it
• Remediation timescales by severity, and measured performance against them including overdue items

• Security requirements defined for new build only, leaving acquired and inherited systems untouched
• No externally visible way for a finder to report a vulnerability
• Patch SLAs published but not measured, so overdue criticals are invisible
• Third-party and open source dependencies unscanned, so the vulnerability is inherited unseen

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.

• The documented effectiveness assessment approach, its criteria and its schedule
• Assessment and test results for the current period, covering the Article 21(2) categories
• Evidence of independence between the assessor and the control operator
• The finding register, with owners, due dates and closure evidence
• Reporting of effectiveness results into the management body under Article 20(1)

• Effectiveness inferred from a maturity self-assessment rather than tested
• Assessment performed by the same team that runs the control
• Findings raised but not tracked to closure, so the same gap recurs each cycle
• Coverage that repeats the easy controls annually and never reaches the rest

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.

• Patch and update currency reporting across the in-scope estate, including exceptions
• Secure configuration baselines and compliance measurement against them
• The privileged account inventory with justification and periodic review
• Network segmentation evidence for the systems carrying the essential service
• Role-based training content and completion rates, with refresh cadence

• Hygiene asserted for servers while endpoints, network devices and operational technology are unmeasured
• Local administrator rights left broadly assigned because removal was disruptive
• One annual awareness module treated as satisfying training for every role
• Configuration baselines defined but drift never measured

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.

• The cryptographic policy, naming approved algorithms, key lengths and permitted use
• The reasoning for where encryption is and is not applied, at rest and in transit
• Key and certificate lifecycle procedures covering generation, storage, rotation and revocation
• The key and certificate inventory with owners and expiry tracking
• Access control evidence over key material, including separation from the data it protects

• Encryption deployed while key custody and rotation are undocumented
• Certificate expiry managed reactively, so outages are the discovery mechanism
• Legacy algorithms still permitted because no deprecation timetable was ever set
• No decision record for the systems left unencrypted, so the where appropriate test cannot be shown

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.

• Screening policy and records proportionate to role sensitivity
• Joiner, mover and leaver procedure with timed evidence of access removal
• Access control policy plus periodic access review results, including privileged accounts
• Asset inventory with ownership and classification, reconciled against a discovery source
• Secure disposal and media sanitisation records

• Leaver process that covers directory accounts but not federated or cloud services
• Internal movers accumulating rights because only leavers trigger review
• Asset inventory maintained manually and drifting away from what is actually connected
• Access reviews signed off in bulk by managers with no basis for the approval

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.

• Coverage report for multi-factor or continuous authentication across remote, privileged and essential-service access
• The reasoning and compensating controls for any access path left without it
• Configuration evidence for secured voice, video and text communications within the entity
• The out-of-band emergency communications capability, its contact data and how the data is kept current
• Exercise evidence showing the emergency channel worked when the primary was assumed unavailable

• Multi-factor authentication on the corporate portal but not on administrative or machine access paths
• Exemptions granted to executives or to legacy protocols and never revisited
• Emergency communications limited to a contact list stored inside the systems that would be down
• No test of the out-of-band channel, so it is first used during a real crisis

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.

• Per-supplier assessment records that address that supplier's own vulnerabilities and secure development practice
• A watch process for Union coordinated supply chain risk assessments and the outputs it has captured
• Decision records showing how each relevant coordinated assessment was reflected in supplier measures
• Evidence that reasoned no-change decisions were recorded rather than assumed
• Reassessment of affected suppliers after a coordinated assessment is published

• Supplier assessment reduced to a questionnaire score with no view of that supplier's actual weaknesses
• No monitoring of Union coordinated assessments, so the input never arrives
• Coordinated assessment findings noted centrally but never pushed into contract or architecture decisions
• Secure development practice of suppliers never asked about, only their certifications

When an entity finds that it does not comply with the measures required by Article 21(2), it must take all necessary, appropriate and proportionate corrective measures without undue delay. The duty is self-triggering, which is what makes it demanding: it attaches on the entity's own discovery, not on a regulator's finding, so the internal assurance work required by Article 21(2)(f) feeds straight into it. What an auditor should be able to see is the path from a known gap to corrective action within a defensible time, with proportionality applied to the urgency rather than used as a reason to defer. A finding register carrying long-overdue items with no interim mitigation is the direct evidence of failure against this paragraph.

• The register of known non-compliances against the Article 21(2) categories, with discovery dates
• Corrective action plans with owners, target dates and the proportionality reasoning applied
• Closure evidence, and interim mitigation recorded where full correction takes time
• Escalation route when a corrective action slips, including reporting to the management body
• Elapsed-time measurement from discovery to correction across the period

• Gaps accepted as risk indefinitely instead of corrected, with no end date
• Corrective action started only after an external audit repeats a known internal finding
• No interim mitigation while a long remediation runs
• Discovery date not recorded, so without undue delay cannot be evidenced either way

Approval of the measures taken under Article 21 sits with the management body itself and cannot be delegated away to the security function. The body has to take the decision, then keep oversight of how the measures are actually implemented, and its members can be held liable for the entity's infringements of Article 21. What this asks for in practice is a decision record: the body saw the risk-management measures, understood what they cover and what they leave uncovered, approved them, and receives reporting good enough to tell whether implementation is real. A standing agenda item with substantive papers behind it satisfies this; a single sign-off page at the end of a project does not, because oversight is a continuing duty. Public bodies keep this obligation but the liability rules that attach to their officials remain those of national law.

• Minutes recording the management body's approval of the Article 21 measures, with the paper that was put to it
• The periodic implementation reporting the body receives, showing status against what was approved
• A written statement of which individual or committee holds the accountability, and how it reaches the board
• Evidence that material changes to the measures went back to the body for re-approval
• Records showing the body acted on adverse reporting rather than merely noting it

• Approval delegated to a security steering group that is not the management body
• One approval at programme start with no subsequent oversight reporting
• Board packs carrying maturity scores with no line of sight to the Article 21(2) categories
• No record of what the body was told, so oversight cannot be evidenced after an incident

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 expec

• The training curriculum put to the management body, showing it addresses risk identification and assessment of risk-management practices
• Attendance records per member, with dates, including members appointed since the last session
• The regular employee training schedule and its completion rates
• Evidence of refresh cadence rather than a single induction event
• Any assessment or exercise output showing the body can apply what it was taught

• Board members given the same awareness module as all staff
• New directors never brought up to the level of the ones trained at launch
• Training delivered once and treated as permanently satisfied
• Completion tracked without any check that the content matches the Article 20(2) purpose

The core reporting duty attaches to any incident with a significant impact on the provision of the entity's services. Article 23(3) fixes the threshold: an incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Capable of causing matters, because it brings in near-miss and contained events that could have gone further. Notification goes to the CSIRT or, where the Member State so provides, the competent authority, without undue delay, and must carry whatever lets the recipient determine cross-border impact. Where appropriate the entity must also tell the recipients of its services about significant incidents likely to affect service delivery. The Directive states t

• The documented significance test, expressed against the Article 23(3) limbs including capable of causing
• The determination record for each candidate incident, including reasoned decisions not to report
• Notifications as submitted, with timestamps, and the identity of the receiving CSIRT or authority
• Cross-border impact information captured and included in the notification
• Recipient notification records where service delivery was likely to be adversely affected

• Threshold applied only to realised impact, so contained incidents capable of severe disruption go unreported
• Reporting decision left to the security team with no legal or executive concurrence and no record
• Cross-border impact not assessed because the entity thinks of itself as national
• Service recipients never told, on the assumption that the authority notification discharges everything

This duty is triggered by a threat rather than an incident. Where a significant cyber threat could affect the recipients of the entity's services, the entity must without undue delay communicate to those potentially affected recipients any measures or remedies they are able to take in response, and where appropriate inform them of the threat itself. The obligation is practical rather than declaratory: the communication has to tell the recipient what to do, which means the entity needs the ability to identify who is affected, reach them quickly, and say something actionable. Building that capability after the threat emerges is the failure mode, because contact data and approval routes take longer to assemble than the threat allows.

• The procedure for deciding when a cyber threat is significant for service recipients
• Contact data for recipients and evidence it is maintained rather than assembled on demand
• Pre-approved communication templates carrying actionable remedies
• Records of threat communications issued, with timing and audience
• The approval path showing who authorises a recipient-facing threat communication

• Communications describing the threat without telling the recipient what action to take
• No maintained recipient contact route outside the account management relationship
• Legal review inserted with no time limit, so undue delay is introduced by the approval process
• Threat monitoring that never asks the question of downstream recipient exposure

The first stage of the layered reporting regime falls due without undue delay and in any event within 24 hours of becoming aware of the significant incident. The early warning is deliberately light: where applicable it indicates whether the incident is suspected of being caused by unlawful or malicious acts, and whether it could have cross-border impact. It is not a full assessment and waiting for one is the classic way to miss the deadline. Two operational points decide whether an entity can meet this. First, becoming aware has to be defined and evidenced, because the clock starts there and an entity that cannot say when it knew cannot show it reported in time. Second, submission has to be possible at any hour, since a Friday night detection has the same 24 hours as a Tuesday morning one. The CSIRT or authority is expected to respond within 24 hours where possible, so the channel is two

• The definition of becoming aware and the evidence trail that fixes that moment per incident
• Submitted early warnings with timestamps, measured against the 24-hour limit
• Out-of-hours submission capability, including named authorised submitters and their credentials
• The judgement recorded on suspected unlawful or malicious cause and on cross-border impact
• Any feedback received from the CSIRT or authority and how it was actioned

• Awareness treated as the moment of executive briefing rather than of qualified detection
• Early warning held back until the facts are clear, so the deadline passes
• Only one person able to file, with no delegate for leave or out of hours
• Portal credentials untested until the first real incident

Within 72 hours of becoming aware, the entity updates the early warning and provides an initial assessment of the significant incident covering its severity and impact, together with indicators of compromise where those are available. The 72 hours runs from awareness, not from the early warning, so the two clocks start together. Trust service providers are held to a shorter deadline: for significant incidents affecting the provision of their trust services they must notify within 24 hours. The practical demand here is investigative rather than administrative, since the entity needs enough forensic capability within three days to characterise severity and impact honestly and to extract indicators worth sharing. Producing indicators requires that the telemetry existed before the incident.

• Submitted notifications with timestamps measured from the awareness moment
• The initial severity and impact assessment as submitted, and the basis for it
• Indicators of compromise shared, and the telemetry and tooling they were derived from
• Where the entity is a trust service provider, evidence the shorter 24-hour deadline is built into the procedure
• Version history showing how the notification updated the early warning

• 72 hours counted from the early warning rather than from awareness
• Impact stated qualitatively with no attempt at scale, so severity cannot be judged
• No indicators available because logging retention was shorter than the dwell time
• Trust service provider status not reflected in the procedure, leaving the 24-hour case unhandled

Between the 72-hour notification and the final report, the CSIRT or competent authority may request an intermediate report on relevant status updates, and the entity has to be able to produce one. There is no fixed deadline attached, which makes the obligation about readiness rather than timing: the entity needs a maintained incident record from which a status update can be drawn on short notice, and a named point of contact that the authority can actually reach while the incident is running. Entities that manage incidents in chat threads and calls, with the written record assembled afterwards, are the ones that struggle here, because there is nothing to report from until the incident is over.

• The contemporaneous incident record maintained during response, timestamped and attributable
• The named regulatory point of contact and their reachability during an incident
• Any intermediate reports requested and submitted, with the request that prompted them
• The procedure for producing a status update without disrupting the response
• Evidence the record is kept during rather than reconstructed after the incident

• Incident timeline reconstructed after closure, so no status update can be produced mid-incident
• Response coordinated in ephemeral channels with no retained record
• No identified contact for the authority once the initial submitter is unavailable
• Status reporting that repeats the notification rather than describing what has changed

One month after the 72-hour notification the entity owes a final report containing a detailed description of the incident including its severity and impact, the type of threat or root cause likely to have triggered it, the mitigation measures applied and ongoing, and where applicable the cross-border impact. If the incident is still ongoing when that month expires, the entity provides a progress report at that point and then a final report within one month of finishing its handling of the incident. Root cause is the demanding element: a report that names the immediate technical trigger without reaching the reason the condition existed does not meet the standard, and it is also the element that determines whether the entity learns anything. The mitigation section must distinguish what is already done from what is still in progress.

• Final reports as submitted, with the date measured one month from the notification
• Root cause analysis output, reaching the underlying condition rather than the immediate trigger
• The mitigation record separating completed measures from ongoing ones, with owners and dates
• Cross-border impact assessment where applicable
• Progress reports issued where handling ran past the month, and the later final report

• Root cause given as the exploited vulnerability with no account of why it was exposed
• Final report deadline missed because it is tracked from incident closure rather than from notification
• Ongoing mitigations described without owners or dates, so completion cannot be checked
• No progress report filed for a long-running incident, leaving a silent gap

Allows the Cooperation Group, with the Commission and ENISA, to carry out coordinated security risk assessments of specific critical ICT services, systems or products supply chains, and requires the Commission to identify which are to be assessed.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Assessment power held by Union bodies. The entity-facing consequence, taking the results into account, is modelled at Article 21(3).

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

A Member State may require essential and important entities to use particular ICT products, ICT services and ICT processes that are certified under a European cybersecurity certification scheme adopted under Article 49 of Regulation (EU) 2019/881, as a way of demonstrating compliance with particular Article 21 requirements. That requirement can arrive either through national transposition or through a Commission delegated act specifying which categories of entity must use certified products or hold a certificate. Member States must also encourage the use of qualified trust services. What binds the entity is therefore conditional and moving: it has to know whether any such requirement applies to it in each Member State whose jurisdiction it falls under, and to hold the conformity evidence where one does. Delegated acts carry an implementation period, so the practical duty is to watch for

• A determination of whether any certification requirement applies, per Member State of jurisdiction
• Certificates held for ICT products, services or processes where certification is required
• The watch process for delegated acts and national requirements, with dated review
• Procurement requirements that carry certification obligations through to suppliers
• Evidence of qualified trust service use where the entity relies on trust services

• Assuming no requirement applies without checking each national transposition
• Certificates held by the supplier but never obtained or verified by the entity
• No monitoring of delegated acts, so the implementation period is consumed before anyone notices
• Certification scope narrower than the deployment it is being used to justify

Requires Member States to encourage, without favouring any particular technology, the use of European and international standards and technical specifications relevant to the security of network and information systems, and requires ENISA to advise on the technical areas concerned.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Encouragement duty on Member States and an advisory duty on ENISA. It creates no obligation an entity can breach; the entity-facing relevance of standards is inside the proportionality test at Article 21(1).

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires the Commission to review the functioning of the Directive periodically and report to the Parliament and Council, with the first review by 17 October 2027 assessing the relevance of the sectors, subsectors, size and entity types covered.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Review duty on the Commission. It may change scope in future but requires nothing now.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires Member States to adopt and publish by 17 October 2024 the measures necessary to comply with the Directive, and to apply them from 18 October 2024, communicating the text to the Commission.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Transposition duty on Member States. Entities comply with the transposing national law rather than with this Article.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Amends the eIDAS Regulation, replacing its security and notification provisions for trust service providers so that those matters are governed by this Directive.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Amending provision operating on another instrument. It relocates duties rather than creating one here.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Amends the European Electronic Communications Code, deleting its security and incident notification articles so that providers of public electronic communications networks and services fall under this Directive instead.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Amending provision operating on another instrument. It relocates duties rather than creating one here.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Repeals Directive (EU) 2016/1148, the original NIS Directive, with effect from 18 October 2024, and provides that references to it are to be read as references to this Directive.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Repeal and correlation provision. It governs the transition between instruments and binds no entity.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Provides that the Directive enters into force on the twentieth day following its publication in the Official Journal of the European Union.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Commencement provision. It fixes a date and imposes no conduct.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

States that the Directive is addressed to the Member States.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Addressee provision. It confirms that the instrument binds Member States, whose transposing law then binds entities.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Jurisdiction normally follows establishment, but several categories of provider are treated differently and the entity has to work out which rule applies to it. Providers of public electronic communications networks or publicly available electronic communications services fall under each Member State in which they provide services. DNS service providers, TLD name registries, domain name registration service providers, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, and providers of online marketplaces, online search engines and social networking platforms fall under the Member State of their main establishment, defined as where decisions on cybersecurity risk-management measures are predominantly taken, failing which where cybersecurity operations are carried out, failing which where the largest Union workforce

• The written jurisdiction determination, naming the rule applied and the Member State it produces
• Evidence supporting the main establishment test, such as where risk-management decisions are actually taken
• The representative designation instrument where the entity is not established in the Union
• Notification of the representative to the relevant authorities, and the representative's contact details
• Review evidence following reorganisation, since main establishment moves with decision making

• Jurisdiction assumed to follow the group headquarters rather than the Article 26 test
• Main establishment recorded as the legal seat when cybersecurity decisions are taken elsewhere
• Non-Union provider serving Union customers with no designated representative
• Determination made once and never revisited after the operating model changed

Requires ENISA to create and maintain the registry of DNS, cloud, data centre, content delivery, managed service, managed security service, online marketplace, online search engine and social networking providers, built from information forwarded by the single points of contact. The entity-facing submission and change duties are carried separately at Article 27(2) and 27(3).

• No artefact of its own. The entity-facing paragraph inside this article is modelled as a separate control and carries the evidence.
• Reason recorded on the node: Registry-keeping duty on ENISA and the single points of contact. The entity-facing paragraphs are modelled as the separate obligation, so counting this node as well would double count it.

• Counting both the article and its entity-facing paragraph, which double counts one obligation.

A defined set of provider types owes a second, more specific registration on top of the Article 3(4) duty: DNS service providers, TLD name registries, domain name registration service providers, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, and providers of online marketplaces, online search engines and social networking platforms. They had to submit to the competent authorities by 17 January 2025 the entity name, the relevant Annex I or II sector, subsector and entity type where applicable, the address of the main establishment and other Union legal establishments or of the designated representative, up to date contact details including email addresses and telephone numbers, the Member States where services are provided, and the entity's IP ranges. Changes must be notified without delay and in any event withi

• The Article 27 submission as filed, covering all six required data items
• The determination that the entity falls within one of the Article 27(1) provider types
• Address records for the main establishment and other Union establishments, or the representative
• The IP range declaration and how it is reconciled against actual announcements
• The change log evidencing notifications inside the three-month limit

• Filing the Article 3(4) registration and assuming it discharges Article 27 as well
• Provider type self-assessed narrowly, so a managed service line is never registered
• IP ranges submitted once from a network inventory that has since changed
• Three-month change window confused with the two-week window under Article 3(4)

TLD name registries and entities providing domain name registration services carry a dedicated set of duties aimed at DNS security, stability and resilience. They must collect and maintain accurate and complete domain name registration data with due diligence and in line with Union data protection law, holding at least the domain name, the registration date, the registrant's name, contact email address and telephone number, and the contact email address and telephone number of the point of contact administering the domain where those differ. They must have policies and procedures, including verification procedures, that keep the data accurate and complete, and those policies must be published. Registration data that is not personal data must be made publicly available without undue delay after registration. Access to specific registration data must be given on lawful and duly substantiat

• The registration database schema showing all data items required by Article 28(2) are held
• Published policies and procedures for verifying accuracy and completeness of registration data
• Verification results, including how inaccurate or incomplete records are detected and corrected
• The published disclosure policy, and the request log showing responses inside 72 hours
• Evidence of the split between published non-personal data and data released only on lawful request
• Cooperation arrangements with registries or registrars that avoid duplicate collection

• Registration data accepted as submitted with no verification procedure behind it
• Verification and disclosure policies operated internally but never published
• Access request handling with no clock, so the 72-hour limit is unmeasured
• Blanket refusal or blanket publication instead of the personal and non-personal split the Article requires

Participation in a cybersecurity information-sharing arrangement is voluntary, but telling the regulator about it is not. An entity that enters into such an arrangement must notify the competent authority on entry, and must notify it again on withdrawal once the withdrawal takes effect. The obligation is small and easy to miss precisely because the arrangement itself is optional, and it usually sits with the threat intelligence team rather than with whoever handles regulatory correspondence. Sector information sharing and analysis centres, trusted communities and bilateral exchanges with suppliers can all fall within scope, so the practical requirement is a maintained inventory of arrangements with a notification state against each.

• An inventory of cybersecurity information-sharing arrangements the entity participates in
• Notifications sent to the competent authority on entry, with dates
• Notifications sent on withdrawal, timed to when the withdrawal took effect
• Named ownership for keeping the inventory and the notification state current
• The assessment of which exchanges fall within the Article 29(2) definition

• Joining a sector sharing community with no notification to the authority
• Withdrawal never notified, so the authority's record stays wrong indefinitely
• Inventory held informally by the threat intelligence team and unknown to compliance
• Bilateral supplier exchanges never assessed against the definition

Allows entities inside and outside the scope of the Directive to notify incidents, cyber threats and near misses to CSIRTs or competent authorities voluntarily, and confirms that doing so imposes no additional obligations on the notifier.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Enabling provision. It creates a route an entity may use and states expressly that using it adds no obligations, so there is nothing to comply with.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires Member States to ensure their competent authorities supervise effectively, allows risk-based prioritisation of supervisory tasks, and governs how authorities handle information suggesting a personal data breach or an infringement of other Union law.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Duty on Member States and their authorities to supervise. The entity-facing cooperation duty is modelled at Articles 32 and 33.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Supervision is a duty on the competent authority, but it lands on the entity as a set of things it must be able to submit to and produce. Essential entities are subject to both ex ante and ex post supervision, important entities to ex post supervision triggered by evidence of an infringement. In either case the measures include on-site inspections and off-site supervision, targeted security audits based on risk assessment, ad hoc audits after a significant incident or where non-compliance is indicated, security scans, requests for information needed to assess the risk-management measures, requests for access to data, documents and information, and requests for evidence of implementation of the entity's cybersecurity policies including audit results and their underlying evidence. Audit results must be made available to the authority, and the cost of a targeted audit performed by an indepe

• A maintained evidence library covering the Article 21(2) categories, retrievable on request
• Records of any inspection, audit, scan or information request received and how it was answered, with timing
• The named point of contact for the competent authority and the internal escalation path
• Results of security audits made available to the authority, with the underlying evidence retained
• Tracking of any binding instruction, order or recommendation issued, through to implementation
• Budget provision for authority-mandated audits carried out by an independent body

• Evidence assembled per audit and then discarded, so the next request starts again
• Summary reports retained while the underlying evidence they rest on is not
• No single point of contact, so a request circulates until the deadline is at risk
• Audit recommendations closed on paper without evidence the change was implemented

Sets the ex post supervisory and enforcement regime for important entities, triggered where an authority has evidence, indication or information of an infringement, with a measure and power set closely mirroring Article 32 but without ex ante supervision and without the suspension powers reserved for essential entities.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Powers conferred on competent authorities. The entity-facing duty to cooperate with these measures is carried once at Article 32, which covers both regimes, so counting this node as well would double count it.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires Member States to ensure administrative fines are effective, proportionate and dissuasive, sets the ceilings of at least EUR 10 000 000 or 2 percent of total worldwide annual turnover for essential entities and at least EUR 7 000 000 or 1,4 percent for important entities, and lists the factors that fix the level of a fine.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Penalty provision addressed to Member States. A fine is the consequence of breaching Articles 21, 23 or 26 rather than a requirement an entity implements.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires competent authorities to inform the data protection supervisory authority where an infringement of this Directive entails a personal data breach, and prevents a fine under this Directive where the supervisory authority fines for the same conduct under the GDPR.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Coordination rule between authorities, including a non bis in idem protection. It governs regulator conduct, not entity conduct.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Requires Member States to lay down the rules on penalties applicable to infringements of the national provisions transposing the Directive and to take all measures necessary to ensure they are implemented.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Transposition duty on Member States to create a penalty regime. It is not itself a requirement on an entity.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Governs cooperation between competent authorities of different Member States where an entity provides services in more than one, including joint supervisory actions and requests for supervisory or enforcement measures.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Cooperation duty between national authorities. It changes who acts, not what an entity must do.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Sets the conditions under which the Commission may adopt delegated acts under the Directive, including duration, expert consultation, revocation and the objection period for the Parliament and Council.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Institutional provision governing Commission delegated powers. Entities have nothing to comply with.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.

Provides that the Commission is assisted by a committee within the meaning of Regulation (EU) No 182/2011 and that the examination procedure applies to the implementing acts adopted under the Directive.

• No entity artefact. This article binds Member States, the Commission, ENISA, the Cooperation Group, the CSIRTs network or a competent authority.
• Reason recorded on the node: Comitology provision governing how implementing acts are adopted. It imposes nothing on an entity.

• Reading an institutional or penalty provision as a requirement an entity implements, which is how authority-facing text ends up described as compliance work.