Article 17: ICT-related incident management process

Article 17: ICT-related incident management process requirement means you must run a defined, implemented incident management process that reliably detects ICT-related incidents, manages them end-to-end, and supports required notifications. Operationalize it by documenting the lifecycle, assigning accountable owners, integrating monitoring and ticketing, setting escalation triggers, and retaining evidence that the process runs in practice. (Regulation (EU) 2022/2554, Article 17)

Key takeaways:

• You need an end-to-end process, not a policy: detect, manage, notify, and prove operation. (Regulation (EU) 2022/2554, Article 17)
• Accountability and cross-functional handoffs (SOC, IT, Legal/Compliance, third-party owners) are the usual failure point. (Regulation (EU) 2022/2554, Article 17)
• Your best “exam defense” is traceability: incident records, escalation logs, notification decisioning, and remediation closure. (Regulation (EU) 2022/2554, Article 17)

If you are a Compliance Officer, CCO, or GRC lead supporting a DORA-scoped financial entity, Article 17 is the requirement that turns “we handle incidents” into an auditable operating capability: a defined, established, and implemented ICT-related incident management process that detects incidents, manages them, and enables notifications. (Regulation (EU) 2022/2554, Article 17)

Supervisors will not accept a slide deck, a security policy, or an IR playbook that only works for cyber events. They will look for a repeatable workflow that catches availability failures, security events, and third-party outages, routes them to the right responders, produces consistent severity decisions, and generates the artifacts needed for internal governance and regulatory notification. (Regulation (EU) 2022/2554, Article 17)

This page focuses on requirement-level implementation you can stand up quickly: what the process must cover, how to assign ownership, how to connect operations (monitoring, ticketing, on-call, problem management) with compliance needs (decision logs, notification readiness, evidence retention), and what auditors typically ask for when validating that the process is real.

Target keyword: article 17: ict-related incident management process requirement

Regulatory text

Text (excerpt): “Financial entities shall define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents.” (Regulation (EU) 2022/2554, Article 17)

What the operator must do

You must have an incident management process that is:

1. Defined: written down with scope, roles, triggers, and lifecycle steps. (Regulation (EU) 2022/2554, Article 17)
2. Established: embedded into tooling and operating routines (monitoring, ticketing, on-call, communications). (Regulation (EU) 2022/2554, Article 17)
3. Implemented: demonstrably followed during real events, with records that show detection, response actions, decisions, and notification readiness. (Regulation (EU) 2022/2554, Article 17)

The process must cover three outcomes: detect, manage, and notify ICT-related incidents. (Regulation (EU) 2022/2554, Article 17)

Plain-English interpretation

Build a single, enterprise incident process that works across cybersecurity, IT operations, and third parties. It must start with detection (alerts, user reports, third-party notifications), move through triage and containment, and end with recovery and documented closure. Along the way, it must create the information you need to decide whether an incident is notifiable and to execute notifications under your broader DORA incident reporting obligations. (Regulation (EU) 2022/2554, Article 17)

A practical way to think about Article 17: your incident response must be operationally effective and compliance-ready by design. If the SOC can respond but Compliance cannot reconstruct what happened, when it was escalated, who approved external statements, or why a notification was (or wasn’t) made, you have an Article 17 gap. (Regulation (EU) 2022/2554, Article 17)

Who it applies to (entity and operational context)

In-scope entities

Article 17 applies to financial entities in scope of DORA. (Regulation (EU) 2022/2554, Article 17)

In-scope operations

Treat the process scope as enterprise-wide and include:

• Production ICT systems supporting critical business services (payments, trading, underwriting, customer portals, core banking/ledger, etc.).
• Security operations (SOC, SIEM/EDR monitoring, threat intel intake).
• IT service management (incident tickets, on-call, change management touchpoints).
• Third parties that operate or materially affect your ICT services (cloud, MSPs, SaaS, payment processors), because their outages and breaches often become your incidents. (Regulation (EU) 2022/2554, Article 17)

What you actually need to do (step-by-step)

Step 1: Set scope and definitions you will enforce

Create a short “ICT-related incident” definition for internal operations. Anchor it to practical triggers:

• Loss of confidentiality/integrity/availability affecting ICT services
• Significant degradation, outage, data corruption, or unauthorized access
• Third-party events that impact your service delivery

Write down what is in and out (for example: purely physical facilities issues may be handled elsewhere unless they cause ICT outage). Keep this aligned with your DORA incident reporting program so operational teams don’t run parallel taxonomies. (Regulation (EU) 2022/2554, Article 17)

Step 2: Assign accountability and handoffs (RACI)

You need named owners for:

• Incident Process Owner (typically CISO, Head of IT Ops, or Operational Resilience lead) accountable for the end-to-end process design and operation.
• Incident Commander role (on-call) with authority to coordinate response.
• Compliance/Legal approver for external notification and regulator communications workflows.
• Third-party service owner accountable for vendor engagement, escalation, and evidence collection. (Regulation (EU) 2022/2554, Article 17)

Keep the RACI tight. One common failure: “everyone is consulted” and nobody can approve customer/regulator communications.

Step 3: Implement detection intake paths (not just SIEM)

Document and enable at least these intake channels:

• Monitoring alerts (security and availability)
• End-user reports (service desk)
• Third-party notifications (vendor trust portals, email, account team escalation)
• Internal change/release signals (failed deployments, rollback events)

Operational requirement: every intake must generate a unique incident record (ticket/case) with timestamps and ownership. (Regulation (EU) 2022/2554, Article 17)

Step 4: Standardize triage and severity decisioning

Create a triage checklist that responders must complete early:

• Affected service/system and business process
• Customer impact and duration (ongoing vs resolved)
• Data impact (suspected/confirmed)
• Third-party involvement
• Containment actions taken
• Current status and next checkpoint time

Add a severity matrix that maps observable conditions to severity levels. Keep it simple enough for on-call teams to apply at 2 a.m., and require an explicit log entry explaining the severity decision.

Step 5: Build the “manage” lifecycle with minimum required stages

Your lifecycle should be explicit in the process document and reflected in your tooling states. A workable baseline:

1. Open / Detect
2. Triage
3. Contain / Stabilize
4. Eradicate / Fix (as applicable)
5. Recover / Validate
6. Close
7. Post-incident review and corrective actions tracking

Tie each stage to required fields in the incident record (owner, timestamps, actions, evidence links). (Regulation (EU) 2022/2554, Article 17)

Step 6: Embed notification readiness into the workflow

Article 17 requires the process to support “notify,” which operationally means:

• A documented notification decision workflow (who decides, what inputs are required, how decisions are recorded). (Regulation (EU) 2022/2554, Article 17)
• A mechanism to quickly compile incident facts into a regulator-ready summary (timeline, impacted services, containment, residual risk).
• A controlled communications path for customers and third parties to reduce inconsistent statements.

Practical control: add a “Regulatory notification assessment” task in the incident ticket template, assigned to Compliance/Legal, with required completion before closure when severity crosses a threshold you define.

Step 7: Connect incident management to remediation closure

Auditors will test whether you close the loop. Require:

• Root cause or contributing factors documentation (right-sized to severity)
• Corrective actions with owners and due dates
• Evidence of completion (config change references, patch records, vendor RCA, test results)
• Management sign-off for acceptance of residual risk when actions are deferred

This addresses a major risk factor: evidence fragmentation across SOC tickets, problem management, and third-party emails. (Regulation (EU) 2022/2554, Article 17)

Step 8: Prove it works: drills and continuous improvement

Run readiness drills for detection, escalation, and notification decisioning, then track gaps to closure with validation evidence. This is one of the fastest ways to generate credible supervisory artifacts and find handoff issues before a real incident. (Regulation (EU) 2022/2554, Article 17)

Where Daydream fits naturally: teams often have the process in multiple places (SOC runbooks, ITSM, compliance procedures). Daydream can act as the single register that maps Article 17 obligations to concrete controls, owners, and evidence artifacts, so you can answer supervisory questions without stitching together screenshots and emails. (Regulation (EU) 2022/2554, Article 17)

Required evidence and artifacts to retain

Retain evidence that shows both design and operation:

Process design artifacts

• Incident management process document (scope, lifecycle, roles, escalation, communications, notification decisioning). (Regulation (EU) 2022/2554, Article 17)
• RACI and on-call roster definitions (or references).
• Severity matrix and triage checklist templates.
• Notification decision workflow (approvals, required inputs, recordkeeping). (Regulation (EU) 2022/2554, Article 17)

Operational artifacts (exam-grade)

• Incident tickets/cases with timestamps, assigned roles, and action logs. (Regulation (EU) 2022/2554, Article 17)
• Monitoring/alert evidence linked to the incident record (SIEM alert IDs, uptime alerts).
• Communications logs (internal status updates, customer communications approvals where applicable).
• Third-party incident communications: vendor notices, RCAs, and your escalation trail.
• Post-incident reviews and corrective action plans, with closure evidence.
• Drill/tabletop records, findings, and remediation tracking.

Common exam/audit questions and hangups

Expect questions that test traceability and repeatability:

• “Show me your incident process and the last incidents handled under it.” (Regulation (EU) 2022/2554, Article 17)
• “How do you detect incidents outside of security tooling (availability, third-party outages)?” (Regulation (EU) 2022/2554, Article 17)
• “Who can declare an incident and who can approve external notifications?” (Regulation (EU) 2022/2554, Article 17)
• “Walk through one incident: detection source → triage → containment → recovery → notification assessment → closure.” (Regulation (EU) 2022/2554, Article 17)
• “How do you ensure third-party incidents are captured and managed within your process?” (Regulation (EU) 2022/2554, Article 17)

Hangups that stall audits:

• No consistent severity decision record.
• Incidents tracked in chat threads with no durable system of record.
• Post-incident actions exist but are not tracked to closure.

Frequent implementation mistakes and how to avoid them

1. Writing a policy without wiring it into operations. Avoid this by mapping each lifecycle step to an ITSM/SOAR workflow state and required fields. (Regulation (EU) 2022/2554, Article 17)
2. Treating “notify” as a separate compliance activity. Avoid this by adding notification decision tasks into the incident workflow so it cannot be skipped. (Regulation (EU) 2022/2554, Article 17)
3. No third-party incident intake. Avoid this by defining mandatory vendor escalation channels and requiring the service owner to open an internal incident record for material vendor events. (Regulation (EU) 2022/2554, Article 17)
4. Unclear incident command authority. Avoid this by naming an Incident Commander role and documenting escalation paths for business decisions (shutdowns, customer comms).
5. Evidence scattered across tools. Avoid this by requiring a single system of record (or a hub like Daydream) that links tickets, alerts, vendor RCAs, approvals, and corrective actions. (Regulation (EU) 2022/2554, Article 17)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should plan based on supervisory expectations implied by the text: competent authorities can ask you to demonstrate that the process is implemented and effective, not merely documented. The risk is operational (slower detection and containment), regulatory (missed or inconsistent notification readiness), and governance-related (unclear accountability during crises). (Regulation (EU) 2022/2554, Article 17)

A practical 30/60/90-day execution plan

First 30 days (Immediate)

• Appoint the Incident Process Owner and finalize the RACI (SOC, IT Ops, Compliance/Legal, third-party owners). (Regulation (EU) 2022/2554, Article 17)
• Publish the minimum viable incident lifecycle and severity matrix; require use for all new ICT incidents.
• Implement a single incident record requirement (ticket/case) and enforce linking of alerts and communications. (Regulation (EU) 2022/2554, Article 17)
• Add a “notification assessment” task to incident templates with Compliance/Legal assignment. (Regulation (EU) 2022/2554, Article 17)

By 60 days (Near-term)

• Expand detection intake: service desk, third-party notifications, and change-related triggers all feed the same process. (Regulation (EU) 2022/2554, Article 17)
• Roll out post-incident review and corrective action tracking with closure evidence requirements.
• Run one drill focused on escalation + notification decisioning; capture gaps and remediation actions. (Regulation (EU) 2022/2554, Article 17)
• Stand up an evidence map: where each artifact lives and who produces it (Daydream is a practical place to maintain this register). (Regulation (EU) 2022/2554, Article 17)

By 90 days (Operationalize and harden)

• Add QA checks: sample closed incidents to confirm required fields, severity rationale, and notification assessment completion. (Regulation (EU) 2022/2554, Article 17)
• Integrate third-party expectations: require timely incident notice, RCAs, and cooperation language in contracts and operational runbooks (coordinate with your third-party risk program). (Regulation (EU) 2022/2554, Article 17)
• Produce a management reporting pack: incident volumes by severity, time-to-detect/time-to-recover trends (qualitative if you cannot support metrics cleanly), and remediation closure status.
• Run a second drill that includes a third-party outage scenario and tests evidence collection from the provider.

Frequently Asked Questions

Do we need a separate DORA incident management process from our existing IR/ITIL process?

No, but you must be able to show your existing process is defined, established, and implemented for ICT-related incidents and supports detection, management, and notification readiness. If you keep multiple processes, auditors will test consistency and handoffs. (Regulation (EU) 2022/2554, Article 17)

Does Article 17 cover outages that are not security incidents?

Yes in practice, because the requirement is “ICT-related incidents,” which includes availability and operational failures that affect ICT services. Your process should intake outages, degradations, and third-party service disruptions, not only cyber events. (Regulation (EU) 2022/2554, Article 17)

What is the minimum evidence we need to prove “implemented”?

Keep incident records showing detection source, timestamps, triage/severity rationale, actions taken, and closure steps, plus a documented process and RACI. Link any notification assessment decisions to the same record. (Regulation (EU) 2022/2554, Article 17)

How do we handle third-party incidents (cloud/SaaS/MSP) under Article 17?

Require the service owner to open an internal incident as soon as a third party reports a material event, then track vendor communications, RCAs, and your mitigation actions inside your lifecycle. Your process must work even when you do not control the underlying infrastructure. (Regulation (EU) 2022/2554, Article 17)

Who should approve regulator-facing notifications?

Set an explicit approval path that includes Legal/Compliance, with clear delegation rules for after-hours. Record the decision and the approver in the incident record so you can defend it later. (Regulation (EU) 2022/2554, Article 17)

We use multiple tools (SIEM, ITSM, SOAR). How do we avoid evidence sprawl?

Pick a system of record for the incident and require all key evidence links to be attached there (alerts, comms, RCA, corrective actions). Daydream can maintain the control-to-evidence register so you can consistently produce supervisory artifacts. (Regulation (EU) 2022/2554, Article 17)