Technology & Cyber in European Union

Key dates

2026-07-31

Joint ESA statement on ICT risks from frontier AI models in the EU financial sector published

Suggested considerations

• Compliance teams may wish to map existing and planned uses of frontier AI models (including large language models and other advanced generative or predictive systems) to current ICT risk and cyber resilience frameworks under Regulation (EU) 2022/2554 (DORA) to demonstrate that these models are covered by documented risk assessments, controls and monitoring.
• Firms should consider reviewing governance arrangements for frontier AI, including board and senior management oversight, clear accountability, and integration of AI-related ICT risks into the firm’s risk appetite, risk taxonomy and operational risk frameworks, with specific escalation and reporting lines.
• Risk and technology functions may wish to update ICT and cyber risk management policies to explicitly address frontier AI threats (e.g. prompt injection, model poisoning, data leakage, adversarial attacks) and to align detection, logging and incident response capabilities with the ESAs’ emphasis on prevention, detection and management of AI-related cyber risks.
• Operational resilience teams should consider conducting scenario analysis and testing around frontier AI incidents (such as compromised AI-enabled customer interaction tools or automated decision engines) to evidence the ability to maintain critical services in line with DORA requirements on ICT-related incident management and business continuity.
• Compliance and procurement teams may wish to review contracts and due diligence for critical ICT third‑party providers that supply or host frontier AI models, assessing how provider controls, service levels and incident processes meet DORA expectations and the ESAs’ focus on frontier AI risks.
• Supervisory engagement teams should consider preparing to discuss the firm’s frontier AI strategy, risk management and governance with competent authorities, using the ESA statement as a reference point for how existing supervisory expectations on ICT risk and cyber resilience are applied to AI use cases.
• Internal audit and second‑line control functions may wish to plan thematic reviews of frontier AI deployments to assess coverage of AI-specific ICT risks within existing control frameworks, including documentation quality, model oversight, and alignment with DORA and sectoral guidance.
• Firms should consider monitoring forthcoming ESA and national competent authority publications on frontier AI and DORA oversight activities, as the statement signals that supervisory practices and expectations in this area are evolving and may be further operationalised.

What changed

The publication introduces a consolidated supervisory expectation that frontier AI models be treated explicitly as a source of ICT and cyber risk within existing EU operational resilience and ICT risk management frameworks, rather than as a separate technology domain. It emphasises the need for robust governance, risk management, and controls around the prevention, detection and management of cyber risks stemming from frontier AI, including model governance, validation, monitoring and incident handling.

Key dates

2026-07-31

Launch of the public consultation on DPM 2.1 and publication of naming conventions for metadata used in reporting

2026-09-30 Deadline

Deadline for submitting comments to the DPM 2.1 public consultation

2023-06-01

Publication month of DPM Standard 2.0 by EBA and EIOPA, establishing the current baseline data dictionary standard

2024-03-01

Establishment of the DPM Alliance joint governance framework by EBA, EIOPA and ECB to extend DPM to ECB statistical reporting

Suggested considerations

• Compliance teams may wish to review the DPM 2.1 factsheet and the published naming conventions to understand proposed changes in metadata versioning, logical data model support and naming structures, and how these could impact existing COREP, FINREP, resolution and insurance reporting implementations.
• Regulatory reporting and technology teams should consider mapping current data dictionaries and reporting taxonomies (including those used for CRR/CRD prudential reports, BRRD/SRB resolution reports and EIOPA insurance and pensions reports) against the DPM 2.1 metamodel to assess the scale of future migration effort and potential system changes.
• Firms should consider engaging in the consultation process, either directly or via industry bodies, to provide feedback on the practicality of the proposed metamodel and naming conventions, particularly where they affect multi-framework reporting or large-scale data integration projects.
• Compliance and regulatory change functions may wish to flag DPM 2.1 internally as a strategic development in EU reporting architecture and ensure it is reflected in medium-term reporting transformation programmes, including planning for alignment with the ESCB Integrated Reporting Framework (IReF).
• Reporting vendors and in-house IT teams should consider evaluating whether their current regulatory reporting tools and data models can support DPM 2.1’s enhanced versioning and logical data model capabilities, and identify potential design changes needed to remain aligned with future EBA, EIOPA and ECB requirements.
• Supervisory liaison and public policy teams may wish to monitor subsequent EBA, EIOPA, ECB and SRB communications following the close of the consultation for indications of timelines when DPM 2.1 and the naming conventions will become expected or mandatory for specific reporting frameworks.

What changed

The DPM Alliance is consulting on DPM 2.1, an updated version of the DPM metadata model that introduces enhanced metadata versioning and extends the metamodel to host logical data models, with the explicit objective of supporting integrated European reporting across all regulatory frameworks in the financial sphere. The consultation also covers newly published naming conventions that set out a common approach for naming metadata used in reporting, designed to ensure consistent use of the common data dictionary across regulatory reporting frameworks.

Key dates

10 July 2026

- ESMA publishes the new Q&As on ESGRR, MiCA, and MiFIR secondary market topics

Suggested considerations

• Review ESG ratings policies to ensure consulting, notification, issuer feedback, and factual error review procedures align with ESMA’s latest ESGRR Q&As.
• Update internal case-handling workflows so notifications are screened for the designated contact issue and the two-working-day notification period is calculated consistently.
• Document how your firm distinguishes internal-use ESG ratings or in-house financial services from externally provided ESG ratings activity.
• Reassess whether any second-party opinion business can rely on the ESGRR exemption and record the legal basis for that conclusion.
• Re-map MiCA permissions for custody, administration, transfer, and lending services to confirm the firm is not performing activities outside its authorisation scope.

What changed

• - ESMA added a Q&A clarifying consulting activities to investors or undertakings under the EU ESG Ratings Regulation (ESGRR), which is relevant where a ratings provider’s advisory services may...
• ESMA added Q&As on the application and scope of the two working day notification period under ESGRR, indicating that firms must apply the notification clock consistently and in line with ESMA’s...
• ESMA clarified access to the dataset for factual error review under ESGRR, which affects how rated entities or issuers can review underlying data used in ESG ratings processes.
• ESMA added a Q&A on notifications without a designated contact under ESGRR, which is relevant for governance and outreach workflows when a notification lacks an identified recipient.
• ESMA clarified the obligation to consider issuer feedback under ESGRR, reinforcing that issuer comments cannot be ignored and must be handled through a documented review process.

Key dates

17 January 2025

– DORA (Regulation (EU) 2022/2554) applies, and financial entities become obliged to report major ICT‑related incidents to their competent authority once classification thresholds are met

Annual (from 2026 onwards) Deadline

– Under Article 22(2) DORA, the ESAs must issue a yearly report covering number, nature, impact, remedial actions and costs of major ICT‑related incidents; the publication in early June 2026 is the first such report and sets the expectation for future annual cycles

Suggested considerations

• Review and, where necessary, recalibrate internal incident classification criteria against the DORA definition of “ICT‑related incident” and “major ICT‑related incident”, ensuring consistency with applicable RTS on classification and materiality thresholds.
• Validate that your firm’s incident management and escalation processes can identify, assess and classify incidents “without undue delay” and trigger major‑incident reporting within the prescribed timelines (initial, intermediate and final reports).
• Conduct a gap analysis of cross‑border incident handling, ensuring that governance, communication and coordination arrangements adequately address incidents affecting multiple Member States or shared cross‑border infrastructures.
• Strengthen third‑party and outsourcing risk management by mapping critical and important functions to their supporting ICT service providers, and ensuring contracts, SLAs and incident‑response clauses support DORA reporting and cooperation obligations.
• Test and, if needed, enhance incident response runbooks to ensure close coordination with ICT service providers during incident containment, remediation and recovery, including clear roles for data provision required for regulatory reporting.

What changed

• - The ESAs have operationalised Article 22(2) DORA by issuing the first annual overview of major ICT‑related incidents, confirming that yearly ESA‑level aggregation and analysis of incident data is...
• Incident reporting under DORA is now demonstrably harmonised and centralised, with major ICT‑related incidents being notified to all competent authorities involved and then aggregated by the ESAs for...
• The report confirms that cross‑border incidents are prevalent (around one third of major incidents), reinforcing that the “borderless and interconnected” nature of ICT risk is a key supervisory...
• System failures and external events, rather than pure cyber‑attacks, are identified as the main drivers of major incidents, placing regulatory emphasis on ICT change management, resilience of core...
• The ESAs highlight third‑party and outsourcing risk as a core theme, stressing the need for robust oversight of ICT service providers and close coordination with them during incident response and...

Key dates

2025 (exact dates TBD)

– ESMA’s Call for Evidence on streamlining reporting across EMIR, MiFIR and SFTR is scheduled, with stakeholders expected to provide input on duplication removal and “report once” options

18 June 2026

– ESMA will host a webinar to present the main findings of the annual report on the quality and use of regulatory data

Suggested considerations

• Map all existing regulatory reporting obligations across EMIR, SFTR, MiFIR, AIFMD, MMFR, Prospectus and DORA ICT‑incident reporting, and document the underlying data sources, systems and ownership for each regime.
• Review and enhance data quality controls for EMIR, SFTR and MiFIR reporting, including validation rules, completeness checks, reconciliations, pairing and matching processes, and governance around Unique Transaction Identifiers and counterparty data.
• Perform a gap analysis of Prospectus reporting and DORA ICT‑incident reporting processes against ESMA’s emerging cross‑regime data quality expectations and ensure they are covered in the firm’s enterprise data governance framework.
• Establish or update a centralised regulatory data governance framework that explicitly covers cross‑regime consistency (for example, trade and position data alignment between EMIR, SFTR and MiFIR) and defines clear accountability at senior management level.
• Engage with internal IT and reporting teams to identify where a future “report once” model could be supported technically, including harmonised reference data, common identifiers and golden‑source transaction and position records.

What changed

• - ESMA confirms measurable data quality improvements across EMIR, SFTR, MiFIR, AIFMD and MMFR regulatory datasets, indicating that regulators now consider these data sufficiently reliable for...
• ESMA highlights extensive and growing supervisory use of regulatory data by ESMA and NCAs for investor protection, financial stability, orderly markets and market integrity, increasing the...
• The scope of the annual data quality and use report is expanded to include Prospectus reporting obligations, bringing prospectus‑related data formally into ESMA’s cross‑regime data quality scrutiny.
• The report scope is also expanded to include ICT‑related incident reporting under the Digital Operational Resilience Act (DORA), signaling that operational resilience incident data will be monitored...
• ESMA has launched a 2025 Call for Evidence on streamlining reporting across EMIR, MiFIR and SFTR, including options to remove duplications and apply a “report once” approach, which will likely lead...