EU Cyber Solidarity Act Readiness with ISO 27001

The 03:17 incident that turns EU cooperation into your audit problem

At 03:17 on a Tuesday morning, Maria, the CISO of InnovateCloud, is staring at a screen full of alerts. Her company is a mid-sized European SaaS provider serving logistics customers across Germany, France and Poland. The first alert looks like suspicious privileged access in a production tenant. Ten minutes later, the managed security service provider reports similar activity affecting two other customers. By 04:00, the SOC sees API calls from infrastructure previously associated with ransomware staging.

InnovateCloud was not the original target. A core infrastructure provider appears to be in the blast radius. The impact, however, is now Maria’s problem.

One affected customer is a German bank asking for answers under DORA. Another is a critical supplier in the energy sector already classified under national NIS2 rules. The environment may contain personal data, but exfiltration is not yet confirmed. The security team wants to contain the threat immediately. Legal wants to know whether the NIS2 24-hour early warning clock has started. The privacy lead is asking whether GDPR breach notification is possible. The board wants to know if the outage could spread across Member States.

In 2026, this is no longer just an internal crisis.

The EU Cyber Solidarity Act changes the operating reality for large-scale and cross-border cyber incidents. It introduces EU-level detection, preparedness and response mechanisms, including the European Cybersecurity Alert System, the Cybersecurity Emergency Mechanism and the EU Cybersecurity Reserve. Even if an organisation never directly requests help from the reserve, its evidence, authority contacts, supplier contracts, incident timelines and customer communications may become part of a wider European response chain.

The gap appears quickly. Many organisations have tools, tickets and policies, but not evidence that survives regulatory scrutiny. They can say, “we contacted the regulator,” but cannot prove who was authorised, which threshold triggered contact, what was communicated, whether logs were preserved, whether a supplier was contractually required to assist, or whether a final report can be reconstructed from contemporaneous decisions.

The answer is not another isolated “Cyber Solidarity Act binder.” The answer is an ISO/IEC 27001:2022 information security management system that produces evidence once and reuses it across NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT 2019 expectations.

That evidence starts before the incident.

Why the EU Cyber Solidarity Act raises the evidence standard

The Cyber Solidarity Act is designed for EU-level cyber detection, preparedness and crisis response. Its practical effect for CISOs, auditors and compliance managers is clear: large-scale incident coordination requires evidence that is faster, cleaner, more consistent and easier to share with trusted stakeholders.

When cross-border impact is possible, an organisation may need to coordinate with national CSIRTs, competent authorities, sector regulators, data protection authorities, financial supervisors, law enforcement, customers, processors, suppliers and external incident responders. The EU Cybersecurity Reserve adds another dimension because pre-vetted private providers may support preparedness, response and recovery. That makes supplier governance, legal authority, data handling and evidence preservation even more important.

Private entities sit at the centre of this reality. Cloud providers, data centres, managed service providers, managed security service providers, digital infrastructure operators, fintechs and SaaS platforms often hold the telemetry, logs, customer impact data and technical facts that authorities need to understand a major incident.

NIS2 already points in this direction. It applies to many medium-sized and large entities in Annex I and Annex II sectors that provide services or carry out activities in the EU. It also captures certain entities regardless of size, including trust service providers, DNS service providers, top-level domain registries and domain-name registration service providers. Annex I includes digital infrastructure such as cloud computing services, data centre services, content delivery networks, DNS providers, trust service providers and TLD registries. It also includes ICT service management B2B, including managed service providers and managed security service providers. Annex II includes digital providers such as online marketplaces, online search engines and social networking services platforms.

DORA adds a second layer for the financial sector. Since 17 January 2025, it applies to a broad range of financial entities, including credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, trading venues, insurance and reinsurance undertakings, credit rating agencies, crowdfunding service providers and others. It also creates significant expectations for ICT third-party service providers because financial entities remain accountable for outsourced ICT services.

A fintech incident in 2026 may therefore be coordinated through DORA supervisory channels, while the SaaS provider or MSSP supporting that fintech may sit under NIS2. The same technical event can create different reporting duties, evidence expectations and contractual obligations for different actors.

ISO/IEC 27001:2022 gives organisations the operating system to manage this complexity. Clauses 4.1 to 4.4 require the organisation to define the ISMS in its business context, identify interested parties and their legal, regulatory and contractual requirements, define boundaries and dependencies, and establish the management system. Clauses 5.1 to 5.3 make leadership accountable for policy, resources, integration and role assignment. Clauses 6.1.1 to 6.1.3 require repeatable risk assessment, risk treatment and a Statement of Applicability. Clause 8.1 requires operational control, including control over externally provided processes, products and services.

This is the core of Cyber Solidarity Act readiness: prove that crisis response is managed, tested and auditable, not improvised.

The Clarysec evidence model: one incident, many obligations

A cross-border incident does not wait while legal teams classify it. Evidence must be captured from the first alert, then filtered into the right reporting and coordination paths.

Clarysec’s approach connects three assets:

1. Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, which turns ISO/IEC 27001:2022 implementation into a sequenced, audit-ready journey.
2. Zenith Controls: The Cross-Compliance Guide Zenith Controls, which maps ISO/IEC 27002:2022 controls to related controls, attributes, operational capabilities, security domains and cross-framework evidence expectations.
3. Clarysec policy templates for incident response, evidence collection, supplier security, logging, monitoring and business continuity, adapted for enterprise and SME environments.

In the Zenith Blueprint, Controls in Action phase, Step 22 addresses ISO/IEC 27002:2022 control 5.5, Contact with authorities. It states:

Control 5.5 ensures that an organization is prepared to interact with external authorities when needed, not reactively or under panic, but through predefined, structured, and well- understood channels.

The same section asks the question every CISO should answer before the crisis:

if your organization were targeted by a cyberattack, involved in a data breach, or under investigation , who would make the call to the authorities? How would they know what to say? Under what conditions would such contact be initiated?

That is not administrative paperwork. In a Cyber Solidarity Act environment, it is the difference between a calm early warning and contradictory messages across jurisdictions.

Zenith Controls treats ISO/IEC 27002:2022 control 5.5, Contact with authorities, as preventive and corrective, connected to confidentiality, integrity and availability, and aligned to Identify, Protect, Respond and Recover concepts. It ties 5.5 to incident management planning and preparation, event reporting, threat intelligence, special interest groups and response to incidents.

The same guide treats ISO/IEC 27002:2022 control 5.24, Information security incident management planning and preparation, as a corrective control connected to Respond and Recover. Its ties to event assessment, incident response, lessons learned, logging, monitoring, security during disruption and continuity show what auditors often test: whether your plan links detection, classification, escalation, evidence, recovery and learning.

For evidence handling, ISO/IEC 27002:2022 control 5.28, Collection of evidence, is especially important. Zenith Controls connects it to incident response, logging, monitoring and event reporting. In a serious cross-border incident, this is where technical investigation becomes defensible.

Mapping Cyber Solidarity Act readiness to ISO 27001 evidence

The EU Cyber Solidarity Act creates a preparedness and coordination environment. ISO/IEC 27001:2022 provides the evidence engine. NIS2, DORA and GDPR define many specific reporting, governance and protection expectations.

Notice what is absent: a separate compliance silo. The same evidence that supports ISO/IEC 27001:2022 certification can support NIS2 management accountability, DORA ICT risk management, GDPR security accountability, NIST CSF communication outcomes and COBIT 2019 assurance expectations.

NIS2: the reporting clock starts when awareness begins

NIS2 is central to 2026 readiness because it defines a staged incident reporting workflow.

Article 23 requires essential and important entities to notify their CSIRT or competent authority without undue delay of significant incidents affecting service provision. The early warning must be submitted without undue delay and no later than 24 hours after becoming aware of the significant incident. It should indicate, where applicable, whether malicious or unlawful acts are suspected and whether cross-border impact is possible.

An incident notification follows without undue delay and no later than 72 hours after awareness, updating the early warning and giving an initial assessment of severity, impact and available indicators of compromise. A final report is due within one month after the incident notification, with severity, impact, likely threat type or root cause, mitigation measures and cross-border impact.

This is why incident response cannot start with a blank document.

The enterprise Incident Response Policy Incident Response Policy states:

NIS2 Article 23 (notification within 24 hours of becoming aware of the incident)

The SME Incident Response Policy - SME Incident Response Policy - SME brings the same timing logic into practical governance:

“Response timelines, including data recovery and notification obligations, must be documented and aligned with legal requirements, such as the GDPR 72-hour personal data breach notification requirement.”

From Incident Response Policy - SME, section “Governance Requirements”, clause 5.3.2.

It also forces the multi-regime assessment into the incident process:

“Where customer data is involved, the General Manager must assess legal notification obligations based on the applicability of GDPR, NIS2, or DORA.”

From Incident Response Policy - SME, section “Risk Treatment and Exceptions”, clause 7.4.1.

In a Cyber Solidarity Act scenario, “cross-border impact is possible” becomes operationally important. The early warning may not have complete facts, but the organisation must be able to show why it suspected or did not suspect cross-border impact based on available evidence.

The incident record should capture:

• When the organisation became aware.
• Who declared the event as a potential incident.
• Which services, countries, customers or sectors were potentially affected.
• Whether malicious or unlawful activity was suspected.
• Which indicators of compromise were available.
• Which authority contact path was used.
• Whether customer communications were required.
• Which evidence was preserved before major remediation.

The best time to design these fields is before 03:17.

DORA: when the customer is regulated but the supplier holds the logs

DORA changes the supplier conversation. Financial entities must manage ICT third-party risk as part of their ICT risk management framework. Outsourcing ICT services does not transfer regulatory responsibility away from the financial entity.

DORA requires ICT third-party risk strategies, registers of ICT service contracts, due diligence, audit and inspection planning, termination rights and tested exit strategies for critical or important ICT services. Article 30 requires contractual clarity, including service descriptions, locations, data handling, confidentiality, integrity, availability, service levels, assistance during ICT incidents, cooperation with authorities and termination rights. For critical or important functions, stricter terms apply.

Return to Maria’s incident. The German bank is regulated under DORA. InnovateCloud provides SaaS services. The MSSP detects suspicious activity. The cloud infrastructure provider has some of the key audit logs. A subcontractor operates part of the telemetry pipeline. The bank remains accountable, but it cannot classify and report well without supplier evidence.

Clarysec addresses this through supplier classification and contractual evidence. The enterprise Third party and supplier security policy Third party and supplier security policy requires:

Contracts with suppliers must include:

The SME Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME uses the same compliance logic in a lighter operating model:

Contracts must include mandatory clauses covering:

The value sits in the schedule behind those words: incident notification duties, log access, audit rights, confidentiality, data location, subcontractor controls, cooperation with authorities, recovery support and exit obligations.

The Zenith Blueprint, Controls in Action phase, Step 23, gives the implementation route:

Compile a full list of current suppliers and service providers (5.19), and classify them based on access to systems, data, or operational control. For each classified supplier, verify that security expectations are clearly embedded in contracts (5.20), including confidentiality, access, incident reporting, and compliance obligations.

It continues with downstream risk:

For every critical supplier, identify if they use subcontractors (sub-processors) who may access your data or systems. Document how your information security requirements are flowed down to these parties, either through your supplier’s contract terms or your own direct clauses.

This is Cybersecurity Reserve readiness too. If an external response provider enters your environment during an emergency, you must know the legal basis, access scope, evidence rules, data handling obligations, authority coordination path and exit conditions. DORA makes this explicit for financial entities. NIS2 makes it relevant to essential and important entities. ISO/IEC 27001:2022 makes it auditable.

GDPR: the breach question inside the cyber crisis

Not every cybersecurity incident is a personal data breach, but every serious incident should be assessed for that possibility.

GDPR applies to processing in the context of an EU establishment, and also to non-EU controllers or processors offering goods or services to individuals in the EU or monitoring their behaviour in the EU. It defines personal data, processing, controller, processor and personal data breach. Its principles include integrity, confidentiality and accountability, meaning controllers must be able to demonstrate compliance.

During the 03:17 incident, Maria’s team must ask:

• Was personal data accessed, disclosed, altered, lost or destroyed?
• Is InnovateCloud a controller, processor or both for the affected data?
• Are special categories of personal data involved?
• Which customers or individuals are affected?
• Are logs sufficient to assess scope?
• Do GDPR notification duties run in parallel with NIS2 or DORA duties?

This is why privacy coordination belongs in incident escalation, not in a late legal review after systems have been rebuilt and logs have rotated.

The SME Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME states:

High-priority alerts must be escalated to the GM and Privacy Coordinator within 24 hours

That clause is simple, but it solves a real failure pattern. Privacy leaders need evidence while it is still fresh enough to determine whether a personal data breach occurred and whether individuals are at risk.

Build a 24-hour cross-border incident evidence pack

A practical readiness exercise should simulate the first 24 hours of a cross-border incident. The goal is not to over-report. The goal is to prove that the organisation can assemble facts, make defensible decisions and keep communications consistent.

Scenario

Your MSSP detects suspicious privileged access from an unusual region against your production tenant. The same source infrastructure appears in alerts affecting two customers in two Member States. One customer is a financial entity. The affected environment contains personal data, but exfiltration is not confirmed.

Step 1: Open the incident record

Create the incident ticket using approved classification fields. Include awareness time, detection source, impacted assets, impacted services, countries potentially affected, suspected malicious activity, initial severity and incident commander.

Tie this to ISO/IEC 27002:2022 controls 5.24, 5.25 and 5.26, and to ISO/IEC 27001:2022 Annex A controls A.5.24, A.5.25 and A.5.26.

Step 2: Trigger the authority decision workflow

Use the authority contact matrix required by Zenith Blueprint Step 22. Identify which authorities may be relevant: national CSIRT, data protection authority, financial regulator, law enforcement and sector regulator.

Record the decision and the rationale. If a NIS2 early warning is not made, capture why. If cross-border impact is possible, record the evidence supporting that conclusion.

Step 3: Preserve evidence before major remediation

The enterprise Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy states:

All collected evidence shall be uniquely identified, labeled, and stored in a secure repository with:

The SME Evidence Collection and Forensics Policy - SME Evidence Collection and Forensics Policy - SME gives the same discipline in simpler form:

“Each item of digital evidence must be logged with:”

From Evidence Collection and Forensics Policy - SME, section “Governance Requirements”, clause 5.2.1.

For the tabletop, collect sample evidence entries: SIEM alert export, identity provider logs, privileged session records, endpoint snapshot, firewall logs, cloud audit logs, customer impact notes and communication approvals.

Step 4: Activate supplier assistance

Check the supplier register. Identify the MSSP, cloud provider and critical subcontractors. Confirm incident support clauses, escalation contacts, log retention periods, evidence format and authority cooperation obligations.

This directly supports DORA ICT third-party risk requirements and NIS2 supply-chain security expectations.

Step 5: Draft three communications

Draft three communications from the same fact base:

Step 6: Close with lessons learned

Update the risk register, Statement of Applicability, supplier register and incident response plan. If the exercise reveals missing logs, unclear authority contacts or weak supplier clauses, raise corrective actions.

The Zenith Blueprint, Controls in Action phase, Step 23, instructs organisations to validate incident capabilities this way:

Select a recent event or conduct a tabletop exercise to validate your plan. Capture and log all decisions, roles, and communications (5.26), and update the plan with lessons learned (5.27). Confirm that procedures are in place to preserve forensic evidence (5.28), including log snapshots, backups, and secure isolation of impacted systems.

That paragraph is an audit-ready exercise agenda.

Logging: the difference between coordination and speculation

Cross-border incident coordination fails when everyone has opinions and nobody has timestamps.

The Zenith Blueprint, Controls in Action phase, Step 19, puts it clearly:

Logging is the lifeblood of any secure IT environment. Without it, incidents remain invisible, accountability fades, and cause-and-effect relationships vanish into thin air.

It continues:

At its heart, logging is about traceability. When something goes wrong, whether it’s a failed login attempt, the deletion of critical files, or a rogue script running on a server, logs provide the forensic thread that helps you untangle what really happened.

For NIS2, logs support the 72-hour incident notification with initial severity, impact and indicators of compromise. For DORA, logs support major ICT-related incident classification, root cause analysis, operational impact and third-party accountability. For GDPR, logs support the assessment of whether personal data was accessed or disclosed. For a Cyber Solidarity Act context, logs support shared situational awareness without forcing responders to rely on speculation.

If the answer to any question is “not sure,” the issue belongs in the risk treatment plan.

Business continuity and secure crisis operations

The Cyber Solidarity Act conversation naturally focuses on incident response, but resilience also means keeping critical services secure during disruption.

NIS2 Article 21 requires an all-hazards approach covering incident handling, business continuity, backup management, disaster recovery, crisis management, supply-chain security, vulnerability handling, effectiveness assessment, cyber hygiene, cryptography, HR security, access control, asset management, multi-factor authentication, secure communications and secured emergency communications where appropriate.

DORA similarly requires governance, ICT risk management, incident management, resilience testing, third-party risk management, continuity and recovery. Smaller entities may have simplified requirements, but they still need documented ICT risk management, monitoring, resilient systems, incident handling, third-party dependency identification, backups, restoration, testing, post-incident learning and training.

The enterprise Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy starts from a simple requirement:

Plans shall cover:

Behind that phrase sits the continuity evidence auditors expect: recovery priorities, recovery time objectives, recovery point objectives, backup schedules, restoration tests, crisis roles, alternate communications, supplier dependencies and post-exercise improvement actions.

ISO/IEC 27002:2022 controls 5.29 and 5.30 are central here. Control 5.29 addresses information security during disruption. Control 5.30 addresses ICT readiness for business continuity. In Zenith Controls, incident planning under 5.24 is tied to security during disruption and broader continuity planning. This is especially relevant when normal channels are unavailable, identity systems are degraded or crisis teams must coordinate with authorities through secured emergency communications.

Cross-compliance map: NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT 2019

A CISO does not need five separate incident programs. They need one evidence model that can be viewed through five lenses.

The NIST CSF 2.0 Current and Target Profile method is especially useful for organisations not yet mature enough for a full integrated GRC platform. It encourages organisations to scope a profile, gather inputs such as policies, enterprise risk priorities, business impact analyses, requirements, standards, procedures, safeguards and roles, then analyze gaps and create a prioritized action plan. That is close to a practical Cyber Solidarity Act readiness sprint: current evidence, target obligations, gap plan, owners, dates and audit trail.

COBIT 2019 and ISACA-style auditors tend to ask whether governance objectives are owned, measured and monitored. They will not be satisfied with “the SOC handles it.” They will ask how management bodies approve risk measures, how performance is reported, how third-party risk is governed, how exceptions are accepted and how corrective actions are tracked.

How auditors will test the same incident

The same 03:17 incident produces different audit questions depending on the assessor’s mandate.

An ISO/IEC 27001:2022 auditor will start with the ISMS. They will ask whether the incident process is in scope, whether interested-party requirements include NIS2, DORA, GDPR and contracts, whether the risk assessment considered cross-border and supplier scenarios, whether Annex A controls were selected in the Statement of Applicability, and whether operational records prove the process was followed.

A NIS2-focused authority or assessor will focus on management accountability, Article 21 risk-management measures and Article 23 reporting. They may ask when the organisation became aware, why the incident was or was not significant, how cross-border impact was assessed, whether customers were informed and whether corrective measures were taken without undue delay.

A DORA supervisor or internal audit team will ask whether the incident affected critical or important functions, whether ICT third-party providers supported the response, whether the financial entity retained responsibility, whether the register of information was accurate, whether the incident was classified correctly and whether lessons learned fed back into resilience testing and supplier oversight.

A GDPR auditor or data protection authority will ask whether the organisation had enough evidence to determine if personal data was breached, whether controller and processor roles were clear, whether data subjects were at risk, whether confidentiality and integrity controls were appropriate and whether accountability records were maintained.

A NIST CSF 2.0 assessor will translate the event into Govern, Identify, Protect, Detect, Respond and Recover outcomes. They will look for stakeholder expectations, legal obligations, risk appetite, supplier governance, logging, monitoring, response execution, communications and recovery validation.

A COBIT 2019 or ISACA auditor will focus on governance and management system effectiveness: ownership, decision rights, metrics, risk acceptance, process performance, assurance and continuous improvement.

This is where Zenith Controls is useful as a cross-compliance compass. It does not rename official controls or create a parallel control framework. It shows how ISO/IEC 27002:2022 controls such as 5.5, 5.24 and 5.28 connect to operational capabilities, related controls and audit-relevant evidence.

What CISOs should do now for 2026 readiness

If you are preparing for the EU Cyber Solidarity Act operating reality, start with evidence, not slogans.

First, update your ISMS context and interested-party analysis. Identify whether your organisation, customers or suppliers fall under NIS2, DORA or GDPR. Include Member State footprint, sector classification, critical customers, ICT service dependencies and authority contacts.

Second, run a cross-border incident tabletop. Use a scenario that includes a supplier, more than one Member State, possible personal data exposure and a regulated financial customer. Time-box the first 24 hours.

Third, review supplier contracts. Confirm notification duties, log access, forensic support, authority cooperation, subcontractor flow-down, data location, audit rights, continuity support and termination rights.

Fourth, test evidence collection. Export logs, preserve snapshots, label evidence, record chain of custody and validate repository access. If your policy says evidence is uniquely identified and securely stored, prove it.

Fifth, align incident communications. Your NIS2 early warning, DORA escalation, GDPR breach assessment and customer notice should not contradict each other. They can have different legal purposes, but they must come from the same fact base.

Sixth, make the board part of the exercise. NIS2 and DORA both elevate management accountability. ISO/IEC 27001:2022 leadership clauses make this auditable. A board that has never seen a 24-hour cyber notification clock is not ready for a cross-border crisis.

Next steps with Clarysec

The future of EU cybersecurity is one of collaboration and proven trust. Organisations that treat NIS2 and DORA as isolated checklists will struggle during cross-border incidents. Organisations that build evidence-backed ISO/IEC 27001:2022 operating systems will be able to answer regulators, customers, auditors and crisis responders with confidence.

Clarysec helps CISOs, compliance managers, auditors and business owners turn EU cyber regulation into audit-ready operating evidence through:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap for structured ISO/IEC 27001:2022 implementation and audit sequencing.
• Zenith Controls: The Cross-Compliance Guide for mapping incident, authority, supplier, evidence, logging and continuity controls across frameworks.
• Clarysec policy templates, including Incident Response Policy, Evidence Collection and Forensics Policy, Third party and supplier security policy, Business Continuity Policy and Disaster Recovery Policy, plus SME versions where proportionality matters.

The best time to prepare for cross-border incident coordination is before the 03:17 alert. The second-best time is today.

Start with a Clarysec readiness review, download the relevant policy toolkit, or request a walkthrough of how the Zenith Blueprint and Zenith Controls can help your ISMS produce the evidence that 2026 cyber resilience will demand.