Art.17(3) Incident classification
What the standard requires
3. The ICT-related incident management process referred to in paragraph 1 shall: (a) put in place early warning indicators; (b) establish procedures to identify, track, log, categorise and classify ICT-related incidents according to their priority and severity and according to the criticality of the services impacted, in accordance with the criteria set out in Article 18(1); (c) assign roles and responsibilities that need to be activated for different ICT-related incident types and scenarios; (d) set out plans for communication to staff, external stakeholders and media in accordance with Article 14 and for notification to clients, for internal escalation procedures, including ICT-related customer complaints, as well as for the provision of information to financial entities that act as counterparts, as appropriate; (e) ensure that at least major ICT-related incidents are reported to relevant senior management and inform the management body of at least major ICT-related incidents, explaining the impact, response and additional controls to be established as a result of such ICT-related incidents; (f) establish ICT-related incident response procedures to mitigate impacts and ensure that services become operational and secure in a timely manner.
Quoted verbatim from Regulation (EU) 2022/2554 (DORA), which is in the public domain.
Cross-framework mappings
No cross-framework mapping is seeded for this control. That is stated rather than filled in: a mapping nobody authored is worse than a gap you can see.
Integrations that carry evidence for this family
These connectors produce data relevant to DORA’s Incident Management family, which is the granularity CMDash publishes — there is no pre-built per-control mapping, and claiming one would be inventing it. You decide which evidence answers which control.
In CMDash this control is a row with an owner, a status, uploaded evidence kept with its full history, and an export an assessor can read.