Article 11: Requirements, technical capabilities and tasks of CSIRTs

To operationalize the article 11: requirements, technical capabilities and tasks of csirts requirement, you must confirm whether your organization is expected to operate a CSIRT (internally or via a designated function) and then document, test, and evidence the CSIRT’s ability to receive, triage, analyze, coordinate, and support incident handling across the organization and relevant stakeholders. Build this as an auditable capability, not a slide deck. (Directive (EU) 2022/2555, Article 11)

Key takeaways:

• Treat Article 11 as a capability requirement: defined services, defined intake routes, defined outputs, and proof they work. (Directive (EU) 2022/2555, Article 11)
• Your fastest path to exam-ready is an obligation register + CSIRT operating model + evidence library mapped to jurisdictions and business scope. (Directive (EU) 2022/2555, Article 11)
• If incident workflows exist but you cannot show logs, tickets, on-call records, and cross-team coordination artifacts, expect audit friction. (Directive (EU) 2022/2555, Article 11)

Article 11 in NIS 2 focuses on the requirements, technical capabilities, and tasks of CSIRTs. For a Compliance Officer, CCO, or GRC lead, the operational challenge is predictable: the “CSIRT” label often exists informally (SOC, IR team, IT ops), while regulators and auditors look for a coherent, documented, consistently executed capability with clear responsibilities and repeatable outputs. (Directive (EU) 2022/2555, Article 11)

Your job is to translate Article 11 into controls that stand up to supervisory scrutiny across jurisdictions where you operate. NIS 2 is implemented through national transposition, so the practical interpretation and evidence expectations can vary by Member State, even when the Directive is the same. That means your baseline should be strong enough to survive different supervisory styles: process proof, not intent statements. (Directive (EU) 2022/2555)

This page gives requirement-level implementation guidance you can put into motion immediately: who should own the CSIRT capability, what “good” looks like in day-to-day operations, which artifacts to retain, and what auditors typically challenge. Where the Directive text available here is limited, the guidance stays precise and avoids speculative legal detail. (Directive (EU) 2022/2555, Article 11)

Regulatory text

Regulatory excerpt (available in source pack): “1. The CSIRTs shall comply with the following requirements:” (Directive (EU) 2022/2555, Article 11)

Operator meaning: Article 11 is a directive-level mandate that CSIRTs must meet defined requirements. Your compliance deliverable is not “we have an incident response policy.” It is a demonstrable CSIRT capability with defined tasks, technical means to execute them, and proof that the capability operates in practice. (Directive (EU) 2022/2555, Article 11)

What you must be ready to show quickly:

• A clearly identified CSIRT function (internal team, designated unit, or formally contracted function) with responsibility boundaries. (Directive (EU) 2022/2555, Article 11)
• Repeatable workflows for intake, triage, analysis, coordination, escalation, and closure. (Directive (EU) 2022/2555, Article 11)
• Evidence that the workflows run under real conditions: tickets, timelines, notifications, handoffs, and post-incident outputs. (Directive (EU) 2022/2555, Article 11)

Plain-English interpretation (requirement-level)

Article 11 expects a CSIRT to be operationally capable. In practice, that means:

1. incidents can be reported to the CSIRT through known channels,
2. the CSIRT can assess and prioritize what comes in,
3. the CSIRT can coordinate technical response and communications,
4. the CSIRT can produce reliable outputs (status, advisories, lessons learned),
5. the organization can prove the above with records. (Directive (EU) 2022/2555, Article 11)

If your “CSIRT” is split across teams (SOC + IT + Security Engineering + Legal), Article 11 pushes you to formalize the seams: who owns triage, who owns containment decisions, who notifies whom, and what gets logged. (Directive (EU) 2022/2555, Article 11)

Who it applies to (entity and operational context)

Direct applicability: This article is written for CSIRTs. Whether you must operate a CSIRT as an organization depends on your NIS 2 role and how obligations land through national transposition. Treat this as applicable if any of the following are true in your operating model:

• You have a formally designated CSIRT or incident response team.
• Your regulator or national competent authority expects you to maintain CSIRT-like capabilities as part of NIS 2 compliance.
• You provide services where your incident handling must integrate with external stakeholders (sector peers, suppliers, customers, authorities). (Directive (EU) 2022/2555, Article 11)

Operational contexts where Article 11 work shows up fastest:

• 24/7 operations and on-call response.
• Multi-country incident coordination.
• Heavy reliance on third parties for hosting, identity, managed detection/response, OT support, or critical SaaS. (Directive (EU) 2022/2555, Article 11)

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

Use this as a build list. Keep each step tied to an artifact you can produce on demand.

Step 1: Decide the CSIRT operating model and document the boundary

• Name the CSIRT function owner (role, not person) and define scope: which business units, systems, and countries are in scope. (Directive (EU) 2022/2555, Article 11)
• If you outsource pieces (MDR, IR retainer), document which tasks remain internal and which are delegated, including escalation authority. (Directive (EU) 2022/2555, Article 11)

Deliverable: CSIRT Operating Model (1–3 pages) with RACI.

Step 2: Build a NIS 2 obligation register mapped to jurisdictions

• Create a register that tracks NIS 2 obligations, your applicability assumptions, control owners, and delivery milestones.
• Add “jurisdiction notes” so local teams understand what must be consistent globally vs. what differs locally. (Directive (EU) 2022/2555)

Deliverable: NIS 2 obligation register (owned by Compliance/GRC; reviewed with Security).

Step 3: Define CSIRT services and service levels in operational terms

Write what the CSIRT does in a way an auditor can test:

• Intake: channels, authentication, required fields, and logging.
• Triage: severity rubric, prioritization rules, and time-to-first-response targets (targets can be internal guidance; avoid claiming regulatory timelines you cannot cite). (Directive (EU) 2022/2555, Article 11)
• Analysis: required tooling and minimum investigation steps for common incident types.
• Coordination: handoffs to IT/OT, Legal, Privacy, Communications, and third parties.
• Closure: root cause summary, remediation tracking, and lessons learned. (Directive (EU) 2022/2555, Article 11)

Deliverable: CSIRT Service Catalogue + Severity Matrix.

Step 4: Codify incident triage, escalation, and reporting workflows

• Document the workflow from “signal received” to “closed incident,” including decision points and who can declare a major incident.
• Add triggers for evidence capture (forensic images, logs, chat transcripts, approvals) and retention expectations. (Directive (EU) 2022/2555, Article 11)

Deliverable: Incident Handling SOPs (runbooks) + Escalation Tree.

Step 5: Make the capability testable (tabletops and functional tests)

• Run scenario tests that force cross-functional decisions (e.g., ransomware, third-party outage, identity compromise).
• Produce artifacts from the exercise as if it were real: tickets, timeline, action items, communications drafts. (Directive (EU) 2022/2555, Article 11)

Deliverable: Exercise pack (scenario, attendance, outputs, after-action report, remediation plan).

Step 6: Integrate critical third-party dependencies into CSIRT operations

• Maintain a list of critical third parties, what they provide, and how to contact them during incidents.
• Pre-negotiate minimum incident cooperation terms where possible (notification paths, log access, coordination). (Directive (EU) 2022/2555, Article 11)

Deliverable: Third-party incident contact matrix + IR cooperation clauses (or contract addendum register).

Step 7: Build an “audit-ready evidence library”

Centralize evidence so you can respond fast:

• Sample incident records (sanitized), with full timeline and approvals.
• On-call schedules and handover notes.
• Tooling screenshots/config exports (case management, SIEM, alerting, paging).
• Metrics you actually track (ticket aging, reopen rates, high-severity postmortems), without inventing regulatory targets. (Directive (EU) 2022/2555, Article 11)

Deliverable: Evidence index with location pointers and owners.

Where Daydream fits naturally: Daydream can host the obligation register, map Article 11 to control owners, track milestones, and keep evidence pointers tied to each control so you stop hunting across shared drives during an exam window. (Directive (EU) 2022/2555, Article 11)

Required evidence and artifacts to retain (exam-ready list)

Maintain these in a controlled repository with change history:

• CSIRT charter / operating model and RACI. (Directive (EU) 2022/2555, Article 11)
• Incident handling SOPs and runbooks, versioned. (Directive (EU) 2022/2555, Article 11)
• Intake channel configuration evidence (ticketing queues, email aliases, hotline/on-call process, portal forms). (Directive (EU) 2022/2555, Article 11)
• Case management records: incident tickets, timelines, containment decisions, closure criteria. (Directive (EU) 2022/2555, Article 11)
• Exercise reports and remediation tracking. (Directive (EU) 2022/2555, Article 11)
• Third-party dependency list and incident contact matrix. (Directive (EU) 2022/2555, Article 11)
• Training/role onboarding records for CSIRT participants (Security, IT, Legal, Comms). (Directive (EU) 2022/2555, Article 11)

Common exam/audit questions and hangups

Expect these themes:

• “Show me your CSIRT.” Auditors ask who is on it, who leads it, and who has authority to escalate. Bring a roster by role and an on-call process. (Directive (EU) 2022/2555, Article 11)
• “Prove it works.” They request a recent incident record and follow the chain: alert → triage → decisions → communications → remediation. Missing timestamps and approvals are a common hangup. (Directive (EU) 2022/2555, Article 11)
• “How do third parties fit?” If a cloud provider or MSP is critical, show the coordination path and evidence you can execute it under pressure. (Directive (EU) 2022/2555, Article 11)
• “What changes by country?” If you operate in multiple Member States, be ready to explain how your baseline CSIRT process maps to local expectations under transposition. (Directive (EU) 2022/2555)

Frequent implementation mistakes (and how to avoid them)

1. Naming a CSIRT without operational authority. Fix: write escalation authority into the RACI and incident SOPs, including who can trigger executive/legal engagement. (Directive (EU) 2022/2555, Article 11)
2. Runbooks that are not wired to tools. Fix: link each runbook step to the system used (ticket queue, pager, SIEM query pack) and keep config exports as evidence. (Directive (EU) 2022/2555, Article 11)
3. Third-party IR is “assumed.” Fix: maintain a third-party contact matrix and store contract language or addenda that governs incident cooperation. (Directive (EU) 2022/2555, Article 11)
4. No evidence trail. Fix: enforce a minimum incident record standard (timestamps, owner, actions, approvals, closure rationale) in your case management tooling. (Directive (EU) 2022/2555, Article 11)

Enforcement context and risk implications

No public enforcement cases were provided in the source pack for this requirement, so this page does not summarize specific actions or outcomes.

Practically, the risk is supervisory: if a CSIRT capability exists only as policy, you can face findings tied to operational readiness, inability to coordinate across teams, and incomplete incident records. These failures compound other NIS 2 duties because incident reporting and response depend on CSIRT execution quality. (Directive (EU) 2022/2555, Article 11)

Practical 30/60/90-day execution plan

Use staged phases to avoid making unsupported timing promises while still moving fast.

Days 0–30: Establish accountability and the minimum viable CSIRT

• Confirm CSIRT scope, owner, and operating model; publish RACI. (Directive (EU) 2022/2555, Article 11)
• Stand up the NIS 2 obligation register with Article 11 mapped to owners and evidence locations. (Directive (EU) 2022/2555)
• Document intake channels and implement a minimum incident record standard in your ticketing/case tool. (Directive (EU) 2022/2555, Article 11)

Days 31–60: Make it repeatable and test it

• Finalize runbooks for your top incident types and integrate them into on-call operations. (Directive (EU) 2022/2555, Article 11)
• Build third-party incident contact matrix for critical dependencies and validate it with call-down tests. (Directive (EU) 2022/2555, Article 11)
• Run at least one cross-functional tabletop; produce an after-action report and remediation plan. (Directive (EU) 2022/2555, Article 11)

Days 61–90: Make it audit-ready

• Build the evidence library: sanitized case files, tool configuration exports, training records, exercise outputs. (Directive (EU) 2022/2555, Article 11)
• Close high-risk gaps found in the tabletop (missing logs, unclear escalation, weak third-party coordination). (Directive (EU) 2022/2555, Article 11)
• Conduct an internal “exam simulation” where a reviewer asks for proof and you respond from the evidence index only. (Directive (EU) 2022/2555, Article 11)

Frequently Asked Questions

Do we need to create a new CSIRT team to meet Article 11?

Not always. If you already have a SOC/IR function, formalize it as the CSIRT operating model with documented tasks, authority, and evidence that it runs. (Directive (EU) 2022/2555, Article 11)

Can an outsourced MDR provider be our CSIRT?

You can outsource components, but you still need clear accountability, escalation authority, and proof of coordination across internal stakeholders and third parties. Document what remains your responsibility. (Directive (EU) 2022/2555, Article 11)

What’s the minimum evidence an auditor will ask for?

Expect to produce the CSIRT charter/RACI, incident handling procedures, and at least one end-to-end incident record or exercise pack with timestamps and decision trail. (Directive (EU) 2022/2555, Article 11)

How do we handle multi-country operations under NIS 2?

Keep a single baseline CSIRT operating model, then add jurisdiction notes in your obligation register to capture transposition differences without fragmenting response operations. (Directive (EU) 2022/2555)

Where do third-party dependencies fit into Article 11 operationalization?

Treat critical third parties as part of incident coordination: contact paths, escalation triggers, cooperation terms, and evidence that you can execute joint response. (Directive (EU) 2022/2555, Article 11)

What should we do if our incident records are inconsistent across teams?

Standardize the incident record template in your case tool and require it for closure. Backfill a small set of representative cases for evidence, with clear notation of what was reconstructed. (Directive (EU) 2022/2555, Article 11)