ICT incident response under DORA: detection, classification and evidence

What DORA's incident chapter expects at a high level

Article 17 sets general requirements for ICT-related incident management: policies, procedures, roles and tools to detect, manage and notify on ICT-related incidents, proportionate to the entity's size and risk.

Article 18 addresses classification - distinguishing incidents that are major or otherwise significant under the criteria developed in EU level 2 measures (including the regulatory technical standards on classification and notification). Article 19 concerns reporting of major ICT-related incidents to competent authorities, with further detail in delegated acts on content and timelines. Articles 20-23 cover intermediate and final reports, voluntary notification and informatics sharing where applicable.

Exact thresholds, deadlines and report templates are legal and supervisory matters. Engineering's contribution is to make classification inputs truthful: timestamps, affected functions, data categories, scope of customer impact, and logs that survive the first hours of an event.

Detection and logging that support classification

If you cannot reconstruct when an anomaly started, classification debates start with guesswork. For cloud-hosted critical functions, baseline detection usually combines:

• ✓Centralised security and platform logs with immutable or WORM-capable storage for the retention your policy requires.
• ✓Alert routing with on-call ownership - not a shared mailbox that nobody acknowledges at night.
• ✓Correlation between application metrics, authentication anomalies and infrastructure events for the services mapped as critical or important in your ICT register.
• ✓Runbooks that name where to pull evidence (CloudTrail, activity logs, Kubernetes audit, SaaS admin logs) before logs rotate out.

Response procedures vs tabletop exercises

Article 17 expects operational procedures, not only crisis slides. A runbook used in production lists concrete steps: contain, eradicate, recover, communicate internally, preserve forensic copies, and hand off to legal/compliance for external reporting decisions.

Tabletop exercises (Article 25 on testing also reinforces resilience testing culture) validate whether those runbooks match reality. A tabletop that never touches log queries, backup restore or comms templates produces confidence without capability. Alternate tabletop scenarios (cloud region loss, identity provider outage, ransomware in a backup path) with timed decision points surface gaps before a real incident.

Notification timelines: engineering inputs, legal decisions

Article 19 and its implementing standards define when major incidents must be reported and what initial, intermediate and final reports contain. Those clocks start from supervisory definitions of awareness and classification - not from when engineering first noticed a suspicious metric.

Platform teams should document detection time, escalation time and technical facts in a single incident record (ticket or dedicated IR tool). Counsel and compliance map that record to regulatory reporting duties, client communication and BaFin or other authority channels where applicable. Engineering should not self-authorise external regulatory filings; it should make the factual timeline defensible.

Third-party and cloud incidents

Many major incidents originate at ICT third-party providers - including hyperscale cloud outages or SaaS dependencies listed in the Article 28 register. Contractual cooperation clauses (Article 30) expect assistance during incidents; operationally that means you know which provider status page, support tier and technical account team applies to each critical function, and you have exported logs before a provider retention window closes.

Link incident records to register entries: which function failed, which contract, which recovery objective. That join is what internal audit and supervisors ask for when testing whether outsourcing governance matches reality.

What Stratoworks engineers - and what we do not do

We implement central logging, alert paths, backup and restore test evidence, and technical runbooks aligned to your critical workloads on AWS, Azure and GCP. We facilitate tabletops with realistic cloud scenarios and update IaC and monitoring when gaps appear.

We do not provide legal advice, classify incidents as 'major' under DORA, or submit reports to competent authorities. We reduce the gap between what engineering knows and what legal must decide - with timestamps, logs and procedures that hold up under review.

FAQ