Article 10: Computer security incident response teams (CSIRTs)

Article 10 requires each EU Member State to designate or establish one or more CSIRTs that cover NIS 2 sectors and handle incidents through a well-defined process aligned to Article 11(1). To operationalize this as an entity, you must map your reporting and operational touchpoints to the national CSIRT(s), harden incident intake/triage, and keep exam-ready evidence of how you engage CSIRTs during incidents. (Directive (EU) 2022/2555, Article 10)

Key takeaways:

• Article 10 is primarily a Member State obligation, but it creates concrete operational expectations for regulated entities around CSIRT engagement and incident handling. (Directive (EU) 2022/2555, Article 10)
• Your fastest path to readiness is a jurisdiction-by-jurisdiction CSIRT contact and notification playbook embedded into incident response and third-party escalation. (Directive (EU) 2022/2555, Article 10)
• Auditors will look for “process over policy”: real workflows, triggers, logs, and artifacts proving you can work with the right CSIRT under pressure. (Directive (EU) 2022/2555, Article 10)

The “article 10: computer security incident response teams (csirts) requirement” is written to Member States, not directly to companies. That distinction matters, but it does not reduce your operational burden. Article 10 establishes that each Member State must have one or more CSIRTs with defined coverage and a well-defined incident handling process, aligned with requirements in Article 11(1). (Directive (EU) 2022/2555, Article 10)

For essential and important entities operating in the EU, this shapes how supervision and incident coordination works in practice: the CSIRT is a key endpoint for incident handling coordination, guidance, and national-level situational awareness. Your incident response program must be built to identify which national CSIRT is in scope for a given incident and to execute the required engagement steps cleanly, including when the incident originates in a third party or cascades across countries. (Directive (EU) 2022/2555, Article 10)

This page focuses on fast operationalization: how to translate Article 10 into a jurisdictional CSIRT engagement model, embed it into incident response and third-party management, and produce the evidence examiners actually ask for.

Regulatory text

Regulatory excerpt (provided):
“Each Member State shall designate or establish one or more CSIRTs… The CSIRTs shall comply with the requirements set out in Article 11(1), shall cover at least the sectors, subsectors and types of entity referred to in Annexes I and II, and shall be responsible for incident handling in accordance with a well-defined process.” (Directive (EU) 2022/2555, Article 10)

Plain-English interpretation

• What Article 10 does: It guarantees that a national incident response capability (CSIRT) exists in each Member State, has defined coverage across NIS 2 sectors, and follows a structured incident-handling process. (Directive (EU) 2022/2555, Article 10)
• What it means for you: You need a repeatable, documented way to (a) identify the relevant CSIRT(s) for your EU footprint and (b) engage them through your incident handling lifecycle, with clear ownership, triggers, and records. You should treat CSIRT engagement as part of “exam-ready” incident response, not as an ad hoc legal task. (Directive (EU) 2022/2555, Article 10)

Who it applies to (entity and operational context)

Although Article 10 is addressed to Member States, it directly affects organizations that fall under NIS 2 scope because CSIRTs “cover at least” the sectors and entity types referenced in Annexes I and II. (Directive (EU) 2022/2555, Article 10)

You should operationalize CSIRT engagement if you are:

• An essential entity or important entity with operations, customers, infrastructure, or regulated services in an EU Member State. (Directive (EU) 2022/2555, Article 10)
• A multi-country operator where one incident may touch multiple national authorities, national CSIRTs, or cross-border response partners. (Directive (EU) 2022/2555, Article 10)
• Reliant on critical third parties (cloud, MSSP, telecom, managed OT, software supply chain) where you may need CSIRT coordination even when the incident starts outside your perimeter. (Directive (EU) 2022/2555, Article 10)

Operationally, this lands in:

• Incident response (IR) and SOC operations (intake, triage, containment, comms)
• Legal/compliance (notification governance, regulator comms control)
• Third-party risk management (escalation, evidence intake from providers)
• Business continuity and crisis management (executive decisioning and external comms)

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

The goal is simple: make CSIRT engagement deterministic. During an incident, nobody should debate who to call, what to send, and who approves it.

Step 1: Build a jurisdictional CSIRT engagement register

Create a living register that answers, per Member State where you operate:

• Which national CSIRT(s) you may need to interact with
• How to contact them (channels, escalation options)
• Which business lines/entities in your org map to that Member State
• Who inside your org owns the relationship (IR lead vs regulatory affairs vs compliance)
• How this ties to your incident handling process (your “well-defined process” alignment point) (Directive (EU) 2022/2555, Article 10)

Practical tip: Put this register under change control. A stale phone number is a real operational risk during a material event.

Step 2: Embed CSIRT routing into incident classification

Update your incident classification and triage logic so each incident is tagged with:

• Impacted Member State(s)
• Impacted NIS 2-covered services/operations
• Primary CSIRT routing and backup routing (if multiple CSIRTs apply) (Directive (EU) 2022/2555, Article 10)

This is usually one field in your incident record plus one decision table in your IR playbook.

Step 3: Define “well-defined process” touchpoints

Article 10 explicitly ties CSIRTs to incident handling “in accordance with a well-defined process.” For operators, that means your process must show where CSIRT interaction occurs, for example:

• Initial assessment and decision to engage national CSIRT(s)
• Information package preparation (facts known, scope, potential cross-border impact)
• Ongoing updates and coordination
• Post-incident closure inputs (lessons learned, mitigations) (Directive (EU) 2022/2555, Article 10)

Write these as workflow steps with owners. Avoid narrative-only policies.

Step 4: Align internal roles, approvals, and segregation of duties

Document a RACI that covers:

• Who can initiate CSIRT contact
• Who approves outbound technical details (SOC/IR lead)
• Who approves legal/regulatory positioning (Legal/Compliance)
• Who controls external messaging consistency (Comms/Crisis lead)

Auditors commonly flag “everyone can email the regulator” as a control gap because it creates inconsistent reporting and privilege risk.

Step 5: Make third-party incidents routable to CSIRTs

Add a third-party incident intake path that forces:

• Vendor/MSSP evidence capture (timeline, IOCs, affected services)
• Contractual escalation and required cooperation steps
• Mapping to impacted Member States and CSIRT routing (Directive (EU) 2022/2555, Article 10)

If you already maintain a third-party criticality tiering, use it to decide which third-party incidents must be evaluated for CSIRT coordination.

Step 6: Run a tabletop that tests CSIRT engagement

Your test should prove you can:

• Identify the correct Member State CSIRT contact quickly
• Produce a coherent incident summary from your ticketing/SIEM sources
• Log decisions, approvals, and outbound communications

Capture outputs as artifacts (see below). Tabletop evidence often becomes your strongest audit defense.

Step 7: Keep the “obligation register” audit-ready

NIS 2 obligations are implemented through national transposition and supervision. Keep a register that shows:

• Which jurisdictions you assessed
• Who owns each obligation internally
• Implementation milestones and status tracking

This prevents scope drift across countries and business units and supports consistent execution during supervision cycles. (Directive (EU) 2022/2555)

Where Daydream fits: teams use Daydream to keep a jurisdictional obligation register tied to control owners, and to package incident-response evidence (workflows, approvals, artifacts) into an exam-ready format without rebuilding the story every audit cycle.

Required evidence and artifacts to retain

Store artifacts in a way that supports retrieval by incident, by country, and by time period.

Minimum evidence set:

• CSIRT engagement register (jurisdictions, contacts, internal owners, last review date)
• Incident response playbooks that show CSIRT touchpoints in the handling process (Directive (EU) 2022/2555, Article 10)
• Decision matrix / routing logic for Member State impact to CSIRT engagement
• RACI and approval workflows for outbound engagement
• Incident records showing classification fields, routing decisions, timestamps, and who approved communications
• Outbound communications log (what was sent, to whom, when, by whom)
• Third-party incident escalation records and received evidence packages
• Tabletop reports and remediation tracking items tied to findings

Common exam/audit questions and hangups

Expect variations of:

• “Which CSIRT(s) cover your operations in each Member State where you provide covered services?” (Directive (EU) 2022/2555, Article 10)
• “Show the ‘well-defined process’ for incident handling, and where CSIRT engagement occurs.” (Directive (EU) 2022/2555, Article 10)
• “How do you avoid missed or inconsistent engagement when the incident starts at a third party?”
• “Who is authorized to communicate technical details externally, and how do you control approvals?”
• “Prove this works: provide an incident file or tabletop artifacts.”

Hangups that create findings:

• No evidence of operational testing
• Playbooks exist, but ticketing fields do not enforce routing decisions
• CSIRT contacts live in personal inboxes, not controlled documentation

Frequent implementation mistakes (and how to avoid them)

1. Treating Article 10 as “not applicable” because it’s a Member State duty.
   Avoidance: document your dependency: “We rely on national CSIRTs; our control is CSIRT engagement readiness mapped to jurisdictions.” (Directive (EU) 2022/2555, Article 10)

2. No single source of truth for cross-border routing.
   Avoidance: one register, change-controlled, with named owners.

3. CSIRT engagement lives only in the policy.
   Avoidance: add system-enforced fields in incident tooling (country impact, routing, approval).

4. Third-party incidents are handled in procurement silos.
   Avoidance: connect third-party incident intake to SOC/IR triage and jurisdiction mapping. (Directive (EU) 2022/2555, Article 10)

Enforcement context and risk implications

No public enforcement case references were provided in the available source catalog for this requirement, so this page does not cite enforcement outcomes.

Operational risk still rises in predictable ways:

• Missed coordination with the relevant national CSIRT can slow containment and complicate supervisory engagement.
• Inconsistent external communications increase legal exposure and damage credibility with regulators during follow-up.
• Third-party opacity (lack of timely facts from providers) causes delays that look like poor incident handling governance.

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Confirm NIS 2 in-scope business units and EU Member States where you operate. (Directive (EU) 2022/2555, Article 10)
• Stand up a CSIRT engagement register template; assign owners.
• Update IR intake forms to capture “impacted Member State(s)” and “potential CSIRT routing.”
• Draft a short CSIRT engagement SOP: who initiates, who approves, where logs live.

Next 60 days (Near-term)

• Complete the CSIRT engagement register for all relevant jurisdictions; put it under change control.
• Update IR playbooks to show CSIRT engagement steps explicitly aligned to your incident handling process. (Directive (EU) 2022/2555, Article 10)
• Implement an outbound comms approval workflow (ticketing integration or documented process with evidence trail).
• Add third-party incident intake requirements (what evidence you require, how fast, where it is stored).

Next 90 days (Stabilize and prove operation)

• Run at least one tabletop that includes (a) a cross-border scenario and (b) a third-party-triggered incident.
• Remediate tabletop findings and record closure evidence.
• Package an “audit binder” view: register + playbooks + RACI + tabletop + sample incident file.
• Operationalize ongoing reviews: periodic validation of CSIRT contacts and internal owners.

Frequently Asked Questions

Does Article 10 require my company to establish a CSIRT?

Article 10 requires each Member State to designate or establish one or more CSIRTs. Your obligation is to ensure your incident handling process can engage the appropriate CSIRT(s) for the Member States and sectors you affect. (Directive (EU) 2022/2555, Article 10)

We operate in multiple EU countries. Do we need multiple CSIRT playbooks?

Keep one global incident response framework, but add a jurisdictional routing layer: a CSIRT engagement register plus a decision table that maps impacted Member States to the right CSIRT contact path. (Directive (EU) 2022/2555, Article 10)

What evidence best proves “well-defined process” in an audit?

Auditors respond to workflow proof: incident tickets with jurisdiction tags, routing decisions, approval logs, and a tabletop report that demonstrates CSIRT engagement steps. Policies help, but execution records close the loop. (Directive (EU) 2022/2555, Article 10)

How do we handle CSIRT engagement when an incident starts at a cloud provider?

Require a third-party incident evidence pack (timeline, scope, affected services, IOCs if appropriate), then run your normal triage to map impacted Member States and initiate CSIRT routing based on your register. Document the dependency and your decision trail. (Directive (EU) 2022/2555, Article 10)

Who should own CSIRT communications: Legal, Compliance, or the SOC?

Split duties. The SOC/IR lead should own technical accuracy and incident handling steps, while Legal/Compliance controls notification governance and consistency of external statements. Put this in a RACI and enforce it through approvals. (Directive (EU) 2022/2555, Article 10)

We have an IR policy but no recent incidents. How do we prove readiness?

Run a tabletop with a realistic cross-border scenario and retain artifacts: participant list, injects, decisions, outputs, and a tracked remediation plan. That evidence often substitutes for real-incident files during exams. (Directive (EU) 2022/2555, Article 10)