MSSP NIS2 Checklist: What Your SOC’s Detection Stack, Training Evidence, and Incident Playbook Must Cover Under CIR 2024/2690

Every MSSP operating inside the EU faces two distinct NIS2 obligations: requirements that apply to your own network and information systems, and obligations governing how you protect client environments. Commission Implementing Regulation (EU) 2024/2690, which came into force on 7 January 2025, directly names managed security service providers as covered entities in Annex I of the NIS2 Directive—placing you under the same binding technical requirements as DNS providers, cloud services, and data centre operators.

This checklist covers four operational domains that supervisory audits examine first: your detection capability evidence under CIR Section 6.9, your key management lifecycle under CIR Section 9, your SOC training records under Article 21(2)(g), and your incident playbook alignment with Article 23. It also covers the MSSP-specific significance thresholds in CIR Article 10 that determine when your own service outages trigger mandatory notification obligations.

Who This Checklist Covers: MSSP Obligations Under NIS2 and CIR 2024/2690

Article 6(40) of the NIS2 Directive defines a managed security service provider as an entity that “carries out or provides assistance for activities relating to cybersecurity risk management.” CIR 2024/2690 applies to MSSPs directly—not only when client contracts require it—because the regulation covers any entity classified under Annex I digital infrastructure. For an overview of how NIS2 classifies MSSPs as Annex I essential entities and the baseline obligations that result, see NIS2 Names MSPs and MSSPs as Annex I Essential Entities.

Two separate obligations follow from this position.

As a covered entity: Your own network and information systems must comply with all 13 thematic areas of the CIR Annex. Supervisory authorities can inspect your internal controls, request documentation, and initiate ex-post audits without a specific incident trigger. Penalties under Article 34(4) reach €10 million or 2% of global annual turnover, whichever is higher.

As a supplier to NIS2-covered clients: Article 21(2)(d) requires your clients to assess your security posture as a direct supplier. Clients will increasingly demand documented evidence that your controls meet CIR requirements because their own supply chain compliance depends on it. For the full analysis of this dual compliance burden, see The MSSP NIS2 Compliance Paradox. For the ICT-managed services supply chain context, see ICT Managed Services Supply Chain Security.

All four checklists below apply to your organisation as a covered entity. Whether they also govern your client-facing service delivery depends on your contract scope and the specific Article 21(2)(d) assessment your clients conduct.

Detection Capability Checklist — CIR Section 6.9

CIR 2024/2690 Section 6.9 imposes two binding sub-requirements on all covered MSSPs. Section 6.9.1 requires entities to protect network and information systems against malicious and unauthorised software. Section 6.9.2 requires implementation of measures to detect or prevent malicious software and, where suitable, deployment of “detection and response software, which is updated regularly” in accordance with risk assessments and provider agreements.

The phrase “detection and response software” covers endpoint detection and response tools, intrusion detection systems, SIEM-connected alert pipelines, and SOAR orchestration—depending on your risk profile. The regulation does not mandate a specific product category, but requires documented justification when your risk assessment concludes that a lower-intensity control is adequate.

The “updated regularly” requirement means your deployment schedule must reflect updates to signatures, threat intelligence feeds, and behavioural detection rules in a documented, auditable cadence. The CIR §3.2 monitoring controls—which govern automated, continuous monitoring infrastructure and protected log retention—run alongside §6.9 rather than replacing it. For the §3.2 requirements in detail, see What NIS2 CIR 2024/2690 Actually Requires for Logging.

• ☐ Anti-malware or EDR tools deployed across all MSSP-managed systems within defined scope
• ☐ Deployment scope documented: which client environments and system types are covered
• ☐ Detection and response software update schedule defined and linked to the risk assessment
• ☐ Update logs retained: evidence that updates are applied within the defined schedule
• ☐ Detection rules (signatures, behavioural analytics, SIEM correlations) documented by system type
• ☐ Rule review cadence defined: frequency for reviewing whether detection rules match current threat intelligence
• ☐ Anomaly detection thresholds documented and linked to the §3.2.2 false-positive minimisation procedure
• ☐ Quarterly or risk-event-triggered detection efficacy review conducted and retained as audit evidence
• ☐ Systems excluded from automated detection: exclusions documented with risk acceptance and management sign-off

Client Data Encryption Checklist — CIR Section 9 Key Management

Article 21(2)(h) of the NIS2 Directive requires “policies and procedures regarding the use of cryptography and, where appropriate, encryption.” CIR 2024/2690 Section 9 operationalises this into three binding sub-requirements that together define the minimum key management lifecycle.

Section 9.1 requires a policy ensuring “adequate and effective use of cryptography to protect the confidentiality, authenticity and integrity of data,” aligned with asset classification and risk assessments. For MSSPs handling client data, asset classification must cover client system data, monitoring telemetry, incident evidence files, and management credentials.

Section 9.2 is where most MSSPs have documentation gaps. It requires policies to establish a complete key lifecycle covering ten discrete stages: key generation, distribution, storage, rotation, compromise handling, revocation, recovery, backup, destruction, and auditing—plus documented activation and deactivation dates for each key. A policy that states “keys are rotated annually” satisfies only one of the ten stages.

Section 9.3 requires periodic review of cryptographic practices against “the state of the art in cryptography,” meaning your algorithm choices must be reviewed when major deprecations are published (for example, SHA-1, 3DES, or weak elliptic curves). For context on how Art.21(2)(h) applies across entity types, see Cryptography and Encryption Under NIS2.

• ☐ Cryptographic policy documented with data classification tiers mapped to algorithm requirements
• ☐ Algorithm and key-length standards defined per classification (e.g., AES-256 at rest, TLS 1.2 minimum in transit)
• ☐ Generation: key generation procedure documented, including randomness source and entropy requirements
• ☐ Distribution: secure channel protocol for key delivery documented (no plaintext transmission path)
• ☐ Storage: key storage mechanism documented; HSM preferred; software vault acceptable if risk-justified with access logging
• ☐ Rotation: rotation schedule defined per key type and data sensitivity; evidence that rotations occur on schedule
• ☐ Compromise handling: procedure documented—who decides, what actions, within what timeframe
• ☐ Revocation: key revocation process documented, including communication to dependent services
• ☐ Recovery: key escrow or recovery procedure documented for business continuity scenarios
• ☐ Backup: key backup process documented, with backup storage isolated from primary key store
• ☐ Destruction: cryptographic erasure method documented for key disposal
• ☐ Auditing: key access log retained with retention aligned to §3.2.5 immutable storage requirement
• ☐ Activation/deactivation dates: each key’s lifecycle dates recorded in a key management register
• ☐ Periodic review: policy reviewed after major cryptographic advisories or at minimum annually (§9.3)

SOC Analyst Training Evidence Checklist — Article 21(2)(g) and CIR Section 8

Article 21(2)(g) requires “basic cyber hygiene practices and cybersecurity training.” CIR Section 8 operationalises this with three binding requirements that carry a critical evidence implication: training must be scheduled over time, role-specific, and—most importantly—“its effectiveness shall be assessed.”

The word “assessed” moves the audit burden from activity records to outcome records. An LMS completion report showing 100% of SOC analysts completed an incident handling module does not, by itself, satisfy §8’s effectiveness requirement. Auditors expect to see: what assessment was used, what were the scores, and whether low scorers received remedial training.

For MSSPs, the security-relevant roles requiring role-specific curriculum include SOC analysts (significance testing under Art.23(3), SIEM alert escalation, evidence preservation), incident response leads (Art.23 notification timelines, CSIRT coordination, IoC documentation), and management body members (Art.20 governance obligations, NIS2 personal liability under Art.34). For a full breakdown of training requirements across entity types, see NIS2 Training Requirements.

• ☐ Training register maintained: employee name, role, module completed, date, and assessment score
• ☐ Security-relevant roles identified: SOC analysts, IR leads, CISO, and management body listed in a role classification document
• ☐ Role-based curriculum documented: SOC-specific modules covering Art.23(3) significance criteria, SIEM alert handling, and evidence chain-of-custody
• ☐ Management body training records: board minutes or signed attestations confirming Art.20 obligations were covered
• ☐ Effectiveness assessments retained: quiz scores, scenario exercise results, or pre/post knowledge assessments
• ☐ Training frequency policy defined: “planned intervals” documented in policy, not left to discretion
• ☐ New employee onboarding training: timestamped completion before access to production systems
• ☐ Threat landscape updates: evidence that training content was reviewed or updated following significant incidents or new threat intelligence
• ☐ Direct supplier awareness: evidence that key contractor and supplier personnel received NIS2 awareness content (§8 applies to direct suppliers)

Incident Playbook Checklist — Aligning SOC Procedures With Article 23 Timelines

Article 23 of the NIS2 Directive establishes a three-stage notification timeline: an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours including an initial severity assessment and indicators of compromise, and a final report no later than one month after submitting the incident notification.

For MSSPs, this creates a structural risk: when your SOC detects an incident at 02:00 and notifies the client at 12:00, the client’s 24-hour Art.23 window is already 10 hours consumed. A written incident playbook that pre-defines escalation authority, client notification timing, and evidence collection protocols is the only operational mechanism that prevents this clock problem from causing client compliance failures. This notification cascade is covered in detail at NIS2 and MSSPs: Who Must Notify CSIRT When Your SOC Detects a Client Incident.

The same playbook governs your own Art.23 obligations as a covered entity, which are triggered by the MSSP-specific significance thresholds in Article 10 described in the next section.

• ☐ Incident playbook exists as a written, versioned document—not an undocumented process
• ☐ Significance decision authority defined: named role in SOC with authority to declare an incident significant
• ☐ Art.23(3) significance criteria embedded: playbook includes a decision tree for (a) severe operational disruption and (b) cascading harm to others
• ☐ Art.10 MSSP thresholds embedded: 30-minute complete unavailability and 5%/1 million-user thresholds listed in the significance test
• ☐ 24-hour early warning procedure: named NIS2 contact at each covered client; pre-drafted notification template
• ☐ Client notification ceiling: playbook specifies maximum delay between SOC detection and client notification
• ☐ 72-hour notification template: pre-structured to include severity level, IoC summary, affected systems, and initial mitigation actions
• ☐ Evidence preservation protocol: chain-of-custody procedure documented—who preserves, what format, where stored, retention period
• ☐ Cross-border routing: for clients operating in multiple EU jurisdictions, playbook specifies which national CSIRT receives notification
• ☐ Tabletop exercise: playbook tested at minimum annually; exercise report retained as audit evidence

Your MSSP’s Own Significant Incident Threshold — CIR Article 10

When an incident affects your own managed service, CIR Article 10 defines the significance thresholds that trigger your own Art.23 notification obligation. These are distinct from the general Art.23(3) criteria and apply specifically to entities operating managed services and managed security services.

Under Article 10 of CIR 2024/2690, your service has experienced a significant incident when: (a) the managed service is completely unavailable for more than 30 minutes; (b) service availability is limited for more than one hour, affecting more than 5% of the service’s users in the Union or more than 1 million users; (c) the integrity, confidentiality, or authenticity of data is compromised as a result of a suspected malicious action—regardless of the number of users affected; or (d) a data compromise from a malicious action affects more than 5% of the service’s users in the Union or more than 1 million users.

Criterion (c) is the most operationally significant for MSSPs: a confirmed breach of client data held in your own SIEM, SOAR platform, or threat intelligence system—even affecting a single client—qualifies as a significant incident requiring Art.23 notification by your own organisation to your national CSIRT. This is separate from, and runs in parallel with, any obligation you have to notify that client.

• ☐ Art.10 thresholds documented in your incident playbook alongside general Art.23(3) criteria
• ☐ Uptime monitoring configured to alert at 20-minute degradation (buffer before the 30-minute Art.10(a) trigger)
• ☐ User count methodology defined: how do you calculate “% of users in the Union” if a service degradation occurs?
• ☐ Data-in-MSSP inventory: documented register of which client data your platform holds (SIEM logs, telemetry, threat intel)—basis for Art.10(c) breach assessment
• ☐ Dual-track notification procedure: Art.23 filing to your own CSIRT is separate from contractual client notification

FAQ

Does CIR 2024/2690 apply to MSSPs directly, or only through client supply chain requirements?
Directly. CIR 2024/2690 names managed security service providers as covered entities under Article 1 and applies the full Annex requirements to your own organisation. Your internal controls must comply regardless of whether client contracts reference the regulation.

What is the difference between CIR Section 6.9 and Section 3.2?
Section 3.2 governs monitoring and logging infrastructure—the processes for detecting and recording events across your network. Section 6.9 governs protection against malicious and unauthorised software specifically, including deployment and maintenance of detection and response tools. Both apply: §3.2 sets the monitoring framework; §6.9 requires the endpoint and system-level detection capability operating within it.

How often must SOC training be conducted under NIS2?
CIR Section 8 requires training at “planned intervals” rather than prescribing a fixed frequency. Your organisation defines the interval, but must document it, apply it consistently, and retain evidence of delivery. Annual training with updates following significant incidents or major threat intelligence changes is a defensible baseline for most MSSP roles. High-risk roles—incident response leads, CISO—benefit from more frequent refreshers.

Can my MSSP file Art.23 notifications on behalf of clients?
No. The Art.23 notification obligation belongs to the covered entity—your client. You cannot fulfil their regulatory notification obligation on their behalf; you can only support the process by delivering timely, accurate incident information within the contractually defined window. For the notification cascade in detail, see the full analysis at NIS2 and MSSPs: Who Must Notify CSIRT (linked above).

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Commission Implementing Regulation (EU) 2024/2690, Annex Sections 6.9 and 9; Article 10. EUR-Lex (eur-lex.europa.eu).
2. NIS2 Directive (EU) 2022/2555, Articles 6(40), 21(2)(g), 21(2)(h), 23. nis-2-directive.com.
3. ENISA Technical Implementation Guidance on Cybersecurity Risk Management Measures, Version 1.0 (June 2025). European Union Agency for Cybersecurity. enisa.europa.eu