Incident Severity Classification for DORA, NIS2 and GDPR

The 02:17 incident call that becomes a regulatory decision

At 02:17 on a Thursday morning, Sarah, the CISO of FinScale, sees the first alert: abnormal API traffic, failed authentication spikes and payment dashboard latency above 3000ms. Within minutes, customer support reports payment status errors. The cloud provider says there is no platform-wide incident. The SOC sees suspicious access tokens from two geographic regions. Product confirms the dashboard is back online after 19 minutes, but twelve customers have already opened tickets.

By 03:05, Sarah is on the crisis bridge with the incident commander, legal counsel, the privacy coordinator, the cloud operations lead and the executive sponsor. The technical question is clear enough: what happened to the API gateway? The regulatory questions are harder:

1. Is this a DORA major ICT-related incident?
2. Is it a NIS2 significant incident?
3. Is there a GDPR personal data breach that requires notification?
4. Can the organization prove how it reached those answers?

The wrong answer can create regulatory exposure. The slow answer can miss a reporting window. The undocumented answer can fail an ISO/IEC 27001:2022 audit months later.

This is the incident response challenge of 2026. Many organizations have an incident response plan, forensic procedures, privacy playbooks and crisis communication templates. Fewer have a defensible incident severity classification model that converts a noisy security event into a documented decision across DORA, NIS2, GDPR and ISO/IEC 27001:2022 evidence expectations.

The solution is not three separate triage processes. It is one governed severity model with separate regulatory overlays, measurable thresholds, escalation rules, decision logs and evidence collection requirements. In practical terms, incident severity should not be a label chosen under pressure. It should be a controlled business decision that survives scrutiny from regulators, auditors, board members, customers and the DPO.

Why incident severity classification is now a board-level control

Incident classification used to be mostly technical: malware severity, affected hosts, exploited vulnerabilities and whether data was exfiltrated. In 2026, it is also legal, financial, societal and contractual.

DORA makes digital operational resilience a governance obligation for financial entities. The management body is expected to define, approve, oversee and remain responsible for the ICT risk management framework. That includes ICT business continuity, response and recovery plans, major incident reporting channels, ICT third-party risk and lessons learned.

NIS2 raises the governance stakes for essential and important entities. Article 20 requires management bodies to approve cybersecurity risk-management measures, oversee implementation and follow training. It also links failures in risk management and incident reporting to serious supervisory consequences. For essential entities, maximum administrative fine baselines can reach at least EUR 10,000,000 or 2 percent of total worldwide annual turnover, whichever is higher. For important entities, the baseline is at least EUR 7,000,000 or 1.4 percent of turnover, whichever is higher.

GDPR adds a different lens. A personal data breach is not limited to confirmed public disclosure or stolen files. It includes accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. Controllers must assess the risk to individuals and demonstrate accountability for the decision to notify or not notify.

ISO/IEC 27001:2022 gives these obligations an evidence backbone. Clauses 4.1 to 4.4 require the organization to understand its context, interested-party requirements, scope, interfaces and dependencies. Clauses 5.1 to 5.3 require leadership commitment, policy, roles, responsibilities and reporting. Clauses 6.1.1 to 6.1.3 require risk-based planning, risk assessment, risk treatment and a Statement of Applicability. Clauses 8.1 to 8.3 require operational control, change control, retained evidence and reassessment when risk conditions change. ISO/IEC 27001:2022

When the incident call happens, the question should not be, “Who thinks this is critical?” It should be, “What do our approved criteria, legal triggers, evidence and escalation rules require us to do now?”

One event, three regulatory classification systems

DORA, NIS2 and GDPR do not use the same language for incidents. That is the core reason organizations struggle during the first hour.

DORA Article 17 requires financial entities to establish an ICT-related incident management process that detects, manages and notifies ICT incidents, records ICT-related incidents and significant cyber threats, addresses root causes, uses early warning indicators, categorises and classifies incidents, assigns roles, manages communications, escalates major incidents to senior management and restores secure operations.

DORA Article 18 requires classification using criteria such as affected clients, affected counterparties, transactions, duration, downtime, geographic spread, data loss affecting availability, authenticity, integrity or confidentiality, criticality of affected services and economic impact. DORA Article 19 requires reporting of major ICT-related incidents and client communication where financial interests are affected.

NIS2 Article 23 defines a significant incident as one that has caused or is capable of causing severe operational disruption or financial loss, or has affected or is capable of affecting others by causing considerable material or non-material damage. It requires an early warning within 24 hours of becoming aware of the significant incident, an incident notification within 72 hours, intermediate reports on request and a final report within one month of the incident notification. Where applicable, affected service recipients must also be informed about measures or remedies they can take.

GDPR asks a privacy-risk question. Did a breach of security cause destruction, loss, alteration, unauthorised disclosure of, or access to personal data? If yes, the controller must assess risk to the rights and freedoms of natural persons. If the breach is likely to result in a risk, the supervisory authority must generally be notified within 72 hours of awareness. If it is likely to result in a high risk, affected individuals may need to be informed without undue delay.

A single incident therefore needs simultaneous classification.

For financial entities, DORA is the sector-specific Union legal act for ICT risk management and incident-reporting obligations that overlap with NIS2. That does not make NIS2 irrelevant. It may still matter for cooperation, information flows, services outside the DORA perimeter, non-financial group entities, cloud services, managed services and customer contractual obligations. The severity model should record not only the outcome, but also the applicability logic.

Clarysec’s model: classify the event, not the emotion

Clarysec starts with ISO/IEC 27002:2022 control 5.25, assessment and decision on information security events, as the cross-compliance anchor. In Zenith Controls: The Cross-Compliance Guide Zenith Controls, this topic is mapped through the entry “Assessment and decision on information security events” for control 5.25, supported by “IS incident management planning and preparation” for control 5.24 and “Collection of evidence” for control 5.28.

The most important compliance moment is often not containment. It is the fork in the road where a security event becomes a regulatory incident, or where it is defensibly recorded as a lower-severity event.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint describes this moment in the Controls in Action phase, Step 23:

“Not every anomaly is a disaster. Not every alert signals compromise. In the real world, security teams and business units are inundated with noise, login attempts, log anomalies, minor policy violations, shadow IT activity. The real challenge isn’t just in detection, but in distinguishing the harmless from the harmful, and knowing what demands escalation.”

That sentence captures the operational problem. A SIEM alert does not automatically equal DORA major. A temporary outage does not automatically equal NIS2 significant. A suspicious database query does not automatically equal GDPR-notifiable. Each may become reportable depending on impact, scope, data, affected parties and evidence.

The Zenith Blueprint, Risk Management phase, Step 10, also recommends that impact definitions be tailored to business scale and regulatory exposure:

“When defining impact, it’s wise to relate levels to your specific business scale. For example, ‘Major financial impact = loss > $100k’ (adjust to your context). Also consider regulatory impact: for example, a data breach of personal data might automatically be ‘Major’ or ‘Severe’ due to GDPR fines and notification requirements, even if the direct financial loss is unclear.”

That is the design principle for 2026 incident severity classification: severity is business impact plus legal impact plus evidence confidence.

A practical incident severity taxonomy for DORA, NIS2 and GDPR

A defensible taxonomy should separate internal severity from regulatory classification. Internal severity drives response urgency, resource allocation and executive escalation. Regulatory classification drives notification, legal review and external communication.

The internal severity level is not the final regulatory answer. It is the operating mode. A SEV 3 event may become GDPR-notifiable after log review. A SEV 2 outage may not be a DORA major incident if impact thresholds are not met. A SEV 1 ransomware incident may trigger DORA, NIS2, GDPR, customer contracts and law enforcement coordination at the same time.

A more detailed classification matrix helps the team move from alert to action.

The model should be embedded in policy rather than left to the strongest voice on the bridge. The SME Incident Response Policy-sme Incident Response Policy-sme - SME, Governance Requirements, clause 5.3.1, states:

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

The same SME policy, Risk Treatment and Exceptions, clause 7.4.1, adds:

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

For larger organizations, the enterprise Incident Response Policy Incident Response Policy, Governance Requirements, clause 5.3, formalizes the same concept:

“Incident classification shall follow a tiered model:”

The policy language matters because regulators and auditors will ask whether classification criteria existed before the incident. A matrix invented after the fact is weak evidence. A matrix approved, trained, exercised and used consistently is defensible.

The decision log: the most important evidence artifact

When auditors, regulators or board members review an incident, they rarely ask only, “What happened?” They ask, “When did you know, who decided, based on what evidence, and why did you not notify earlier?”

That is why Clarysec recommends a severity decision log for every SEV 3 and above event, and for any event involving personal data, critical services, financial customers, managed services, cloud infrastructure or cross-border impact.

This maps directly to ISO/IEC 27001:2022. Clause 8.1 requires processes to be planned, implemented and controlled, with sufficient documented information retained to show they operated as planned. Clauses 8.2 and 8.3 require reassessment when significant changes occur and retention of risk treatment evidence. Annex A controls A.5.24 to A.5.28 provide the incident management spine: planning and preparation, event assessment and decision, response, learning from incidents and evidence collection.

The SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy-sme - SME, Enforcement and Compliance, clause 8.3.2, supports the GDPR side of the model:

“The Privacy Coordinator will determine the severity, initiate containment actions, and document the case”

Privacy assessment should not begin after the regulatory clock becomes uncomfortable. It belongs inside the triage workflow.

Hands-on example: classifying Sarah’s API incident

Return to FinScale. It is a B2B fintech platform using cloud infrastructure, an external fraud analytics provider and a managed security provider. It is a DORA-covered financial entity for some activities. It is also a digital service provider with NIS2-relevant operations in one Member State. It processes customer personal data as controller for account services and as processor for some enterprise clients.

At 02:17, abnormal API traffic is detected. At 02:35, the incident ticket is opened. At 03:00, Sarah completes initial triage with the incident commander.

First, the internal severity is set. The incident affected customer dashboard availability for 19 minutes, involved suspicious access tokens and touched a critical customer-facing function. It is classified as SEV 3 Moderate pending confirmation, with escalation to the incident commander, privacy coordinator, legal counsel and service owner.

Second, the DORA screen is completed. The team checks affected clients, counterparties, transactions, duration, downtime, geographic spread, data loss, criticality and economic impact. No failed or altered transactions are confirmed. Downtime is limited. No data loss is proven. However, because a critical financial service component and customer financial interests may be affected, the incident remains under DORA monitoring and may be reclassified.

Third, the NIS2 screen is recorded. The team notes that DORA is the primary sector-specific reporting regime for the covered financial entity obligations. It also checks whether the incident affects services or customers outside the DORA perimeter. No severe operational disruption or considerable damage is confirmed at this stage.

Fourth, the GDPR screen is started. The suspicious tokens may have allowed access to customer dashboard data. The privacy coordinator documents data categories, affected users, token scope, logs reviewed, whether data was viewed or exported, and safeguards such as token expiry and access controls.

By 04:20, log analysis shows two tokens were used to access dashboard metadata for 41 customers, including names, account IDs and transaction status, but no payment credentials or identity documents. The team updates the incident to SEV 2 Major because personal data confidentiality was affected and customer communication may be required. The DPO assesses GDPR risk to individuals. The DORA decision is revisited based on client impact, transaction impact and economic impact.

This is the practical value of the model. Initial classification is not a final legal conclusion. It is an evidence-driven decision that can be updated as facts develop.

Logging, monitoring and forensic evidence: the proof layer

A severity model without evidence is a meeting opinion. The 2026 expectation is that classification is supported by logs, monitoring, preserved artifacts and chain of custody.

The SME Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME, Enforcement and Compliance, clause 8.3.4, states:

“Breach investigations must be supported by adequate logs to meet the accountability principle under GDPR and DORA”

Forensic handling is equally important. The SME Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy-sme - SME, Governance Requirements, clause 5.3.1, requires:

“A simple chain-of-custody log (e.g., Excel file or template document) must be maintained for each incident.”

For enterprise environments, the Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy, Governance Requirements, clause 5.5, requires:

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

The Zenith Blueprint, Controls in Action phase, Step 23, explains why this matters for ISO/IEC 27002:2022 control 5.28:

“When an information security incident occurs, one of the most critical, yet often overlooked, elements of response is evidence. Not logs, not screenshots, not loose narratives, but properly preserved, chain-of-custody-respecting, tamper-resistant evidence.”

A practical evidence pack for a major or potentially reportable incident should include:

• Incident ticket and timeline
• Severity decision log and reclassification history
• SIEM alerts, EDR alerts, cloud logs and identity logs
• Data access logs and export logs
• Affected asset and service inventory entries
• Customer, transaction and geography impact assessment
• DORA, NIS2 and GDPR screening worksheet
• DPO or legal assessment
• Communications approvals and sent messages
• Chain-of-custody record
• Root-cause analysis
• Corrective actions and lessons learned

This evidence pack also supports ISO/IEC 27001:2022 Annex A controls A.8.15 logging, A.8.16 monitoring activities, A.5.28 collection of evidence, A.5.27 learning from information security incidents, A.5.31 legal, statutory, regulatory and contractual requirements, and A.5.34 privacy and protection of personally identifiable information.

Cross-compliance mapping: build once, answer many auditors

The strongest incident severity models are built once and mapped many times. Zenith Controls is designed as a cross-compliance compass for this work. For this topic, the core ISO/IEC 27002:2022 entries are 5.24 information security incident management planning and preparation, 5.25 assessment and decision on information security events, 5.26 response to information security incidents, 5.27 learning from information security incidents and 5.28 collection of evidence.

These controls tie naturally into the ISO/IEC 27001:2022 management system. Clauses 4, 5, 6 and 8 define scope, leadership, risk criteria, treatment and operational evidence. ISO/IEC 27002:2022 provides the control implementation language. ISO 22301-style business continuity thinking supports disruption thresholds, recovery priorities and crisis management. ISO/IEC 27035-style incident management practices support structured detection, reporting, assessment, response and learning. ISO/IEC 27701-style privacy governance supports personal data breach roles, controller and processor considerations, privacy evidence and accountability.

The same model maps to NIST Cybersecurity Framework 2.0. The GOVERN Function requires legal, regulatory, contractual, privacy and civil liberties obligations to be understood and managed. It also expects risk appetite, roles, authorities, policies and oversight to be defined. The DETECT, RESPOND and RECOVER Functions support triage, analysis, escalation, containment, restoration, communications and improvement.

The benefit is practical. When a DORA supervisor asks for major ICT-related incident rationale, a NIS2 authority asks about the 24-hour early warning decision, a DPA asks why a GDPR notification was or was not made, and an ISO auditor asks whether the ISMS operated as planned, the organization can answer from the same evidence set.

How auditors and regulators will test your model

An ISO/IEC 27001:2022 auditor will usually start with scope and legal requirements. They will ask whether DORA, NIS2, GDPR, customer contracts and ICT third-party obligations were identified as interested-party requirements. Then they will follow the trail into risk criteria, the Statement of Applicability, incident procedures, operational records and evidence retention. They want proof that the classification process was not invented during the incident.

A DORA supervisor or internal audit team will look for a lifecycle loop: incident management process, early warning indicators, classification criteria, major incident escalation, client communication, root cause, final impact figures, resilience testing and management body oversight. They will also ask whether ICT third-party dependencies were considered, especially where cloud, SaaS, managed security or outsourcing providers were involved.

A NIS2-focused auditor or authority will test whether the entity can identify significant incidents, meet staged timelines, communicate with affected service recipients and provide evidence of cross-border impact assessment. They will connect incident handling to Article 21 risk-management measures, including business continuity, crisis management, supply-chain security, access control, asset management and training.

A GDPR DPO or supervisory authority will examine whether the organization identified personal data, roles, data subjects, categories, affected systems, breach type and risk to individuals. They will test whether the controller can demonstrate accountability and whether processor notifications to controllers were timely and complete.

An ISACA or COBIT 2019-style auditor will focus on governance evidence. Who approved the severity taxonomy? Who owns the risk? What metrics are reported to management? How are exceptions handled? How are lessons learned converted into control improvements?

Common failure patterns in incident classification

The first failure is single-label thinking. Teams classify an event as high, medium or low, but never separately assess DORA, NIS2 and GDPR triggers. The result is a severity label that cannot explain a reporting decision.

The second failure is confirmed-breach bias. Teams wait for absolute proof of exfiltration before involving privacy or legal. GDPR breach assessment often begins with possible unauthorised access, loss, alteration or disclosure, not only confirmed publication of data.

The third failure is clock confusion. NIS2 and GDPR timelines depend on awareness and assessment. If the incident ticket does not capture awareness time, classification time and escalation time, the organization may struggle to prove timeliness.

The fourth failure is forensics after cleanup. Engineers rotate keys, rebuild hosts and delete temporary evidence before investigative posture is triggered. This can destroy proof needed for regulatory, contractual or legal review.

The fifth failure is supplier blindness. DORA, NIS2 and NIST CSF 2.0 all emphasize third-party and supply-chain risk. If a cloud provider, managed service provider, payment processor, identity provider or SaaS vendor is part of the incident chain, the classification model must include supplier impact and contractual notification obligations.

A Clarysec implementation checklist for 2026

To operationalize a defensible incident severity classification model, Clarysec recommends this sequence:

1. Confirm regulatory applicability across DORA, NIS2, GDPR, customer contracts and sector rules.
2. Update the ISMS scope and interested-party requirements under ISO/IEC 27001:2022.
3. Define internal severity levels with measurable thresholds for downtime, data, customers, geography, financial loss and criticality.
4. Add separate DORA, NIS2 and GDPR screening questions to the incident ticket workflow.
5. Define escalation triggers for the incident commander, DPO, legal, senior management and board.
6. Create a severity decision log template.
7. Link classification to evidence collection and chain-of-custody procedures.
8. Validate logging coverage for identity, cloud, application, database, network and supplier events.
9. Run tabletop exercises for DORA major incident, NIS2 significant incident and GDPR breach scenarios.
10. Feed lessons learned into risk treatment, the Statement of Applicability, training and resilience testing.

The Zenith Blueprint, Controls in Action phase, Step 16, reinforces the human side of this model: reports should be logged, triaged, escalated through the incident response plan, and even minor events should be tracked because trends reveal control weaknesses. It promotes a low-threshold reporting mindset: “When in doubt, report.”

That cultural point is critical. A severity model fails if employees delay reporting because they fear overreaction. The goal is fast reporting, disciplined triage and defensible classification.

Turn incident uncertainty into audit-ready evidence

In 2026, incident severity classification is no longer a SOC-only decision. It is a regulated governance process that must connect DORA major ICT-related incident criteria, NIS2 significant incident thresholds, GDPR breach risk and ISO/IEC 27001:2022 evidence.

The organizations that perform best during incidents will not be the ones with the thickest response binder. They will be the ones that can answer four questions quickly and prove every answer later:

• What happened?
• How severe is it?
• Which regulatory obligations may apply?
• What evidence supports the decision?

Clarysec helps organizations build that bridge through policy templates, severity taxonomies, decision logs, tabletop scenarios and cross-compliance mappings. Start with the incident policies, validate your risk criteria in Zenith Blueprint Zenith Blueprint, and use Zenith Controls Zenith Controls to map ISO/IEC 27002:2022 controls 5.24, 5.25, 5.26, 5.27 and 5.28 across DORA, NIS2, GDPR, NIST CSF and audit expectations.

If your team cannot answer “Is this DORA major, NIS2 significant or GDPR-notifiable?” within the first hour, the next step is not another generic incident response plan. The next step is a defensible incident severity classification operating model, tested before the next 02:17 call arrives.

Ready to replace panic with process? Download Clarysec’s incident response and evidence collection policy templates, review your current severity taxonomy against the Zenith Blueprint, or request a Clarysec readiness assessment to build an audit-ready DORA, NIS2, GDPR and ISO/IEC 27001 incident classification model.