DORA Incident Reporting and ISO 27001 Controls in 2026

It is 08:17 on a Tuesday morning in 2026. Sarah, the CISO of a European FinTech, sees a dashboard flashing amber, not red. A critical payment settlement platform is slowing down. Transactions are not fully failing, but they are taking three times longer than the service level agreement allows. The SOC sees unusual authentication attempts against an administrator account. The cloud infrastructure provider reports degraded service in one availability zone. Customer support starts receiving calls from corporate clients asking why payment files are delayed.

No one knows yet whether this is a cyberattack, an operational resilience failure, a supplier outage, a privacy incident, or all of them at once.

Sarah has a DORA problem before the technical facts are complete. Is this a major ICT-related incident? Does it affect a critical or important function? Has it crossed the internal severity threshold? Who needs to be notified, when, and with what evidence? If personal data is involved, has the GDPR notification clock also started? If a third-party ICT provider is part of the incident chain, who owns the facts?

This is where financial entities discover the gap between having an incident response plan and having an auditable DORA incident reporting operating model.

DORA incident reporting in 2026 requires more than fast escalation. It requires a defensible chain from detection to classification, from classification to supervisory reporting, from reporting to remediation, and from remediation to lessons learned. ISO/IEC 27001:2022 provides the management system structure. ISO/IEC 27002:2022 Annex A controls provide the practical control expectations. Clarysec’s policies, 30-step roadmap, and cross-compliance guide turn those expectations into evidence-ready implementation.

Why DORA Incident Reporting Fails Under Pressure

Most DORA incident reporting failures do not begin with negligence. They begin with ambiguity.

A security analyst sees an alert but does not know whether it qualifies as an ICT-related incident under DORA. The IT service manager treats degraded performance as a technical service issue, while Compliance treats it as a regulatory event. Legal waits for confirmation before escalating. The business owner cannot yet quantify client impact. The CISO wants evidence, but the relevant logs are spread across cloud services, endpoints, identity systems, the SIEM, and supplier platforms.

By the time the organization agrees on classification, the reporting window is already under pressure.

DORA Articles 17 to 21 create a structured expectation for ICT-related incident management, classification, reporting, reporting content, and supervisory handling. For financial entities, the practical requirement is clear: monitor, manage, log, classify, report, update, and learn from ICT-related incidents in a way that can be reconstructed later.

Clarysec’s Incident Response Policy [IRP] embeds DORA directly into the reference framework:

EU DORA (2022/2554): Article 17: ICT incident reporting requirements for financial institutions to competent authorities.

The same policy connects incident management to ISO/IEC 27002:2022 Controls 5.25 to 5.27, covering responsibilities for incident assessment, response, communication, and improvement.

For smaller financial technology firms and lean regulated entities, Clarysec’s Incident Response Policy - SME [IRP-SME] makes the obligation practical by emphasizing that DORA requires financial entities to classify, report, and track ICT-related incidents and disruptions.

That phrase matters. DORA compliance is not only a reporting template. The organization must classify, report, and track. That means evidence of the initial event, decision criteria, severity level, reporting decision, communications, recovery actions, supplier involvement, and follow-up.

ISO/IEC 27001:2022 as the DORA Incident Command Center

A mature ISO/IEC 27001:2022 Information Security Management System should not become another compliance silo next to DORA. It should become the command center for DORA incident reporting.

The ISMS already requires risk ownership, control selection, internal audit, management review, documented information, continual improvement, and evidence of control operation. DORA adds sector-specific reporting pressure, but ISO/IEC 27001:2022 gives the governance structure for making the process repeatable.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap [ZB] reinforces this integration in Step 13, Risk Treatment Planning and Statement of Applicability. The Blueprint recommends mapping controls to risks and clauses for traceability, including adding an Annex A control reference to risks and noting when controls support GDPR, NIS2, or DORA.

For Sarah’s payment settlement incident, the risk register entry might be:

“Disruption or compromise of payment processing platform.”

The mapped ISO/IEC 27001:2022 Annex A controls would include 5.24, 5.25, 5.26, 5.27, 5.28, 6.8, 8.15, and 8.16, with a DORA note for major ICT-related incident classification and reporting.

Clarysec’s Zenith Controls: The Cross-Compliance Guide [ZC] then acts as the cross-compliance compass. In Zenith Controls, Clarysec maps ISO/IEC 27002:2022 controls to other ISO/IEC 27001:2022 controls, related standards, audit expectations, and regulations such as DORA, GDPR, and NIS2. It does not create separate “Zenith controls.” It shows how the existing ISO controls operate together and how they are tested.

The DORA reporting workflow can be viewed as a control chain:

You cannot report what you did not detect. You cannot classify what you did not assess. You cannot justify a reporting decision without records. You cannot improve without a post-incident review.

Control 6.8: The DORA Clock Starts With People

In Sarah’s scenario, the first useful signal may not come from the SOC. It may come from a relationship manager hearing client complaints, a finance user seeing failed settlement batches, or an engineer noticing abnormal latency.

That is why ISO/IEC 27001:2022 Annex A control 6.8, Information security event reporting, is essential for DORA. It makes reporting a workforce responsibility, not only a security operations function.

In the Zenith Blueprint, Step 16, People Controls II, Clarysec states:

An effective incident response system begins not with tools, but with people.

Step 16 recommends clear reporting channels, awareness training, a blame-free culture, triage, confidentiality, and periodic simulations. The most useful practical message is simple:

“When in doubt, report.”

That is a DORA control principle. If employees wait until they are certain, the organization loses time. If they report early, the organization can assess, classify, and decide.

In Zenith Controls, 6.8 is mapped as a detective control supporting confidentiality, integrity, and availability. It connects to 5.24 because reporting channels must be part of the incident plan. It feeds 5.25 because events can only be assessed if they are reported. It triggers 5.26 because formal response starts after reports are evaluated.

For DORA, this supports Articles 17 and 18, where financial entities must manage, classify, and report major ICT-related incidents and significant cyber threats. It also supports GDPR Article 33 and Recital 85, because internal reporting determines how quickly a personal data breach is identified and escalated.

A practical Clarysec implementation is a one-page “How to Report an ICT Incident” instruction sheet. It should include:

• What to report, including outages, suspicious emails, lost devices, unusual system behavior, suspected supplier compromise, unauthorized access, data leakage, and client-impacting service degradation.
• How to report, using a monitored mailbox, ticket category, hotline, collaboration channel, or SOC portal.
• What to include, such as time, system, user, business process, observed impact, screenshots if safe, and whether clients or personal data may be affected.
• What not to do, including not deleting logs, not rebooting critical systems unless instructed, not contacting clients externally without approval, and not investigating beyond role.
• What happens next, including triage, classification, escalation, response, evidence preservation, and possible regulatory assessment.

The objective is not to turn every employee into an investigator. It is to make every employee a reliable signal source.

Control 5.25: The DORA Classification Decision Point

DORA major ICT-related incident reporting hinges on classification. This is where ISO/IEC 27001:2022 Annex A control 5.25, Assessment and decision on information security events, becomes central.

The Zenith Blueprint, Step 23, explains the practical challenge:

Not every anomaly is a disaster. Not every alert signals compromise.

It then describes the purpose of 5.25 as:

distinguishing the harmless from the harmful, and knowing what demands escalation.

For DORA, this is the moment when a security event, service degradation, supplier outage, data exposure, or operational disruption is assessed against major incident criteria. The organization must consider operational impact, affected services, critical or important functions, clients and transactions affected, duration, geographic spread, data impact, reputational implications, and economic impact.

In Zenith Controls, 5.25 is mapped directly to DORA Article 18, Major ICT Incident Classification. It is the structured evaluation process for determining whether an observed event qualifies as a security incident. It also connects to 8.16, Monitoring activities, because alerts and log data must be triaged, and to 5.26, because classification triggers response.

This is where many organizations fail audits. They have tickets, but not classification records. They have severity labels, but not criteria. They have regulatory reports, but not the decision trail proving why an incident was or was not considered major.

Clarysec addresses this by embedding DORA classification into the incident severity model. In the enterprise Incident Response Policy, clause 5.3.1 includes a clear Tier 1 example:

Tier 1: Critical (e.g., confirmed data breach, ransomware outbreak, production system compromise)

For smaller organizations, the Incident Response Policy - SME adds a tight operational expectation:

The General Manager, with input from the IT provider, must classify all incidents by severity within one hour of notification.

That one-hour classification target is powerful because it forces governance discipline. A smaller regulated entity may not have a 24/7 SOC, but it can still define who classifies, who advises, and how quickly the decision must happen.

A DORA-to-ISO Incident Triage Record

To make the classification defensible, create a DORA incident triage record in your ticketing, GRC, or incident management system. The record should be created for every potentially material ICT event, even if it is later downgraded.

Add a decision note:

“Based on payment service disruption affecting a critical business process, unresolved root cause, and potential client impact, the event is escalated as a potential major ICT-related incident. Compliance and Legal to assess regulatory notification requirements. Evidence preservation initiated.”

This single record supports DORA Article 17 tracking, Article 18 classification, Article 19 reporting decisions, ISO/IEC 27001:2022 Annex A 5.25 assessment, 6.8 reporting, 5.26 response, and 5.28 evidence handling.

Controls 5.24 and 5.26: Planning, Roles, and Response

When a DORA incident happens, the response plan must already answer uncomfortable questions.

Who has authority to classify? Who contacts the competent authority? Who approves the initial notification? Who communicates with clients? Who contacts the ICT third-party provider? Who decides whether the incident also triggers GDPR notification? Who preserves evidence? Who owns the final report?

ISO/IEC 27001:2022 Annex A control 5.24, Information security incident management planning and preparation, answers those questions before the crisis. Control 5.26, Response to information security incidents, ensures the plan turns into controlled action during the incident.

In Zenith Controls, 5.24 is tied to DORA Articles 17 to 21 because it operationalizes documented, tested, and reviewed incident response, including internal escalation, external regulatory notification, stakeholder communication, and lessons learned.

ISO/IEC 27035-1:2023 supports this by expanding incident management beyond response procedures into policy, planning, capabilities, relationships, support mechanisms, awareness, training, and regular testing. ISO/IEC 27035-2:2023 further details the incident management process from preparation through lessons learned.

The Zenith Blueprint, Step 23, gives a direct implementation instruction:

Ensure you have an up-to-date incident response plan (5.24), covering preparation, escalation, response, and communication.

A DORA-ready incident response plan should define:

• The ICT incident response team and alternates.
• Authority for severity classification and DORA reporting escalation.
• Legal, Compliance, Privacy, Communications, IT, Security, supplier, and business owner responsibilities.
• Criteria for major ICT-related incident classification.
• Procedures for initial, intermediate, and final regulatory reporting.
• GDPR, NIS2, contractual, cyber insurance, and board notification assessment.
• Containment, eradication, recovery, and validation steps.
• Evidence preservation requirements.
• Supplier escalation and log access procedures.
• Lessons learned and corrective action tracking.

The Incident Response Policy - SME also connects response timelines to legal requirements:

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.

This is vital because a single ICT incident can become a DORA major incident, a GDPR personal data breach, a NIS2 significant incident, a contractual client notification event, and a supplier management issue. The plan must coordinate those overlays instead of treating them as separate worlds.

Controls 8.15 and 8.16: Logs Make the Report Defensible

DORA incident reporting depends on facts. Facts depend on logging and monitoring.

In the payment settlement scenario, Sarah needs to know when the degradation started, which systems were affected, whether privileged accounts were used, whether data left the environment, whether the cloud provider’s outage aligns with internal telemetry, and when recovery was complete.

ISO/IEC 27001:2022 Annex A control 8.15, Logging, and 8.16, Monitoring activities, support this evidence base. In Zenith Controls, both connect to 5.24 because incident response planning must include usable log data and monitoring capability. Control 8.16 also connects to 5.25 because alerts must be triaged into decisions.

Clarysec’s Logging and Monitoring Policy - SME [LMP-SME] includes a practical escalation requirement:

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

For DORA-regulated entities, potentially major ICT incidents usually require a faster operational escalation model, especially where critical or important functions are affected. Still, the governance pattern is correct: high-priority alerts cannot remain inside IT. They must reach business, privacy, and management roles.

A DORA-ready logging model should include:

• Centralized logging for critical systems, identity platforms, endpoints, cloud services, network security tools, and business applications.
• Time synchronization across systems so incident timelines are reliable.
• Alert categorization aligned to incident severity and DORA classification.
• Log retention aligned to regulatory, contractual, and forensic needs.
• Access controls that protect log integrity.
• Procedures for capturing log snapshots during major incidents.
• Supplier log access requirements for critical ICT services.

Auditors will not accept “the SIEM has it” as sufficient evidence. They will ask whether the right logs existed, whether alerts were reviewed, whether escalation happened on time, and whether logs were preserved once the incident became potentially reportable.

Control 5.28: Evidence Collection and Chain of Custody

In a major ICT-related incident, evidence serves three purposes: technical investigation, regulatory accountability, and legal defensibility.

If evidence is incomplete, overwritten, altered, or undocumented, the organization may struggle to prove what happened. It may also struggle to justify its classification decision.

Clarysec’s Evidence Collection and Forensics Policy [ECF] states:

A chain-of-custody log shall accompany all physical or digital evidence from the time of acquisition through archival or transfer and shall document:

The SME version, Evidence Collection and Forensics Policy - SME [ECF-SME], keeps the requirement simple:

Each item of digital evidence must be logged with:

The operational lesson is direct. Evidence handling cannot begin after Legal asks for it. It must be embedded into incident response.

ISO/IEC 27006-1:2024 reinforces this audit expectation by emphasizing procedures to identify, collect, and preserve evidence from information security incidents. For DORA, the same evidence set may support the initial notification, intermediate updates, final report, post-incident review, and supervisory questions.

A practical evidence checklist for DORA-related incidents should include:

• Incident ticket and triage notes.
• Timeline of detection, escalation, classification, reporting, containment, recovery, and closure.
• SIEM alerts and correlated logs.
• Endpoint and server artifacts.
• Identity and privileged access logs.
• Network traffic summaries.
• Cloud provider status and audit logs.
• Supplier communications and incident statements.
• Business impact records, including clients, services, transactions, and downtime.
• Regulatory notification drafts and submissions.
• Management decisions and approvals.
• Root cause analysis.
• Lessons learned and corrective actions.

The evidence must show both technical facts and governance decisions. DORA reporting is not only about what happened to systems. It is also about how management recognized, assessed, escalated, controlled, and improved from the incident.

Control 5.27: Lessons Learned and Continual Improvement

A DORA incident is not closed when the final report is submitted. It is closed when the organization has learned from it, assigned corrective actions, updated controls, and verified improvement.

ISO/IEC 27001:2022 Annex A control 5.27, Learning from information security incidents, connects DORA reporting to the ISO/IEC 27001:2022 continual improvement cycle. In Zenith Controls, 5.24 is linked to 5.27 because incident management is incomplete without root cause analysis, lessons learned, and control improvement.

The Zenith Blueprint, Step 23, instructs organizations to update the plan with lessons learned and provide targeted training on incident response and evidence handling. This is especially important for DORA because recurring classification delays, missing supplier evidence, weak logs, or unclear communications can become supervisory concerns.

A lessons learned template should capture:

• What happened and when.
• Which critical or important functions were affected.
• Whether classification was timely and accurate.
• Whether DORA reporting decisions were made with sufficient evidence.
• Whether GDPR, NIS2, contractual, or client notification triggers were assessed.
• Whether suppliers responded within agreed timelines.
• Whether logs and forensic evidence were preserved.
• Which controls failed or were missing.
• Which policies, playbooks, training, or technical controls must be improved.
• Who owns each corrective action and by when.

This also feeds ISO/IEC 27001:2022 management review. Incident trends should be reviewed by leadership, not buried in technical postmortems.

Cross-Compliance: DORA, GDPR, NIS2, NIST, and COBIT 2019

DORA is the headline for financial entities, but incident reporting rarely belongs to only one framework.

A single ICT incident may involve DORA major ICT-related incident reporting, GDPR personal data breach notification, NIS2 significant incident reporting, customer contract obligations, cyber insurance notification, and board reporting.

Zenith Controls helps reduce this complexity by mapping ISO/IEC 27002:2022 controls across frameworks. For example:

From a NIST perspective, the same model supports Detect, Respond, and Recover outcomes. From a COBIT 2019 and ISACA audit perspective, the concern is governance: whether incident management, continuity, risk, compliance, supplier responsibilities, and performance monitoring are controlled.

The most mature organizations do not create separate workflows for every framework. They create one incident management process with regulatory overlays. The ticket captures the same core facts once, then branches into DORA, GDPR, NIS2, contractual, insurance, or sector-specific reporting when required.

How Auditors Will Test Your DORA Incident Process

A DORA-ready incident reporting process must survive different audit lenses.

An ISO/IEC 27001:2022 auditor will examine whether the ISMS has selected and implemented relevant Annex A controls, whether the Statement of Applicability supports those controls, whether incident records exist, and whether internal audit and management review include incident performance.

Zenith Controls cites ISO/IEC 19011:2018 audit methodology for 5.24, 5.25, and 6.8. For 5.24, auditors examine the incident response plan for incident types, severity classifications, assigned roles, contact lists, escalation paths, regulatory reporting instructions, and communication responsibilities. For 5.25, they examine whether documented classification criteria exist, such as severity matrices or decision trees based on system impact, data sensitivity, and duration. For 6.8, they assess reporting mechanisms, time-to-report metrics, and evidence that reported events are logged, triaged, and resolved.

A DORA supervisory review will focus on whether major ICT-related incidents are detected, classified, reported, updated, and closed according to regulatory expectations. The reviewer may ask for a sample incident and trace it from first alert to final report.

A privacy auditor will focus on whether personal data breach risk was assessed and whether GDPR Article 33 and Article 34 obligations were triggered. BS EN 17926:2023 is relevant here because it adds privacy incident responsibilities, notification criteria, timing, and alignment with supervisory disclosure expectations.

The same evidence can satisfy multiple audit questions if it is structured correctly from the beginning.

DORA Incident Reporting Readiness Checklist for 2026

Before your next tabletop exercise, internal audit, or supervisory review, test your organization against this checklist:

• Do employees know how to report suspected ICT incidents?
• Is there a dedicated incident reporting channel?
• Are security events logged and triaged consistently?
• Is there a documented severity and DORA major incident classification matrix?
• Is classification required within a defined time after notification?
• Are critical or important functions mapped to systems and suppliers?
• Are DORA, GDPR, NIS2, contractual, insurance, and client notification triggers assessed in one workflow?
• Are incident roles defined across IT, Security, Legal, Compliance, Privacy, Communications, and business owners?
• Are logs sufficient to reconstruct incident timelines?
• Is evidence preserved with chain of custody?
• Are supplier incident obligations and log access rights tested?
• Are tabletop exercises performed using realistic DORA scenarios?
• Are lessons learned tracked to corrective actions?
• Are incident metrics reviewed in management review?
• Is the Statement of Applicability mapped to DORA-relevant ISO/IEC 27001:2022 controls?

If the answer to any of these is “partially,” the issue is not only compliance. It is operational resilience.

Build an Evidence-Ready DORA Incident Reporting Model

DORA incident reporting in 2026 is a test of governance under pressure. The organizations that perform well will not be the ones with the longest incident response documents. They will be the ones with clear reporting channels, fast classification, reliable logs, preserved evidence, trained people, tested supplier escalation, and cross-framework traceability.

Clarysec can help you build that operating model.

Start by mapping your incident risks and Statement of Applicability using the Zenith Blueprint: An Auditor’s 30-Step Roadmap. Then align your incident controls with Zenith Controls: The Cross-Compliance Guide. Operationalize the process with Clarysec’s Incident Response Policy, Incident Response Policy - SME, Logging and Monitoring Policy - SME, Evidence Collection and Forensics Policy, and Evidence Collection and Forensics Policy - SME.

If your leadership team wants confidence before the next real incident, run a DORA major ICT-related incident tabletop with Clarysec’s toolkit and produce the evidence pack an auditor or supervisor would expect to see.