Article 18: Report on the state of cybersecurity in the Union

Article 18 is not a control you “comply with” directly; it is ENISA’s obligation to publish a biennial EU-wide cybersecurity state report. Your job is to operationalize the downstream expectation: maintain exam-ready cybersecurity metrics, incident and third-party dependency evidence, and an obligation register so you can answer regulator questions that will be informed by that report. (Directive (EU) 2022/2555, Article 18)

Key takeaways:

• Treat Article 18 as a supervisory “signal”: regulators will benchmark your posture against EU-wide trends and gaps cited by ENISA. (Directive (EU) 2022/2555, Article 18)
• Build an evidence package around incidents, governance, and critical third parties so you can respond fast to information requests aligned to the Union report themes. (Directive (EU) 2022/2555, Article 18)
• Operationalize with three basics: an obligation register, codified incident reporting workflows, and third-party dependency integration into risk management. (Directive (EU) 2022/2555, Article 18)

Article 18: report on the state of cybersecurity in the union requirement sounds like a reporting duty for companies. It isn’t. The legal obligation sits with ENISA, working with the Commission and the Cooperation Group, to produce a biennial report and present it to the European Parliament. (Directive (EU) 2022/2555, Article 18)

For operators, Article 18 matters because it shapes what “good” and “insufficient” cybersecurity looks like at the Union level. When supervisors, auditors, or boards ask why you are prioritizing certain controls, why an incident response investment is urgent, or why a third party concentration risk needs remediation, the ENISA report becomes part of the ambient evidence base that informs those questions. (Directive (EU) 2022/2555, Article 18)

This page translates Article 18 into a practical readiness playbook: what scope to assume, what data and artifacts you should already have, and how to organize ownership so you can answer inquiries quickly and consistently across jurisdictions. It is written for a Compliance Officer, CCO, or GRC lead who needs requirement-level guidance they can put into a working plan immediately. (Directive (EU) 2022/2555, Article 18)

Regulatory text

What the law says (excerpt)
“ENISA shall adopt, in cooperation with the Commission and the Cooperation Group, a biennial report on the state of cybersecurity in the Union and shall submit and present that report to the European Parliament. The report shall, inter alia, be made available in machine-readable data and include the following:” (Directive (EU) 2022/2555, Article 18)

Operator interpretation of that excerpt

• ENISA publishes; you prepare. Article 18 assigns a publication duty to ENISA, not to your organization. Your operational obligation is indirect: expect supervisory attention and information requests that track the report’s themes, and ensure your security and compliance program can produce consistent evidence on demand. (Directive (EU) 2022/2555, Article 18)
• Machine-readable implies data discipline. Because the Union-level report must be machine-readable, the upstream ecosystem will reward structured data. You should assume regulators will increasingly prefer structured, comparable metrics over narrative-only descriptions. Plan to produce metrics in consistent formats across entities and countries. (Directive (EU) 2022/2555, Article 18)

Plain-English interpretation (what the requirement means in practice)

For a regulated entity, the “article 18: report on the state of cybersecurity in the union requirement” translates into a readiness standard: you need to be able to explain your cybersecurity state with defensible, consistent data; demonstrate that incident handling is operational, timed, and evidenced; and show that critical third-party dependencies are identified, risk-assessed, and governed. (Directive (EU) 2022/2555, Article 18)

Think of Article 18 as the mechanism that turns many isolated supervisory findings into a Union narrative. If ENISA highlights common weaknesses across sectors, expect those weaknesses to become exam focus areas, board agenda items, and budget justification topics.

Who it applies to (entity and operational context)

Direct legal addressee

• ENISA is the direct party required to produce and present the report. (Directive (EU) 2022/2555, Article 18)

Practical applicability for companies

You should operationalize Article 18 if you are:

• In scope of NIS 2 through national transposition (essential or important entities) and subject to supervisory review under the directive’s broader framework. (Directive (EU) 2022/2555)
• Operating in multiple EU jurisdictions where consistency of obligations, evidence, and metrics becomes a recurring supervisory question. (Directive (EU) 2022/2555)

Operational contexts where Article 18 readiness shows up

• Supervisory inquiries and thematic reviews that ask you to benchmark your program against current Union threat trends or sector weaknesses. (Directive (EU) 2022/2555, Article 18)
• Board and executive reporting where you need to tie your internal risk picture to external authoritative narratives without over-claiming. (Directive (EU) 2022/2555, Article 18)
• Third-party governance where “systemic” or “ecosystem” risk framing becomes relevant (for example, dependency concentration and cascading failures). (Directive (EU) 2022/2555, Article 18)

What you actually need to do (step-by-step)

Below is a pragmatic implementation sequence that turns Article 18 into audit-ready operational outputs.

Step 1: Create an “Article 18 readiness mapping” (one-page)

Owner: GRC lead (with CISO input)

Include:

• The Article 18 excerpt and what it implies for your organization: “be able to describe cybersecurity state with structured evidence.” (Directive (EU) 2022/2555, Article 18)
• A list of likely information domains you will be asked about: incidents, resilience posture, governance, and critical third parties. Keep it generic, and align it to what you already report internally. (Directive (EU) 2022/2555, Article 18)

Deliverable: a one-page mapping you can attach to your NIS 2 compliance plan.

Step 2: Maintain a NIS 2 obligation register (jurisdiction-aware)

Owner: Compliance / Legal ops

Minimum fields:

• Obligation statement (plain English)
• Jurisdictional applicability notes (by member state transposition status and your footprint)
• Control owner and RACI
• Evidence location
• Implementation milestone tracking

This prevents scope drift across countries and gives you a single “truth source” during exams. It also makes it easier to explain how you translated directive obligations into operational requirements. (Directive (EU) 2022/2555)

Practical note: Daydream is often used here as the system of record for obligation registers, control ownership, and evidence linking, because it reduces spreadsheet sprawl and makes exam responses repeatable.

Step 3: Codify incident triage, escalation, and reporting workflows (and test them)

Owner: Security operations + Compliance

What “codify” means operationally:

• Define severity levels and decision points.
• Define who declares an incident, who escalates, and who approves external notifications.
• Define evidence retention requirements per incident type (tickets, timeline, indicators, decisions). (Directive (EU) 2022/2555)

Artifact goal: an incident workflow that produces a consistent incident package without heroic manual coordination.

Step 4: Build a structured cybersecurity “state” scorecard (internally)

Owner: CISO + GRC

Keep it simple and defensible:

• A small set of metrics you can explain and reproduce.
• Clear definitions and calculation logic.
• Change log and data owners.

Do not chase vanity metrics. Choose measures you can stand behind during scrutiny: patch status logic, asset coverage, control exceptions, risk acceptance volume, and third-party assurance status are typical candidates. Article 18’s machine-readable framing is your cue to standardize definitions and data lineage. (Directive (EU) 2022/2555, Article 18)

Step 5: Integrate critical third-party dependencies into risk assessments and remediation tracking

Owner: Third-party risk (TPRM) + Procurement + Security

Minimum operational requirements:

• Identify “critical” third parties based on service criticality and access patterns.
• Ensure each critical third party has an owned risk assessment, remediation plan, and assurance tracking (contracts, security attestations, audit reports, or equivalent).
• Track concentration risk: where multiple critical services depend on the same third party or subprocessor. (Directive (EU) 2022/2555)

Evidence goal: you can answer “which third parties could materially affect service continuity or incident propagation, and what did you do about it?”

Step 6: Prepare an “exam response kit” aligned to Union-level narratives

Owner: Compliance

Create a standard package you can refresh:

• Current cybersecurity scorecard
• Incident register excerpt with supporting evidence links
• Critical third-party inventory and assurance status
• Open remediation items and risk acceptances, with approvals
• Board/executive reporting excerpts showing oversight

This is the operational outcome Article 18 drives: faster, consistent, evidence-based responses when regulators ask questions informed by ENISA’s Union report. (Directive (EU) 2022/2555, Article 18)

Required evidence and artifacts to retain

Use this as your retention checklist.

Artifact	What auditors look for	Where teams fail
NIS 2 obligation register	Clear ownership, applicability notes, evidence links	Register exists but is not maintained; owners are unclear
Incident workflow + runbooks	Timed escalation, decision records, repeatability	Policy-only documentation with no proof of execution
Incident case files	Timeline, impact analysis, actions taken, approvals	Missing decision logs and communications evidence
Cybersecurity state scorecard	Stable definitions, data owners, change control	Metrics change every quarter without explanation
Critical third-party inventory	Identification of critical services and dependencies	Inventory stops at procurement “vendor list” and misses subdependencies
Third-party risk assessments + remediation tracking	Evidence of review, follow-up, closure	Findings tracked but not driven to closure or risk acceptance

All of these artifacts tie back to the need to communicate “state of cybersecurity” in a way that holds up under scrutiny influenced by Union-level reporting. (Directive (EU) 2022/2555, Article 18)

Common exam/audit questions and hangups

Expect questions in these buckets:

1. “Show me how NIS 2 applies to your footprint.”
   Hangup: different business units interpret applicability differently. Your obligation register resolves this if it has jurisdiction notes and owners. (Directive (EU) 2022/2555)

2. “Prove incident management works in practice.”
   Hangup: teams show a policy, not execution evidence. Keep case files, decision logs, and post-incident actions tied to remediation tracking. (Directive (EU) 2022/2555)

3. “Which third parties are critical, and what assurance do you have?”
   Hangup: “critical” is undefined or informal. Define criteria, document it, and keep the list current. (Directive (EU) 2022/2555)

4. “Explain your cybersecurity posture with data.”
   Hangup: metrics are inconsistent across entities. Standardize definitions and keep data lineage notes. (Directive (EU) 2022/2555, Article 18)

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating Article 18 as “nothing for us.”
  Fix: treat it as a supervisory lens. Build an exam response kit and a defensible posture scorecard. (Directive (EU) 2022/2555, Article 18)

• Mistake: Obligation register without evidence links.
  Fix: every obligation row needs an evidence pointer (system, folder, ticketing queue, or GRC record) and an owner who can produce it quickly. (Directive (EU) 2022/2555)

• Mistake: Third-party program stops at onboarding.
  Fix: track remediation and assurance over time for critical third parties, not just a one-time due diligence package. (Directive (EU) 2022/2555)

• Mistake: Metrics that cannot be reproduced.
  Fix: document metric definitions, data sources, and change control. Machine-readable expectations reward discipline. (Directive (EU) 2022/2555, Article 18)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for Article 18, so this page does not list case examples.

Risk implication you should plan for: Article 18 increases the chance of thematic, cross-sector supervisory attention based on the EU-wide narrative. If your program cannot produce consistent evidence on incidents and third-party dependencies, you risk slower responses, credibility loss with supervisors, and expanded follow-up requests. (Directive (EU) 2022/2555, Article 18)

Practical 30/60/90-day execution plan

You asked for speed, but numeric timelines create a trap if you treat them as guarantees. Use this as phased execution guidance, and adjust to your footprint.

First 30 days (stabilize scope and ownership)

• Stand up the NIS 2 obligation register with owners and jurisdiction notes. (Directive (EU) 2022/2555)
• Draft the one-page Article 18 readiness mapping. (Directive (EU) 2022/2555, Article 18)
• Inventory your existing incident workflow documents and identify evidence gaps (missing decision logs, missing post-incident remediation tracking). (Directive (EU) 2022/2555)

By 60 days (build the exam kit)

• Implement the exam response kit structure (scorecard, incidents, third parties, remediation). (Directive (EU) 2022/2555, Article 18)
• Define “critical third party” criteria and produce the first critical dependency list. (Directive (EU) 2022/2555)
• Run a tabletop that forces evidence capture: who records decisions, where artifacts live, and who can retrieve them. (Directive (EU) 2022/2555)

By 90 days (operate and refine)

• Produce a repeatable cybersecurity state scorecard with definitions and data owners. (Directive (EU) 2022/2555, Article 18)
• Close the loop on third-party remediation: open items, owners, due dates, and risk acceptances with approvals. (Directive (EU) 2022/2555)
• Add continuous maintenance: monthly refresh of critical third-party list, incident metrics, and obligation register updates as national transpositions evolve. (Directive (EU) 2022/2555)

Frequently Asked Questions

Does Article 18 require my company to submit a report to ENISA?

Article 18 assigns the reporting obligation to ENISA, in cooperation with the Commission and the Cooperation Group. Your practical need is readiness to support supervisory questions influenced by that Union-level report. (Directive (EU) 2022/2555, Article 18)

What evidence should I prepare that maps cleanly to “state of cybersecurity”?

Prepare a defensible posture scorecard, incident case files with decision logs, and a critical third-party dependency inventory with assurance and remediation tracking. Keep evidence linkable and reproducible. (Directive (EU) 2022/2555, Article 18)

We operate in multiple EU countries. How do we avoid inconsistent NIS 2 implementation?

Maintain a single obligation register with jurisdictional applicability notes, named control owners, and evidence pointers. Use it as the source for audits, board reporting, and program management. (Directive (EU) 2022/2555)

What’s the fastest way to become “exam-ready” without rewriting all policies?

Build an exam response kit and backfill evidence for how processes actually run: incident tickets, timelines, approvals, and remediation items. Auditors usually accept concise procedures if execution evidence is strong. (Directive (EU) 2022/2555)

How should third-party risk tie into this requirement?

Article 18 is Union-level reporting, but supervisors will care about systemic drivers like supply chain risk. Identify critical third parties, document dependencies, and track remediation and assurance over time. (Directive (EU) 2022/2555, Article 18)

Where does Daydream fit without adding process overhead?

Use Daydream as the system of record for the NIS 2 obligation register, control ownership, and evidence links, so exam responses are repeatable and not dependent on individual memory or shared-drive archeology. (Directive (EU) 2022/2555)