Controls & Evidence
EU DORA readiness evaluates your controls across multiple domains. For each domain, reviewers look for evidence that controls are designed properly and operating effectively. Below are the core control domains with minimum requirements and example evidence artifacts.
What reviewers look for: Reviewers don't just check that policies exist. They verify that controls are operating as described, that evidence is produced on schedule, and that gaps are tracked and remediated. The evidence examples below show what "operating effectiveness" looks like in practice.
Comprehensive ICT risk management framework covering identification, protection, detection, response, recovery, and learning — approved by the management body.
Requirements
- Comprehensive ICT risk management framework approved by the management body
- Identification of all ICT-supported business functions, roles, and information assets
- Protection and prevention measures including security policies, access controls, and network security
- Detection of anomalous activities and ICT-related incidents
- Response and recovery procedures with estimated impact and containment timelines
- Learning and evolving processes incorporating post-incident lessons into the framework
Evidence Examples
| Artifact | Owner | Frequency |
| ICT risk management framework document with management body approval record | Chief Information Security Officer | Annually reviewed; updated upon material change |
| ICT risk assessment reports with identified threats, vulnerabilities, and residual risk ratings | ICT Risk Manager | Annually and after significant incidents |
| Protection and prevention measures documentation (security policies, access control matrices, network diagrams) | IT Security Team | Annually reviewed; updated per change management |
| Detection capability inventory and anomaly monitoring reports | Security Operations Center | Continuously monitored; quarterly effectiveness review |
Classification methodology for ICT-related incidents and mandatory reporting of major incidents to competent authorities.
Requirements
- Classification methodology for ICT-related incidents using defined criteria (clients affected, duration, geographic spread, data losses, criticality of services)
- Notification to competent authority for major incidents via initial, intermediate, and final reports
- Significant cyber threat reporting to competent authorities (voluntary)
- Incident management process covering detection, logging, classification, escalation, and resolution
Evidence Examples
| Artifact | Owner | Frequency |
| Incident classification matrix with major incident criteria and severity thresholds | ICT Risk Manager | Annually reviewed; updated upon regulatory guidance |
| Major incident notification records (initial, intermediate, final reports to competent authority) | Compliance Officer | Per major incident |
| Incident management procedure documentation with escalation paths | Security Operations Center | Annually reviewed |
| Incident register with classification decisions and timeline records | ICT Risk Manager | Per incident; quarterly summary review |
Risk-based testing program including vulnerability assessments, scenario-based tests, and threat-led penetration testing (TLPT) for significant entities.
Requirements
- Basic testing program covering vulnerability assessments, network security assessments, gap analyses, software reviews, and source code analysis
- Advanced threat-led penetration testing (TLPT) for significant financial entities
- Basic testing performed at least annually for critical ICT systems
- TLPT conducted at least every three years for in-scope entities
- Use of qualified and independent testers with appropriate certifications
Evidence Examples
| Artifact | Owner | Frequency |
| Digital operational resilience testing program with scope, methodology, and schedule | ICT Risk Manager | Annually reviewed and updated |
| Vulnerability assessment and network security test results with remediation tracking | IT Security Team | At least annually; critical systems more frequently |
| TLPT reports including threat intelligence, red team findings, and remediation plans | Chief Information Security Officer | At least every three years |
| Tester qualification records and independence attestations | Compliance Officer | Per engagement |
Strategy, register, and contractual framework for managing ICT third-party risk, including oversight of critical ICT third-party service providers.
Requirements
- Strategy on ICT third-party risk adopted by the management body
- Comprehensive register of all ICT third-party arrangements (contractual and intra-group)
- Key contractual provisions covering service levels, data locations, audit rights, exit clauses, and sub-outsourcing restrictions
- Concentration risk assessment for critical or important ICT services
- Exit strategies ensuring continuity of critical functions upon provider termination
- Oversight framework for critical ICT third-party service providers designated by ESAs
Evidence Examples
| Artifact | Owner | Frequency |
| ICT third-party risk strategy document with management body approval | Chief Information Security Officer | Annually reviewed; updated upon material change |
| Register of information on all ICT third-party arrangements | Third-Party Risk Manager | Continuously maintained; annually reported to competent authority |
| Contract review records documenting required DORA provisions (SLAs, audit rights, exit clauses) | Legal / Procurement | Per contract; annually reviewed for existing arrangements |
| Concentration risk analysis with alternative provider identification | ICT Risk Manager | Annually; updated upon provider changes |
Voluntary participation in cyber threat intelligence sharing arrangements among financial entities and with competent authorities.
Requirements
- Participation in cyber threat intelligence sharing arrangements (voluntary but encouraged)
- Trusted information sharing agreements with defined scope and confidentiality protections
- Protection of shared information including confidentiality, data protection, and competition law compliance
- Notification to competent authorities of participation in information sharing arrangements
Evidence Examples
| Artifact | Owner | Frequency |
| Information sharing agreements and membership records (ISACs, FS-ISAC, sector groups) | Chief Information Security Officer | Annually reviewed |
| Participation records and intelligence contributions | Threat Intelligence Team | Ongoing; quarterly activity summary |
| Information handling procedures for shared threat intelligence (TLP classifications, dissemination controls) | Security Operations Center | Annually reviewed |
Comprehensive ICT business continuity policy with response, recovery, and crisis communication plans tested annually.
Requirements
- Comprehensive ICT business continuity policy aligned with overall business continuity management
- Response and recovery plans for ICT-related disruptions with defined RTOs and RPOs
- Crisis communication plans covering internal stakeholders, clients, counterparties, and public authorities
- Annual testing of BCP/DR plans including scenario-based and full-scale exercises
- Lessons learned integration from tests and actual incidents into plan updates
Evidence Examples
| Artifact | Owner | Frequency |
| ICT business continuity policy and response/recovery plans with RTO/RPO targets | Business Continuity Manager | Annually reviewed; updated after material changes or incidents |
| BCP/DR test results with scenario descriptions, findings, and remediation actions | IT Operations / Business Continuity Manager | At least annually |
| Crisis communication plans with contact lists, escalation paths, and message templates | Corporate Communications / Compliance | Annually reviewed; tested during BCP exercises |
| Lessons learned reports from BCP/DR tests and actual ICT disruptions | ICT Risk Manager | After each test and significant incident |
Policies and procedures governing ICT changes including risk assessment, testing, approval, rollback, and emergency change processes.
Requirements
- ICT change management policies and procedures covering the full change lifecycle
- Risk assessment for all ICT changes proportionate to their scope and impact
- Testing before production deployment with documented results
- Rollback procedures for failed or problematic changes
- Emergency change process with expedited approval and post-hoc review
- Change approval authority with defined roles and escalation paths
Evidence Examples
| Artifact | Owner | Frequency |
| ICT change management policy with defined change categories and approval authorities | IT Operations Manager | Annually reviewed |
| Change request logs with risk assessments, test results, and approval records | Change Advisory Board / IT Operations | Per change; monthly summary review |
| Pre-deployment test records and rollback procedure documentation | DevOps / Engineering | Per change |
Inventory of all ICT and information assets with dependency mapping, criticality classification, and regular updates.
Requirements
- Complete inventory of all ICT assets and information assets
- Identification of dependencies and interconnections between ICT assets
- Classification of ICT assets by criticality to business functions
- Regular inventory updates reflecting acquisitions, changes, and decommissions
- Mapping of ICT assets to supported business functions and processes
Evidence Examples
| Artifact | Owner | Frequency |
| ICT asset register with classifications, owners, and lifecycle status | IT Asset Manager | Continuously maintained; quarterly completeness review |
| Dependency and interconnection maps showing relationships between ICT assets | Enterprise Architecture / IT Operations | Annually updated; reviewed after significant infrastructure changes |
| Criticality classification records aligned with business impact analysis | ICT Risk Manager | Annually reviewed |
Management body responsibility for ICT risk, including framework oversight, budget allocation, and mandatory ICT risk training.
Requirements
- Management body defines, approves, and oversees the ICT risk management framework
- Management body bears ultimate responsibility for managing ICT risk
- Allocation of adequate budget and resources for digital operational resilience
- Establishment of an ICT risk management function with sufficient authority and independence
- Regular training for management body members on ICT risks and digital operational resilience
Evidence Examples
| Artifact | Owner | Frequency |
| Board resolutions and meeting minutes documenting ICT risk framework approval and oversight | Board Secretary / Corporate Governance | At least annually; ad hoc for material decisions |
| ICT risk management function charter defining mandate, authority, and reporting lines | Chief Information Security Officer | Annually reviewed |
| Budget allocation records for ICT security, resilience testing, and digital operational resilience | Chief Financial Officer / CIO | Annual budget cycle |
| Management body ICT risk training records with topics covered and attendance | Human Resources / Compliance | At least annually |
Evidence Naming Conventions
Organized, traceable evidence is critical for a smooth review. Adopting a consistent convention makes evidence retrieval faster and reduces friction.
Recommended format:
ControlID_System_ArtifactType_YYYY-MM-DD_Period_Owner_v# Key principles for evidence management:
- Centralized repository with access control and version history
- Consistent naming across all control domains and artifact types
- Defined cadence for each evidence type: event-driven, monthly, quarterly, or annual
- Immutable exports where possible to demonstrate evidence integrity
AI and data companies: Standard controls are the baseline. See the AI-specific advisory modules for additional controls addressing data governance, prompt logging, RAG security, and model vendor risk.