DORA Art.17-18: ICT Incident Management Process, Classification, and Materiality Thresholds — Developer Guide 2026

Post #501 in the sota.io EU Cyber Compliance Series

DORA Chapter III is the operational heart of the regulation for engineering teams. Where Chapter II (Art.5–14) builds the ICT risk management framework, Chapter III converts that framework into a live operational process: detect, manage, classify, report. Articles 17 and 18 define the first two steps — the incident management process and the classification decision that determines regulatory consequence.

The stakes are direct. Get classification wrong and you either miss the four-hour initial notification deadline under Art.19 (enforcement exposure) or you over-report routine incidents and attract supervisory scrutiny of your classification methodology. Art.17 and Art.18 together define how your engineering team should think about incidents before calling the legal or compliance team.

1. Scope: Who Must Comply with DORA Art.17-18

Both articles apply to the same DORA scope as the rest of Chapter III — approximately 22,000 EU financial entities under Art.2(1):

Microenterprise note (Art.4(2)): Even the smallest DORA-scoped entities must maintain some documented incident management process. "Proportionate" means lighter documentation, not absence of documentation.

2. Art.17: ICT-Related Incident Management Process

The Core Obligation

Art.17(1) requires financial entities to define, establish, and implement an ICT-related incident management process that covers the full lifecycle: detection through post-incident review.

Art.17(2) specifies six mandatory components of that process:

What Art.17 Does NOT Specify

Art.17 defines what the process must cover, not how to implement it. The process can live in a runbook, an incident management platform (PagerDuty, OpsGenie, ServiceNow), or a documented SOP. What NCAs audit is:

1. Whether the process is documented and approved at a governance level
2. Whether it was followed in the last major incident (audit trail)
3. Whether roles are named, not just described abstractly
4. Whether post-incident review conclusions fed back into the process

The Art.17 × Art.13 Loop

Art.13 (learning and evolving) requires that post-incident reviews from major incidents update the ICT risk management framework. Art.17 closes this loop at the incident level: the incident management process must include root cause analysis, and Art.13 requires those root causes to inform risk identification under Art.6. In practice, this means:

• Every major incident → blameless post-mortem → written report
• Report feeds into Art.6 risk register update
• Next quarterly review of ICT risk management framework references the updated register

3. Art.18: Classification of ICT-Related Incidents

The Six Classification Criteria

Art.18(1) requires financial entities to classify ICT-related incidents as major or non-major using criteria set out in Art.18(1) and further specified in Commission Delegated Regulation 2024/1772 (RTS on incident classification, published February 2024).

The six mandatory criteria:

Important: Meeting any one of the six criteria is sufficient to classify an incident as major. The criteria are not cumulative — a single criterion exceeded triggers major classification and Art.19 reporting.

RTS Thresholds in Detail

Commission Delegated Regulation 2024/1772 specifies the quantitative thresholds. Key thresholds for engineering teams:

Clients affected:

• Payment service providers: ≥500 clients OR ≥10% of active client base (whichever is lower)
• Other financial entities: ≥100 clients OR ≥10% of active client base (whichever is lower)
• "Active client" = client with at least one transaction in the previous 12 months

Service downtime:

• Payment services: incident lasting ≥2 hours triggers major classification
• Non-payment financial services: ≥4 hours
• Clock starts from first confirmed detection, not from when the on-call engineer acknowledges the alert

Economic impact:

• Direct costs ≥€100,000 within 24 hours of incident start, OR
• ≥1% of the entity's annual ICT budget (whichever is higher for larger entities)
• Direct costs include: incident response labour, external forensics, regulatory fines, client compensation

Data integrity:

• Any loss of client financial data, trading records, or payment instructions qualifies
• GDPR Art.33 notification trigger automatically implies major ICT incident under DORA

Art.18(2): Cyber-Attacks as Automatic Major Incidents

Art.18(2) adds a mandatory classification override: cyber-attacks that disrupt critical services are automatically classified as major incidents, regardless of whether the six criteria thresholds are met. "Critical service" follows the definition in Art.6 — services whose interruption would materially harm financial stability or client protection.

Engineering implication: if your incident detection identifies a deliberate cyber-attack (ransomware, DDoS, data exfiltration) affecting any production system that processes client transactions or data, classify as major immediately and start the Art.19 clock.

Art.18(3): Significant Cyber Threats

Art.18(3) introduces a forward-looking obligation: financial entities must notify their NCA of significant cyber threats — threats that have not yet caused an incident but could, given the entity's profile. This is distinct from incident reporting:

NCAs have used Art.18(3) to develop threat intelligence picture across sectors. Entities that proactively report significant threats are generally treated more favourably in post-incident enforcement than those who only report after harm occurs.

4. The Classification Decision Tree

How Art.17 and Art.18 work together in a live incident:

INCIDENT DETECTED (Art.17 process triggers)
           │
           ▼
Is this a deliberate cyber-attack? ──YES──► MAJOR (Art.18(2))
           │                                  │
           NO                                 ▼
           │                        Start Art.19 clock (t=0)
           ▼
Apply the 6 criteria (Art.18(1)):
  ┌─────────────────────────────────────┐
  │ (1) Clients affected ≥ threshold?   │
  │ (2) Duration ≥ 2h/4h?               │ ──ANY YES──► MAJOR
  │ (3) Geographic spread ≥2 MS?        │
  │ (4) Data loss (integrity/conf/avail)?│
  │ (5) Reputational impact?            │
  │ (6) Economic impact ≥ threshold?    │
  └─────────────────────────────────────┘
           │
           ALL NO
           │
           ▼
     NON-MAJOR INCIDENT
  (Document per Art.17 process;
   no Art.19 reporting obligation;
   review for Art.13 if significant)

5. Python Implementation: IncidentClassifier

from dataclasses import dataclass, field
from enum import Enum
from datetime import datetime, timedelta
from typing import Optional

class IncidentSeverity(str, Enum):
    ROUTINE = "routine"
    SIGNIFICANT = "significant"
    MAJOR = "major"
    CRITICAL = "critical"  # cyber-attack on critical service (Art.18(2))

class EntityType(str, Enum):
    PAYMENT_SERVICE_PROVIDER = "psp"
    OTHER_FINANCIAL_ENTITY = "other_fe"

@dataclass
class IncidentContext:
    incident_id: str
    entity_type: EntityType
    active_client_base: int
    annual_ict_budget_eur: float
    detected_at: datetime
    
    # Art.18(1) criteria values
    clients_affected: int = 0
    duration_hours: float = 0.0
    member_states_affected: int = 1
    data_loss_occurred: bool = False  # integrity/confidentiality/availability
    gdpr_art33_trigger: bool = False  # automatic data loss indicator
    reputational_media_coverage: bool = False
    direct_costs_eur: float = 0.0
    
    # Art.18(2) cyber-attack flag
    is_deliberate_cyber_attack: bool = False
    affects_critical_service: bool = False
    
    # Internal tracking
    classification_reasons: list = field(default_factory=list)

class DORAIncidentClassifier:
    """DORA Art.17-18 incident classification per Commission Delegated Reg 2024/1772."""
    
    def classify(self, ctx: IncidentContext) -> IncidentSeverity:
        ctx.classification_reasons.clear()
        
        # Art.18(2): cyber-attack on critical service → automatic CRITICAL
        if ctx.is_deliberate_cyber_attack and ctx.affects_critical_service:
            ctx.classification_reasons.append(
                "Art.18(2): Deliberate cyber-attack affecting critical service"
            )
            return IncidentSeverity.CRITICAL
        
        # Art.18(1): check six criteria
        major_triggers = []
        
        # Criterion 1: Clients affected
        client_threshold = self._client_threshold(ctx)
        if ctx.clients_affected >= client_threshold:
            major_triggers.append(
                f"Art.18(1)(a): {ctx.clients_affected} clients affected "
                f"(threshold: {client_threshold})"
            )
        
        # Criterion 2: Duration
        duration_threshold = 2.0 if ctx.entity_type == EntityType.PAYMENT_SERVICE_PROVIDER else 4.0
        if ctx.duration_hours >= duration_threshold:
            major_triggers.append(
                f"Art.18(1)(b): {ctx.duration_hours}h duration "
                f"(threshold: {duration_threshold}h)"
            )
        
        # Criterion 3: Geographic spread
        if ctx.member_states_affected >= 2:
            major_triggers.append(
                f"Art.18(1)(c): {ctx.member_states_affected} EU member states affected"
            )
        
        # Criterion 4: Data losses
        if ctx.data_loss_occurred or ctx.gdpr_art33_trigger:
            reason = "Art.18(1)(d): Data loss (integrity/confidentiality/availability)"
            if ctx.gdpr_art33_trigger:
                reason += " + GDPR Art.33 notification trigger"
            major_triggers.append(reason)
        
        # Criterion 5: Reputational impact (qualitative)
        if ctx.reputational_media_coverage:
            major_triggers.append("Art.18(1)(e): Reputational impact — media coverage")
        
        # Criterion 6: Economic impact
        economic_threshold = max(100_000, ctx.annual_ict_budget_eur * 0.01)
        if ctx.direct_costs_eur >= economic_threshold:
            major_triggers.append(
                f"Art.18(1)(f): Economic impact €{ctx.direct_costs_eur:,.0f} "
                f"(threshold: €{economic_threshold:,.0f})"
            )
        
        if major_triggers:
            ctx.classification_reasons.extend(major_triggers)
            # Cyber-attack without critical service = still MAJOR (Art.18(2) partial)
            if ctx.is_deliberate_cyber_attack:
                return IncidentSeverity.CRITICAL
            return IncidentSeverity.MAJOR
        
        return IncidentSeverity.SIGNIFICANT if ctx.duration_hours > 0 else IncidentSeverity.ROUTINE
    
    def _client_threshold(self, ctx: IncidentContext) -> int:
        """Per RTS 2024/1772: lower of absolute threshold or 10% of active client base."""
        percentage_threshold = int(ctx.active_client_base * 0.10)
        if ctx.entity_type == EntityType.PAYMENT_SERVICE_PROVIDER:
            return min(500, percentage_threshold)
        else:
            return min(100, percentage_threshold)
    
    def reporting_deadline(self, ctx: IncidentContext, severity: IncidentSeverity) -> dict:
        """Art.19 deadlines given classification."""
        if severity not in (IncidentSeverity.MAJOR, IncidentSeverity.CRITICAL):
            return {"required": False, "reason": "Non-major incident — no Art.19 obligation"}
        
        t0 = ctx.detected_at
        return {
            "required": True,
            "initial_notification": t0 + timedelta(hours=4),   # Art.19(3)(a)
            "intermediate_report": t0 + timedelta(hours=72),    # Art.19(3)(b)
            "final_report": t0 + timedelta(days=30),            # Art.19(4)
        }

# Usage
classifier = DORAIncidentClassifier()

incident = IncidentContext(
    incident_id="INC-2026-042",
    entity_type=EntityType.PAYMENT_SERVICE_PROVIDER,
    active_client_base=8_000,
    annual_ict_budget_eur=2_000_000,
    detected_at=datetime(2026, 4, 21, 9, 15),
    clients_affected=850,     # >500 threshold for PSP
    duration_hours=3.5,       # >2h threshold for PSP
    member_states_affected=1,
    data_loss_occurred=False,
    direct_costs_eur=45_000,
)

severity = classifier.classify(incident)
deadlines = classifier.reporting_deadline(incident, severity)

print(f"Classification: {severity.value}")
for reason in incident.classification_reasons:
    print(f"  → {reason}")
print(f"Initial notification due: {deadlines.get('initial_notification')}")

Output:

Classification: major
  → Art.18(1)(a): 850 clients affected (threshold: 500)
  → Art.18(1)(b): 3.5h duration (threshold: 2.0h)
Initial notification due: 2026-04-21 13:15:00

6. Common Classification Errors and NCA Audit Focus

Error 1: Starting the Clock from Acknowledgement, Not Detection

The Art.19 four-hour clock starts at first confirmed detection — when the SIEM alert fires or the anomaly is first logged — not when the on-call engineer accepts the PagerDuty notification. Entities that start the clock at human acknowledgement systematically underreport their initial notification latency.

Fix: Your incident management process (Art.17) must define detection as the automated trigger point, and your SIEM logs must provide an auditable timestamp.

Error 2: Treating "Clients Affected" as Active Users, Not Client Records

"Clients affected" in the RTS means clients whose service access or data was impaired — not clients who actively attempted to use the service during the incident. A payment processing outage that lasted four hours affects every client with a pending transaction or scheduled payment in that window, not just those who tried to make a payment.

Error 3: Missing the Geographic Spread Criterion for Cloud-Hosted Services

Multi-region cloud deployments can create multi-member-state impacts that on-premise entities rarely face. If your EU infrastructure spans Frankfurt and Amsterdam and both AZs are affected, you have multi-member-state geographic spread regardless of where your registered office is.

Error 4: Forgetting That GDPR Art.33 Auto-Triggers DORA Major Classification

A personal data breach that reaches the GDPR Art.33 notification threshold (72 hours to supervisory authority) automatically satisfies DORA Art.18(1)(d). Entities with separate GDPR and DORA response teams who don't cross-notify are a common NCA finding.

Fix: Your Art.17 incident management process must include a step that checks: "Does this incident involve personal data loss? If yes, classify as DORA major regardless of other criteria."

Error 5: Not Documenting Non-Major Classification Decisions

NCAs don't only audit major incidents. They audit the methodology by which incidents were classified as non-major. Entities that cannot produce a documented classification decision (even a brief log entry with criteria checked) are non-compliant with Art.17's requirement for a defined classification process.

7. Art.17-18 × Art.19 Workflow in Practice

t=0    Incident detected (SIEM alert / anomaly detection)
       │
       ├─► Art.17: Incident management process activates
       │   └─ On-call engineer paged; incident record created
       │
       ├─► Art.18: Classification assessment begins
       │   └─ Six criteria evaluated against RTS thresholds
       │
       │   [If MAJOR/CRITICAL]
       ├─► Art.19(3)(a): Initial notification to NCA
t+4h  │   └─ Subject matter, estimated clients affected, estimated financial impact
       │
       ├─► Containment and recovery actions (Art.17(2)(e))
       │
t+72h ├─► Art.19(3)(b): Intermediate report
       │   └─ Root cause identification, financial impact update, recovery status
       │
t+30d └─► Art.19(4): Final report
           └─ Full root cause analysis, lessons learned, Art.13 feed-in

8. NCA Audit Checklist — 25 Items

Art.17: ICT Incident Management Process

• 1. ICT incident management process is documented in a named policy/procedure document
• 2. The document has a version number, owner, and approval date at governance level
• 3. Detection procedures specify automated alert thresholds (not just human judgment)
• 4. The incident log captures automated detection timestamp (Art.19 clock start)
• 5. Classification criteria reference Art.18 and RTS 2024/1772 thresholds
• 6. Named communication roles are defined (specific job titles or teams, not "senior management")
• 7. Escalation chain covers 24/7 (weekends, holidays) with named deputies
• 8. Business impact assessment occurs at defined intervals (t+1h, t+4h, t+24h)
• 9. Containment and recovery procedures exist per service category
• 10. Root cause analysis is mandatory for major incidents with defined output format
• 11. Post-incident review findings are formally recorded and tracked to closure
• 12. Art.13 loop: post-incident findings feed into Art.6 risk register updates

Art.18: Classification

• 13. Classification matrix references all six Art.18(1) criteria
• 14. RTS thresholds are documented for your entity type (PSP vs. other FE)
• 15. Client threshold reflects active client base and is updated annually
• 16. "Detection timestamp" (not acknowledgement timestamp) is the classification clock start
• 17. Cyber-attack override (Art.18(2)) is documented as a classification trigger
• 18. GDPR Art.33 trigger automatically maps to DORA major classification in process
• 19. Geographic spread criterion is evaluated for all multi-region deployments
• 20. Non-major classification decisions are documented with criteria assessment
• 21. Classification decisions are retained for at least 5 years (Art.25 record-keeping)

Art.18(3): Significant Cyber Threats

• 22. Process for identifying significant cyber threats is documented
• 23. Threat assessment includes NCA notification consideration
• 24. Threat intelligence sources are defined (ISACs per NIS2 Art.41, vendor feeds)
• 25. Threat notifications are logged even when NCA notification is not made

9. Key Regulatory References

10. See Also

• DORA Art.14: Communication Strategy for ICT Incidents — Art.14 closes Chapter II with communication obligations; this post opens Chapter III with the incident management process
• DORA Art.19: Major Incident Reporting 4h/24h/5-Day Timeline — Art.19 is triggered by Art.18 major classification; read both together
• DORA Art.13: Learning and Evolving from ICT Incidents — Post-incident review requirements that Art.17 feeds into
• NIS2 Art.23: Incident Notification Obligations — NIS2 parallel for non-financial sector entities; similar 4h/72h/30d structure
• EU Multi-Regulation Incident Reporting: NIS2 + GDPR + DORA — Cross-framework incident reporting when multiple regulations apply simultaneously