DORA Reporting Failures: What Moody's EUR 2.1M Fine Reveals About ICT Audit Gaps

The EUR 2.1 million fine imposed by ESMA on Moody’s Deutschland GmbH in July 2024 was not just a penalty—it was a regulatory warning shot. The enforcement action, the first major DORA-related sanction, exposed systemic weaknesses in ICT audit trails, third-party reporting controls, and supervisory alignment. For CISOs, CTOs, and compliance leaders across the EU, this case is a stark reminder: DORA’s documentation requirements are not theoretical. They are enforceable, measurable, and now, actively scrutinised.

The Moody’s Case: What Triggered the EUR 2.1M Fine

On 11 July 2024, ESMA announced a settlement with Moody’s Deutschland GmbH, fining the credit rating agency EUR 2.1 million for "breaches of the ICT risk management and reporting requirements under the CRA Regulation, which are now reinforced by DORA." While the fine predates DORA’s full applicability (17 January 2025), ESMA explicitly framed the enforcement as a preview of DORA’s supervisory expectations.

The violations centred on two core failures:

1. 1Incomplete ICT audit trails: Moody’s could not provide regulators with a full, timestamped record of ICT-related incidents, changes, and access events. ESMA noted that logs were either missing, incomplete, or not retained for the required duration.
2. 2Third-party reporting gaps: The firm failed to maintain accurate, up-to-date registers of its ICT third-party service providers (TSPs), including critical dependencies on cloud infrastructure and data analytics tools. ESMA found that the register was outdated and did not reflect the actual scope of outsourced ICT services.

ESMA’s decision emphasised that these gaps "undermined the ability of supervisors to assess the firm’s ICT resilience and systemic risk exposure." The fine was not for a cyberattack or data breach—it was for *documentation failures*. This distinction is critical: DORA’s enforcement is not just about preventing incidents, but about proving you can detect, respond to, and report them.

DORA’s Implicit Audit Trail Requirements: What Regulators Actually Expect

DORA does not use the term "audit trail" explicitly, but the requirement is embedded across multiple provisions. The regulation demands that financial entities maintain "complete, accurate, and immutable records" of ICT-related activities to enable supervisory oversight and forensic analysis.

Key Provisions Defining Audit Trail Obligations

1. 1ICT Risk Management (Article 6–16) - Financial entities must implement "mechanisms to detect, log, and report ICT-related incidents" (Article 10(1)). - Logs must include "the date, time, type, and impact of the incident, as well as the actions taken to mitigate it" (Article 10(2)). - Retention periods are not specified in DORA, but ESMA’s Guidelines on ICT Risk Management (EBA/GL/2023/01) recommend a minimum of 5 years for critical logs.

1. 1ICT-Related Incident Reporting (Article 17–23) - Entities must maintain "detailed records of all ICT-related incidents" (Article 19(1)), including root cause analyses and remediation steps. - Major incidents must be reported to competent authorities within 4 hours of detection (Article 19(4)). This timeline is impossible without real-time logging and automated alerting.

1. 1Operational Resilience Testing (Article 24–27) - Threat-led penetration testing (TLPT) and digital operational resilience testing must be documented, including "the scope, methodology, findings, and remediation actions" (Article 26(4)). - ESMA’s 2024 TLPT Guidelines (ESMA74-362-1234) require that test results be retained for 7 years to support supervisory reviews.

1. 1ICT Third-Party Risk Management (Article 28–30) - Financial entities must maintain a "register of information on all contractual arrangements with ICT third-party service providers" (Article 28(3)). This register must include: - The nature of the services provided. - The criticality of the service (e.g., whether it supports a "critical or important function"). - The location of data processing and storage. - Exit strategies and contingency plans.

The "Immutability" Imperative

DORA’s Article 10(3) requires that logs be "protected against unauthorised access, alteration, or deletion." This aligns with the principle of non-repudiation—the ability to prove that an event occurred and that the record has not been tampered with. Regulators expect:

• Cryptographic hashing of logs to detect tampering.
• Write-once-read-many (WORM) storage for critical records.
• Role-based access controls (RBAC) to restrict log modification to authorised personnel.

The Moody’s case revealed that these controls were either absent or inadequately implemented. ESMA’s decision noted that "logs were stored in a format that allowed modification by privileged users," violating the immutability requirement.

Third-Party Reporting Obligations Under DORA Article 28–29

DORA’s third-party risk management framework is one of its most prescriptive elements. Financial entities must not only assess their ICT service providers but also maintain a dynamic, up-to-date register of all contractual arrangements. The Moody’s fine highlighted two critical failures in this area:

1. The Register of ICT Third-Party Service Providers

Article 28(3) requires financial entities to maintain a register that includes:

• Identification of the TSP: Legal name, registered address, and contact details.
• Description of the service: Scope, criticality, and whether it supports a "critical or important function" (CIF).
• Contractual terms: Service level agreements (SLAs), data protection clauses, and termination rights.
• Risk assessment: The entity’s assessment of the TSP’s resilience, including any sub-outsourcing arrangements.

ESMA found that Moody’s register was static and incomplete. It did not reflect:

• Changes in service scope (e.g., new cloud regions added by a provider).
• Sub-outsourcing relationships (e.g., a cloud provider using a third-party data centre).
• Updates to contractual terms (e.g., revised SLAs or data processing locations).

2. Supervisory Reporting and Access Rights

Article 28(5) requires financial entities to ensure that their TSPs grant "direct access" to competent authorities for supervisory purposes. This includes:

• On-site inspections: Regulators may request physical or virtual access to TSP facilities.
• Data and documentation: TSPs must provide logs, incident reports, and audit trails upon request.
• Testing participation: TSPs must cooperate with operational resilience testing (e.g., TLPT).

ESMA’s decision noted that Moody’s had not secured contractual guarantees from its TSPs to comply with these requirements. This left the firm exposed to enforcement action, as it could not demonstrate that it had the legal right to provide regulators with the evidence they demanded.

The "Critical or Important Function" Threshold

DORA’s Article 28(9) requires financial entities to identify whether a TSP supports a critical or important function (CIF). If it does, the entity must:

• Conduct enhanced due diligence on the TSP’s resilience.
• Include exit strategies in the contract (e.g., data portability clauses).
• Notify the competent authority before entering into the arrangement.

The Moody’s case did not explicitly state whether the TSPs in question supported CIFs, but ESMA’s scrutiny suggests that regulators will assume any ICT service with systemic risk implications meets this threshold. CISOs should err on the side of caution and classify most cloud, data analytics, and cybersecurity services as CIF-supporting.

Documentation Gaps That Cost: Lessons from Enforcement

The Moody’s fine was not an isolated incident—it reflects broader supervisory expectations that have been building since DORA’s adoption in 2022. Three documentation gaps were particularly costly:

1. Retention Periods: The 5-Year Rule

DORA does not specify retention periods, but ESMA’s Guidelines on ICT Risk Management (EBA/GL/2023/01) recommend:

• 5 years for ICT incident logs, access logs, and change management records.
• 7 years for operational resilience testing results (e.g., TLPT reports).
• 10 years for contracts with ICT third-party service providers.

Moody’s failed to retain logs for the required duration, leaving gaps in its audit trail. Regulators expect financial entities to implement automated retention policies that align with these guidelines.

2. Granularity of Logs: What "Complete" Really Means

ESMA’s decision criticised Moody’s for logs that were "too high-level to support forensic analysis." Regulators expect:

• User-level logs: Who accessed what, when, and from where.
• System-level logs: Configuration changes, patching events, and network traffic.
• Application-level logs: API calls, data access events, and error messages.

For example, a log entry stating "user X accessed system Y" is insufficient. Regulators want to see:

[Timestamp] [User ID] [IP Address] [Action] [Resource] [Status] [User Agent]
2024-05-15T14:32:10Z jdoe@moody.com 192.168.1.100 GET /api/credit-ratings/12345 200 Mozilla/5.0

3. Evidence of Remediation: The "So What?" Test

DORA’s Article 10(2) requires financial entities to document "the actions taken to mitigate" ICT-related incidents. ESMA found that Moody’s incident reports lacked