Procedures to prioritise, classify and remedy all issues revealed throughout the performance of the tests

Purpose of the Requirement

Article 24(5) DORA requires financial entities (except microenterprises) to implement formalised, comprehensive, and documented procedures and policies governing the triage, classification, prioritisation, remediation, and internal validation of all issues detected during any form of digital operational resilience testing performed under Chapter IV DORA.

This requirement ensures that every weakness, deficiency, or control gap identified during testing is fully remediated, appropriately prioritised, and independently validated before closure, thereby strengthening the entity’s overall digital operational resilience posture.

Scope of Application

The procedures must cover all testing types conducted under Article 24 and Article 25 DORA, including but not limited to:

vulnerability assessments
open-source analysis
network security assessments
gap analyses
physical security reviews
scenario-based tests
end-to-end business continuity tests
failover and switchover tests
ICT third-party service provider tests
threat-led penetration testing (TLPT), where applicable
integrated testing of ICT response and recovery plans
tests of backup, restoration, recovery, and continuity procedures

The requirement applies to all weaknesses identified during such tests, irrespective of severity, origin, or affected system.

Mandatory Components of the Procedures

Financial entities must define, document, and implement procedures and policies addressing all of the following:

Prioritisation of Issues

The procedures must ensure that issues are assigned risk-based priorities, taking into account:

criticality of the affected business function or ICT asset (per Article 8(1) DORA)
impact on confidentiality, integrity, availability, and authenticity of data
dependency on ICT third-party service providers
potential for propagation or escalation
systemic impact on the digital operational resilience framework
customer impact or market-wide effects
alignment with the entity’s risk tolerance level (Article 6(8)(b) DORA)

Prioritisation must be consistent, repeatable, and documented, using well-defined criteria and thresholds.

Classification of Issues

The classification procedures must categorise all issues identified during testing, ensuring uniformity of assessment. Classification must include:

severity levels (e.g., critical, high, medium, low)
urgency levels (immediate, short-term, normal)
type of deficiency (technical, procedural, organisational)
affected systems, assets, data, or functions
root-cause category (e.g., configuration, architectural weakness, human error, procedural gap, ICT third-party issue)
linkage to vulnerabilities, controls, resilience mechanisms or dependencies

Classification must align with:

the ICT asset classification scheme (Article 8(1), (4), (6) DORA)
vulnerability assessment procedures (Article 10 RTS RMF)
ICT risk assessment methodology (Article 3 RTS RMF)

Remediation Requirements

Procedures must define how issues are corrected, including:

mandatory remediation steps for each severity level
timelines and deadlines for correction
responsible roles and escalation paths
interim mitigating controls if immediate remediation is not possible
dependencies on ICT third-party service providers
documentation requirements for actions taken
required approvals for remediation plans
criteria for reopening previously closed issues (e.g., if recurrence is detected)

Remediation processes must guarantee that identified vulnerabilities and gaps cannot remain unaddressed or unresolved beyond approved timelines.

Internal Validation Methodologies

Article 24(5) DORA requires financial entities to establish internal validation methodologies ensuring that all identified weaknesses, deficiencies, and gaps are:

verified,
tested,
validated, and
confirmed as fully addressed

before closure.

The validation methodologies must include:

Independence and segregation

Validation must be performed by functions independent of those who executed the test or performed remediation, in line with the three lines of defence model (Article 6(4) DORA).

Evidence-based verification

Validation must rely on:

technical evidence (logs, test results, screenshots, configurations)
procedural evidence (policies, processes, process flows)
organisational evidence (training records, ownership definitions)

Retesting

Critical issues must be retested under similar conditions to verify that:

the deficiency is removed
no new weaknesses are introduced
the remediation aligns with security and resilience requirements

Formal closure mechanisms

The methodology must stipulate:

acceptance criteria for testing issues
sign-off requirements
documentation for closure
conditions requiring further follow-up

Documentation Requirements

Entities must document:

issue inventories and registers
classification and prioritisation decisions
remediation plans and activities
validation evidence
final closure status
lessons learned
impact on risk assessments, continuity plans, and architecture

Documentation must be complete, up-to-date, auditable, and aligned with:

Article 6(5) DORA (review of ICT risk management framework)
Article 25(5) RTS RMF (documentation of ICT BCP tests)
Article 23 RTS RMF (records of anomalous activities)
Article 17 DORA (incident records)

Integration with Other DORA Requirements

The procedures must feed into and be consistent with:

ICT risk assessment and risk tolerance (Article 6(8))
anomaly detection and incident management (Articles 10 and 17)
ICT change management (Article 17 RTS RMF)
ICT BCP testing (Article 25 RTS RMF)
governance oversight by the management body (Article 5(2))
audit follow-up process (Article 6(7))

Weaknesses discovered during testing are inputs for:

updates of ICT BCP and response plans (Articles 24–26 RTS RMF)
improvements of detection mechanisms (Article 10)
refinement of security controls
adjustments to third-party monitoring (Article 28)

Supervisory and Audit Expectations

Supervisors and auditors will expect to see:

a defined issue lifecycle workflow
complete and accurate issue logs
clear severity and priority determination
defined remediation deadlines and evidence of compliance
independence in validation
evidence of periodic review by senior management
traceability from issue discovery → remediation → validation → closure
improvements to processes based on lessons learned

Article 24 (5) DORA

Article 24 DORA – General requirements for the performance of digital operational resilience testing