0%
0 of 49 answered
Pillar 1 — ICT Risk
ICT Risk Management
0/12
Pillar 2 — Incidents
Incident Management
0/10
Pillar 3 — Testing
Resilience Testing
0/9
Pillar 4 — Third-Party
Third-Party Risk
0/10
Pillar 5 — Sharing
Information Sharing
0/8
P1
ICT Risk Management
Articles 5–16 — Governance, risk framework, protection, detection, response & recovery
Art. 5 — ICT Risk Management Governance
Does the management body define, approve, and oversee the implementation of the ICT risk management framework?
DORA Article 5(2) requires the management body to bear ultimate responsibility for managing ICT risk, including defining risk appetite, approving the ICT risk management framework, and reviewing it at least annually.
Is there a dedicated ICT risk management function with clear roles, responsibilities, and reporting lines?
Article 6(4) requires a control function independent from ICT operations for entities not subject to simplified requirements. Adequate budget and resources must be allocated.
Art. 6–7 — ICT Risk Management Framework
Is there a comprehensive, documented ICT risk management framework that is reviewed at least annually?
Article 6(1) requires a sound, comprehensive, and well-documented ICT risk management framework as part of the overall risk management system. It must include strategies, policies, and procedures for ICT risk protection.
Do you maintain a complete and up-to-date inventory of all ICT assets, systems, and information assets?
Article 7 requires identification and documentation of all ICT-supported business functions, information assets, and ICT assets, including those on remote sites. Assets must be classified by criticality.
Art. 8–9 — Protection & Prevention
Are ICT systems and tools kept up to date and protected with appropriate security measures including encryption, network segmentation, and access controls?
Article 8 requires mechanisms to promptly detect anomalous activities. Article 9 requires protection policies covering encryption, cryptographic controls, and ICT operations security.
Is there a robust identity and access management policy including strong authentication, least-privilege access, and regular access reviews?
Article 9(4) requires implementing strong authentication mechanisms, managing privileged access, and applying the principle of least privilege. Access rights must be regularly reviewed.
Is there a comprehensive patch management and vulnerability management process for all ICT systems?
Article 9(2) requires processes to manage vulnerabilities, including timely patching. Critical patches should be deployed following risk-based prioritisation.
Art. 10 — Detection
Are mechanisms in place to promptly detect anomalous activities on ICT networks, including automated alerting and log analysis?
Article 10 requires mechanisms to detect anomalous activities, including ICT-related incidents and significant single points of failure. Multiple layers of controls and alert thresholds should be defined.
Art. 11–13 — Response, Recovery & Backup
Is there a comprehensive ICT business continuity policy with documented response and recovery plans?
Article 11 requires an ICT business continuity policy covering risk scenarios, communication plans, and procedures to ensure continuity of critical functions. Plans must be tested at least annually.
Are backup and restoration policies in place with regular testing of backup integrity and recovery procedures?
Article 12 requires backup policies with defined scope, frequency, and recovery methods. Restoration from backups must be tested periodically. Secondary processing sites should be considered for critical functions.
Are post-incident reviews conducted to identify root causes and are lessons learned formally documented and acted upon?
Article 13 requires learning from ICT-related incidents and digital operational resilience testing. Financial entities must analyse root causes of disruptions and share key findings with relevant staff.
Art. 14–16 — Communication & Awareness
Is there an ICT security awareness programme covering all staff, with specific training for the management body?
Article 13(6) requires ongoing ICT security awareness programmes. Article 5(4) mandates that management body members maintain sufficient ICT knowledge and skills, including through regular training.
P2
ICT-Related Incident Management
Articles 17–23 — Classification, reporting, and major incident handling
Art. 17 — Incident Management Process
Is there a documented ICT-related incident management process covering detection, recording, classification, and escalation?
Article 17 requires financial entities to define, establish, and implement an ICT-related incident management process to detect, manage, and notify ICT-related incidents.
Are early warning indicators and automated alert mechanisms in place to trigger the incident response process?
Effective incident management requires early detection through monitoring and alerting. Trigger criteria should be documented so that potential incidents are identified before they escalate.
Art. 18 — Classification of Incidents
Do you classify ICT-related incidents using the criteria specified in DORA (number of clients affected, duration, geographic spread, data losses, criticality of services, economic impact)?
Article 18 defines specific criteria for classifying ICT-related incidents as major. These include client impact, duration of downtime, data losses, criticality of affected services, and economic impact thresholds.
Is there a process for identifying and classifying significant cyber threats in addition to incidents?
Article 18(2) requires classification of significant cyber threats based on the criticality of services at risk, including near-miss scenarios that could have materialised as major incidents.
Art. 19–20 — Incident Reporting
Is there a process to report major ICT-related incidents to the competent authority within the required timeframes (initial notification within 4 hours of classification)?
Article 19 mandates reporting major ICT-related incidents to the competent authority. The RTS specifies an initial notification within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month.
Do you have templates and procedures ready for initial, intermediate, and final incident reports to the competent authority?
The three-stage reporting process requires standardised templates. Pre-prepared templates with clear data fields accelerate compliance during the stress of an actual incident.
Is there a process to notify affected clients when a major ICT-related incident impacts their financial interests?
Article 19(3) requires financial entities to inform clients about major ICT-related incidents that may affect their financial interests, including the measures taken to mitigate adverse effects.
Art. 21–23 — Incident Logging & Coordination
Are all ICT-related incidents and significant cyber threats logged and the root causes analysed and documented?
Article 17 requires recording and documenting all ICT-related incidents and significant cyber threats. Root cause analysis must be conducted for major incidents to prevent recurrence.
Is there a crisis communication plan that covers internal escalation, external stakeholders, the media, and regulators?
Effective incident response requires pre-defined communication channels. Staff designated to handle public disclosures, regulator liaison, and client notifications should be identified in advance.
Are there mechanisms to share incident data with peer financial entities or sectoral bodies (e.g., ISACs) where relevant?
Article 23 encourages voluntary notification of significant cyber threats to the competent authority and sharing anonymised incident data with peers to strengthen collective resilience.
P3
Digital Operational Resilience Testing
Articles 24–27 — Testing programme, TLPT, and vulnerability assessments
Art. 24 — General Testing Requirements
Is there a digital operational resilience testing programme that is proportionate to the size and risk profile of your entity?
Article 24 requires a sound and comprehensive testing programme as an integral part of the ICT risk management framework. Testing must be undertaken by independent parties (internal or external).
Does your testing programme include vulnerability assessments and scans, open-source analyses, network security assessments, and gap analyses?
Article 25 lists specific tests that all financial entities must perform, including vulnerability assessments, scenario-based testing, compatibility testing, performance testing, and end-to-end testing.
Art. 25 — Testing of ICT Tools and Systems
Are all critical ICT systems and applications tested at least annually, with identified issues prioritised and remediated in a timely manner?
Article 25 requires regular testing of all critical ICT systems. Test findings must be risk-assessed and fully remediated. Corrective measures should be tracked and verified.
Are scenario-based tests performed that simulate plausible adverse events including severe business disruptions and cyber-attacks?
Testing should include realistic scenario-based exercises simulating cyber-attacks, infrastructure failures, and supply chain disruptions, to validate the effectiveness of response and recovery plans.
Art. 26–27 — Threat-Led Penetration Testing (TLPT)
If your entity is identified for TLPT, do you carry out threat-led penetration testing at least every 3 years covering critical or important functions?
Article 26 requires significant financial entities (as identified by the competent authority) to conduct advanced TLPT at least every 3 years. The scope must cover critical functions and live production systems.
Are TLPT engagements conducted using the TIBER-EU framework (or equivalent recognised standard) with qualified external testers?
Article 27 specifies that TLPT must follow the TIBER-EU framework. External testers must meet reputation, expertise, and independence requirements. Internal testers may participate but with constraints.
Are ICT third-party service providers supporting critical functions included in the scope of your TLPT programme (pooled testing or direct)?
Article 26(3) permits pooled testing where ICT third-party providers are in scope. The financial entity retains full responsibility and must ensure appropriate risk management measures are applied throughout.
Remediation & Reporting
Are testing findings formally reported to the management body and are remediation plans tracked to completion?
Test results must be communicated to the management body and validated by internal audit. Findings should be prioritised and remediation tracked with clear ownership and deadlines.
Is there a red-teaming or adversary simulation capability (internal or external) to test detection and response under realistic conditions?
Beyond TLPT, regular red-team exercises help validate the effectiveness of SOC capabilities, incident response playbooks, and staff readiness against sophisticated attack scenarios.
P4
ICT Third-Party Risk Management
Articles 28–44 — Outsourcing, contractual requirements, and oversight
Art. 28 — General Principles
Is there a strategy and policy for managing ICT third-party risk, including a register of all ICT service arrangements?
Article 28 requires a strategy on ICT third-party risk as part of the overall ICT risk management framework. A complete register of all ICT third-party arrangements must be maintained, distinguishing those supporting critical or important functions.
Do you report annually to the competent authority on the number of new ICT third-party arrangements, categories of providers, and type of contractual arrangements?
Article 28(3) requires annual reporting to the competent authority on new arrangements for ICT services supporting critical or important functions, including information on the types of providers and services contracted.
Art. 29 — Pre-Contractual Assessment
Do you conduct a thorough risk assessment before entering into ICT third-party contracts, including concentration risk and sub-outsourcing analysis?
Article 29 requires due diligence before contracting ICT third-party providers. This includes assessing whether the arrangement creates concentration risk, evaluating the provider’s ability to meet DORA requirements, and identifying sub-outsourcing chains.
Art. 30 — Key Contractual Provisions
Do your ICT third-party contracts include the mandatory DORA provisions (SLAs, audit rights, exit strategies, data location, incident support obligations)?
Article 30 specifies mandatory contractual terms: clear service descriptions, SLAs, data processing locations, audit and access rights, cooperation during incidents, exit strategies with transition periods, and sub-outsourcing conditions.
Do contracts for critical/important function providers include the right of full access, inspection, and audit, including on-site access to the provider?
Article 30(3) requires that contracts supporting critical or important functions include unrestricted rights of access, inspection, and audit for the financial entity and its competent authority.
Art. 28–30 — Ongoing Oversight & Exit Strategy
Is there ongoing monitoring of ICT third-party provider performance, security posture, and compliance with contractual obligations?
Financial entities must continuously monitor provider performance against agreed SLAs, conduct periodic risk assessments, and verify that the provider maintains adequate security standards throughout the contractual term.
Are there documented exit strategies for all critical ICT third-party arrangements, including data migration and transition plans?
Article 28(8) requires comprehensive exit strategies covering transition to alternative providers, data portability, adequate transition periods, and continued service during the migration. Plans should be tested periodically.
Art. 28–29 — Concentration Risk & Sub-outsourcing
Have you assessed and mitigated ICT concentration risk, including over-reliance on a single provider or providers established in the same jurisdiction?
Article 29(2) requires assessment of ICT concentration risk arising from multiple arrangements with the same or closely connected providers. Financial entities must consider geographic concentration and the substitutability of providers.
Is there visibility into the sub-outsourcing chains of critical ICT providers, with appropriate contractual controls on sub-outsourcing?
Article 29(2) requires financial entities to consider the risks from sub-outsourcing, particularly where sub-outsourcees are established in third countries. Contracts must restrict or condition sub-outsourcing of critical services.
Does the management body receive regular reporting on ICT third-party risk, including material changes to the provider register?
The management body must be informed of material ICT third-party risks and changes. Reporting should cover new arrangements, performance issues, concentration risk, and the status of exit plans.
P5
Information Sharing Arrangements
Article 45 — Cyber threat intelligence, voluntary sharing, and cross-sector collaboration
Art. 45 — Information Sharing
Does your organisation participate in information-sharing arrangements with other financial entities or sectoral bodies for exchanging cyber threat intelligence?
Article 45 permits financial entities to exchange cyber threat intelligence (TTPs, indicators of compromise, tactics, alerts, and configuration tools). Arrangements must be within trusted communities and protect business confidentiality.
Are there policies and procedures governing the handling, classification, and protection of shared threat intelligence data?
Sharing arrangements must protect commercially sensitive data, personal data, and competition law constraints. Governance policies should define classification levels, data handling procedures, and confidentiality requirements.
Has the management body been notified of the participation in information-sharing arrangements, as required by DORA?
Article 45(2) requires financial entities to notify their competent authority of their participation in information-sharing arrangements. The management body must be informed and approve such participation.
Threat Intelligence Capability
Does your organisation subscribe to or consume structured cyber threat intelligence feeds (e.g., STIX/TAXII, MISP, sectoral ISACs)?
Effective information sharing requires technical capability to ingest, analyse, and act on threat intelligence. Structured formats like STIX/TAXII enable automated ingestion and correlation.
Is received threat intelligence used operationally to update detection rules, security controls, and risk assessments?
Intelligence should flow into operational processes: updating firewall rules, IDS signatures, SIEM correlation rules, vulnerability prioritisation, and risk assessments. A feedback loop should validate the intelligence’s usefulness.
Cross-Sector & Regulatory Collaboration
Does your organisation engage with sector-specific CERTs, CSIRTs, or the ESAs’ coordination mechanisms for cyber resilience?
DORA envisages a coordinated response mechanism across the EU financial sector. Engagement with national CERTs, sectoral CSIRTs, and the ESAs’ joint exercises strengthens collective resilience.
Are lessons learned from industry incidents and shared intelligence reviewed and incorporated into your ICT risk management framework?
Intelligence sharing should not be passive. Lessons from sector-wide incidents, regulatory advisories, and peer disclosures should be actively reviewed and used to update policies, controls, and training.
Is there a designated role or function responsible for coordinating information sharing and maintaining external relationships with sharing communities?
A designated CTI lead or team ensures consistent participation in sharing communities, timely dissemination of received intelligence, and quality control of outbound contributions.