EU Cyber Solidarity Act Compliance Checklist for SaaS Developers: Complete Audit Readiness Guide 2026

Post #5 in the sota.io EU Cyber Solidarity Act Series

This is the finale of the sota.io EU Cyber Solidarity Act series. In the first four posts, we covered the Act's scope and structure, the European Cyber Shield's threat intelligence infrastructure, the Cybersecurity Reserve's MSSP pre-qualification framework, and the cross-border incident handling architecture. This post synthesizes everything into a practical compliance checklist — a structured audit tool SaaS developers can use to assess their current posture and identify concrete gaps.

The EU Cyber Solidarity Act (Regulation (EU) 2024/2847) does not create entirely new obligations in isolation. Its compliance requirements are layered on top of NIS2, and for SaaS platforms handling personal data, GDPR. The checklist structure reflects that layering: NIS2 prerequisites first, then CSA-specific additions.

How to Use This Checklist

Each section maps to one dimension of the CSA compliance framework. For each item, the status options are:

• ✅ Done — requirement is met, evidence exists
• ⚠️ Partial — work in progress or gaps identified
• ❌ Not started — gap confirmed, action needed
• N/A — not applicable to your specific scope

Work through Section 1 (applicability) first. If you are out of scope, the rest of the checklist does not apply. If you are in scope, complete every section before your first regulatory inspection.

Section 1 — Applicability Self-Assessment

The EU Cyber Solidarity Act applies to entities and systems that fall within its specific governance architecture. Not every SaaS product is in scope.

1.1 Entity Classification

☐ Determine your NIS2 classification

The Cyber Solidarity Act's incident coordination mechanism is built on top of the NIS2 entity classification framework. Your starting point is whether you qualify as an essential entity (Annex I of NIS2) or important entity (Annex II of NIS2).

Essential entity categories under NIS2 Annex I include: energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure (IXPs, DNS providers, TLD registries, cloud computing service providers, data centre service providers, content delivery networks, trust service providers, electronic communications networks), and ICT service management (managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms).

Important entity categories under NIS2 Annex II include: postal and courier services, waste management, manufacture of chemicals, food production, manufacturing of medical devices, computers, motor vehicles and other transport equipment, digital providers (online marketplaces, search engines, social networking platforms below essential thresholds), research organisations.

☐ Apply the size threshold test

NIS2 applies the general EU SME size thresholds: entities with 50 or more employees AND €10M or more in annual turnover or balance sheet. Entities below both thresholds are out of scope unless they are the sole provider of a service essential for maintaining critical societal or economic activities in a member state.

SaaS platforms serving multiple sectors may qualify through multiple pathways simultaneously. A developer tooling platform serving critical infrastructure clients may be classified as an ICT service manager even if it would otherwise fall below thresholds.

☐ Identify your member state registrations

Your obligations under the Cyber Solidarity Act's coordination mechanism flow through national competent authorities. Identify which member states you have formal NIS2 notification obligations toward based on where you provide services to essential or important entities.

1.2 CSA-Specific Scope

☐ Assess whether you are eligible to access the Cybersecurity Reserve

The European Cybersecurity Reserve (managed by ENISA under Chapter III of the Act) provides incident response support through pre-qualified trusted providers. This resource is available to EU member states for significant and large-scale incidents affecting entities in their jurisdiction. Understanding whether your incident could trigger a Reserve request — and what that means for your interaction with national authorities — requires clarity on your entity classification.

☐ Assess whether you provide services to critical sectors

If your SaaS platform serves essential entities in the energy, health, financial, or digital infrastructure sectors, a significant incident affecting your platform may trigger cross-border coordination under the Act, even if your own classification would not otherwise reach that threshold.

Section 2 — NIS2 Prerequisite Readiness

These items are NIS2 obligations that form the foundation of CSA compliance. You cannot be CSA-ready without these in place.

2.1 Registration and Notification

☐ Registered with national competent authority

If you qualify as an essential or important entity under NIS2, you must register with the designated national competent authority in each relevant member state. Registration requirements vary by country — Germany, France, the Netherlands, and others have published their NIS2 national implementation guidance.

☐ Incident reporting contacts established

Your technical and management contacts for incident reporting to national CSIRTs must be current and tested. Regulatory inspections routinely check that contact information is accurate and that the people listed actually know their role.

☐ Significant incident threshold defined internally

NIS2 requires reporting of significant incidents — defined as incidents with a substantial impact on service provision. Your internal incident severity framework must map to the regulatory definition. Document the specific criteria that trigger a regulatory report.

2.2 Incident Reporting Timelines

☐ Early warning process: 24-hour clock documented

A significant incident triggers an early warning notification obligation within 24 hours of becoming aware. "Becoming aware" is the detection moment, not the moment of full assessment. Your incident response runbook must document this distinction and establish the immediate escalation path.

☐ Initial notification process: 72-hour target documented

Following the early warning, a more detailed initial notification must be submitted within 72 hours, including the incident's nature, preliminary impact assessment, and initial indicators of compromise where available.

☐ Final report process: 1-month target documented

A comprehensive final incident report, including a full description, root cause analysis, and remediation steps taken, must be submitted within one month of the initial notification. For ongoing incidents, an intermediate report is required at the one-month mark.

☐ Multi-jurisdiction reporting mapped

If you serve clients in multiple EU member states, a significant incident may require parallel reporting to multiple national CSIRTs. Map which authorities require notification and what their country-specific requirements are.

2.3 Technical Security Baseline

☐ Risk management framework documented

NIS2 requires entities to implement appropriate technical, operational, and organisational measures. A documented risk management framework demonstrating your approach to identifying, assessing, and treating cybersecurity risks is a prerequisite for any regulatory engagement.

☐ Supply chain security assessment completed

NIS2 explicitly includes supply chain security as a required risk management domain. If your SaaS platform relies on third-party components, cloud infrastructure, or software dependencies, you need a documented assessment of the cybersecurity posture of your critical suppliers.

☐ Business continuity and disaster recovery tested

Backup procedures, disaster recovery mechanisms, and business continuity management must be documented and tested. Testing records should be available for regulatory inspection.

Section 3 — European Cyber Shield Readiness

The European Cyber Shield (Chapter II of the Act) is built on national and cross-border Security Operations Centres (SOCs). SaaS platforms serving critical sectors increasingly interact with national SOC infrastructure through threat intelligence sharing. This section covers your readiness for that integration.

3.1 Threat Intelligence Sharing Capability

☐ STIX/TAXII integration assessed

The European Cyber Shield infrastructure uses STIX (Structured Threat Information eXpression) and TAXII (Trusted Automated eXchange of Intelligence Information) as the standard formats and transport protocol for threat intelligence. Assess whether your security tooling can produce and consume STIX 2.1 bundles via a TAXII 2.1 API.

Practical starting point: most modern SIEMs (Splunk, Elastic Security, Microsoft Sentinel, open-source options like OpenCTI or Wazuh) have STIX/TAXII connectors available. Evaluate whether your current logging and detection architecture can produce STIX Indicators of Compromise when an incident is detected.

☐ MISP connectivity assessed

MISP (Malware Information Sharing Platform) is the primary open-source threat intelligence sharing platform deployed across EU national cyber agencies. If your security operations team participates in any sectoral or national information sharing community, MISP is likely the technical layer. Assess whether your tooling integrates with MISP instances and whether you have a process for contributing relevant threat data.

☐ Information sharing participation evaluated

Beyond the technical capability, evaluate whether participation in sectoral information sharing communities is appropriate for your threat profile. Sector-specific ISACs (Information Sharing and Analysis Centres) and national coordination bodies provide structured channels for sharing and receiving threat intelligence relevant to your operating environment.

3.2 Detection and Response Capability

☐ Security monitoring coverage mapped

Document the coverage of your security monitoring across your infrastructure. Gaps in monitoring — unmonitored API gateways, third-party integrations without logging, legacy components outside your SIEM scope — are common inspection findings.

☐ Incident detection to notification latency measured

Regulatory obligations have hard timelines from detection. Measure your actual detection-to-notification latency in test scenarios. If your current tooling would not surface a significant incident within a window that allows a 24-hour early warning notification, identify the gap and the remediation path.

Section 4 — Cybersecurity Reserve Access Preparation

The European Cybersecurity Reserve provides pre-qualified trusted providers that can be deployed for significant and large-scale incidents. SaaS platforms do not directly access the Reserve — it is accessed by member state authorities on behalf of affected entities. But your readiness to work with Reserve-deployed experts determines how effectively that support lands.

4.1 Internal Readiness for External Expert Engagement

☐ Technical documentation accessible to external responders

Reserve-deployed incident response experts arrive with limited context about your specific architecture. Maintain technical documentation — architecture diagrams, network topology, data flow maps, service dependencies — that can be shared securely with authorised responders within hours of incident escalation.

☐ Secure communication channel for responder coordination

Identify the secure communication channel you would use to coordinate with national authority representatives and external incident response experts during a live incident. Email to personal accounts is not appropriate. Dedicated incident response communication should use encrypted channels with defined access controls.

☐ Evidence preservation procedures documented

Incident response support is most effective when forensic evidence is available. Document your log retention policies, ensure logs relevant to security events are retained for at least 12 months (a common regulatory standard), and establish the procedure for preserving evidence without disrupting ongoing operations.

☐ National competent authority contact protocol tested

The pathway from your security team to your national competent authority and CSIRT should be documented and tested. For essential entities, this pathway is a regulatory requirement. For entities that may become subject to coordinated response during a large-scale incident, having this pathway pre-established dramatically reduces escalation time.

4.2 Mutual Assistance Framework Awareness

☐ Understand the mutual assistance request pathway

Under the Act's Chapter III mechanism, member states can request mutual assistance from other member states and access ENISA coordination support. For SaaS platforms operating cross-border, a significant incident may involve competent authorities from multiple jurisdictions engaging with your team simultaneously.

Establish clarity internally on: who has authority to engage with foreign regulators, what information disclosure is appropriate in coordinated response scenarios, and how your legal team should be involved in cross-border regulatory engagement.

Section 5 — Cross-Border Incident Handling Readiness

For SaaS platforms operating across multiple EU member states or serving clients whose incidents may have cross-border dimensions, preparation for EU-CyCLONe-coordinated response is a practical operational requirement.

5.1 Incident Classification Framework

☐ Internal incident severity levels mapped to regulatory thresholds

Your internal P0/P1/P2 severity framework (or equivalent) should be explicitly mapped to the regulatory significance thresholds under NIS2 and the CSA. An internal P1 may or may not be a "significant incident" for regulatory purposes — the mapping must be explicit and agreed by your security, legal, and engineering leadership.

☐ Cross-border impact assessment procedure documented

For each high-severity incident, establish a documented assessment procedure that evaluates whether the incident has cross-border dimensions: Does it affect services consumed by clients in multiple member states? Does the attack infrastructure or threat actor appear to be targeting entities beyond your jurisdiction? Could the incident cascade to affect critical infrastructure operated by clients?

☐ Multi-jurisdiction notification sequencing planned

If a significant incident triggers parallel notification obligations in multiple member states, the sequencing and content consistency of those notifications needs to be planned in advance. Inconsistent notifications to different authorities create unnecessary regulatory complexity during an already stressful incident.

5.2 Preparedness Actions

☐ Tabletop exercise including regulatory notification scenario completed

The most reliable way to validate your incident response readiness is to run a tabletop exercise that includes the full notification workflow — from detection through early warning to initial notification. Include your legal and communications teams. Document the exercise findings and remediation actions.

☐ Incident response retainer evaluated

For SaaS platforms serving critical sectors, having a pre-established relationship with an incident response retainer — ideally one of the trusted providers pre-qualified for the Cybersecurity Reserve — provides a direct path to expert support during a live incident. Evaluate whether a retainer arrangement is appropriate given your threat profile and client base.

Section 6 — Documentation and Audit Readiness

Regulatory inspections under NIS2 and CSA oversight focus heavily on documentation quality. Technical controls without documentation are not verifiable. Documentation without tested processes is not credible.

6.1 Core Documentation

☐ Cybersecurity policy documented and approved by management

A cybersecurity policy approved at senior management level, covering your approach to risk management, incident response, supply chain security, and business continuity, is the baseline document for any regulatory engagement.

☐ Incident response plan documented and version-controlled

Your incident response plan should be a living document — version-controlled, regularly reviewed, and updated after every significant incident or tabletop exercise. It should cover the full lifecycle from detection through notification through remediation and post-incident review.

☐ Risk register maintained and current

A current risk register demonstrating your ongoing risk assessment and treatment process is a standard regulatory inspection document. "Current" typically means reviewed within the past 12 months, with identified risks tracked through to treatment status.

☐ Security measure effectiveness evidence available

NIS2 requires proportionate security measures. "Proportionate" requires evidence that you assessed the risks and chose measures accordingly. For each significant security control, maintain evidence of why it was selected and how its effectiveness is measured.

6.2 Evidence Collection

☐ Log retention policy implemented

Define and implement a log retention policy. Security-relevant events — authentication, administrative actions, API access, configuration changes — should be retained for at least 12 months. For entities under regulatory scrutiny, longer retention periods may be advisable.

☐ Security testing records maintained

Penetration testing reports, vulnerability scan results, and remediation tracking records demonstrate ongoing security investment. Maintain these records and ensure they are available for regulatory disclosure where appropriate.

☐ Third-party security assessment records available

If you use third-party cloud infrastructure, CDN, or critical SaaS dependencies, maintain records of those providers' security certifications (ISO 27001, SOC 2, CSA STAR, or equivalent). This forms part of your supply chain security evidence.

Section 7 — EU-Native Infrastructure Considerations

For SaaS platforms operating under EU data governance requirements, infrastructure jurisdiction intersects directly with cybersecurity compliance. This section addresses the infrastructure dimension of CSA compliance.

7.1 Data Residency and Jurisdiction

☐ Incident evidence data residency mapped

Security logs, forensic data, and incident evidence are subject to the same data residency considerations as operational data. If your logging infrastructure stores data outside the EU, the jurisdictional reach of non-EU law enforcement requests — including the US CLOUD Act — applies to that evidence. This has implications both for your GDPR compliance and for your ability to control what is disclosed to authorities during an incident.

☐ Incident response tooling jurisdiction assessed

If your security operations platform (SIEM, EDR, vulnerability management) is hosted by a US-headquartered provider on US infrastructure, your incident response tooling is subject to US jurisdiction. For entities handling sensitive critical infrastructure data, this is a meaningful risk in the CSA compliance context.

☐ Communication channel data residency confirmed

Incident response coordination — especially for events that may involve regulatory engagement — should use communication channels where the confidentiality of communications is protected by EU jurisdiction. Legal professional privilege and regulatory communication confidentiality work differently when communications transit US-controlled infrastructure.

7.2 Infrastructure as Compliance Evidence

Choosing EU-native infrastructure for your security logging, incident response tooling, and compliance evidence storage is not merely a principle — it simplifies regulatory engagement. When a national CSIRT requests logs or forensic evidence, being able to provide that evidence under a straightforward EU legal framework is materially easier than navigating cross-border data transfer restrictions during an active incident.

Complete Checklist Summary

For quick reference, here is the condensed checklist across all seven sections:

Section 1 — Applicability

• NIS2 entity classification confirmed
• Size threshold test applied
• Member state registrations identified
• CSA scope assessment completed

Section 2 — NIS2 Prerequisites

• Registered with national competent authority
• Incident reporting contacts current
• Significant incident threshold defined
• 24-hour early warning process documented
• 72-hour initial notification process documented
• 1-month final report process documented
• Multi-jurisdiction reporting mapped
• Risk management framework documented
• Supply chain security assessment completed
• Business continuity and DR tested

Section 3 — European Cyber Shield

• STIX/TAXII integration assessed
• MISP connectivity assessed
• Information sharing participation evaluated
• Security monitoring coverage mapped
• Detection-to-notification latency measured

Section 4 — Cybersecurity Reserve

• Technical documentation accessible to external responders
• Secure responder communication channel defined
• Evidence preservation procedures documented
• NCA contact protocol tested
• Mutual assistance pathway understood

Section 5 — Cross-Border Readiness

• Severity levels mapped to regulatory thresholds
• Cross-border impact assessment procedure documented
• Multi-jurisdiction notification sequencing planned
• Tabletop exercise including notification scenario completed
• Incident response retainer evaluated

Section 6 — Documentation

• Cybersecurity policy approved by management
• Incident response plan current and version-controlled
• Risk register maintained
• Security measure effectiveness evidence available
• Log retention policy implemented
• Security testing records maintained
• Third-party security assessment records available

Section 7 — Infrastructure

• Incident evidence data residency mapped
• Incident response tooling jurisdiction assessed
• Communication channel data residency confirmed

What to Do After This Checklist

Running this checklist produces one of three outcomes:

Outcome 1 — Out of scope: Your entity classification assessment in Section 1 determines you are not subject to NIS2 and therefore not in the CSA coordination architecture. Document the assessment. Revisit annually — thresholds and sector classifications continue to evolve.

Outcome 2 — Partial compliance with identified gaps: The most common outcome. Prioritise by regulatory risk: multi-jurisdiction notification readiness and incident detection timelines are the highest-risk gaps because they have hard regulatory deadlines once an incident occurs. Start there.

Outcome 3 — Substantially compliant: Use the checklist as an ongoing audit tool. Schedule a full review at least annually, after any significant incident, and when your service offering or customer base changes in ways that could affect your entity classification.

The EU Cyber Solidarity Act is not a one-time compliance exercise. It is a framework that assumes ongoing engagement between regulated entities and the national and EU-level bodies responsible for coordinating cybersecurity responses. The organisations that navigate it most effectively are those that build the regulatory relationships, technical capabilities, and documentation practices before an incident — not during one.

Series Summary

This five-post series covered the EU Cyber Solidarity Act comprehensively:

• Post 1: Act overview, scope, and what it means for SaaS developers
• Post 2: European Cyber Shield — national SOC architecture, threat sharing infrastructure (STIX/TAXII/MISP), and the pan-European SOC
• Post 3: European Cybersecurity Reserve — MSSP pre-qualification, trusted provider selection, and incident response deployment
• Post 4: Cross-border incident handling — EU-CyCLONe architecture, escalation chains, and the 24/72-hour notification framework
• Post 5 (this post): Complete compliance checklist — applicability through audit readiness, with actionable implementation guidance across all seven dimensions

The EU Cyber Solidarity Act joins NIS2, GDPR, and the EU AI Act as a foundation pillar of the EU's digital regulation stack. For SaaS platforms serving the European market, the compliance investment is not optional — but approached systematically, it is manageable.

Deploying your compliance infrastructure on EU-native, CLOUD Act-free infrastructure simplifies every dimension of the regulatory engagement described in this series. sota.io provides EU-managed PaaS on Hetzner Germany — no US parent, no CLOUD Act exposure, built for exactly this operating environment.