€30 Million in Four Days: What the Commerzbank Service Provider Breach Means for DORA Third-Party ICT Risk

The most important detail in the Commerzbank breach is not the amount stolen. It is where the attack entered. Not through the bank. Through a vendor.

In November 2023, attackers identified a software vulnerability introduced by a faulty update at the payment and transaction processing system of a third-party service provider. Over four days, they used this vulnerability to initiate thousands of unauthorized direct debits from Commerzbank customer accounts. The stolen funds moved to Brazil through a layered network of pass-through accounts, shell companies, payment institutions, virtual-asset platforms, and prepaid cards issued without beneficiaries' consent.

Nearly three years later, on August 14, 2026, German and Brazilian federal police launched Operation Klonen. Four suspects were arrested in Brazil. Three more were charged in Spain and Bulgaria. Brazilian courts ordered the seizure of more than $22 million in assets. One of the arrested suspects had used illicit proceeds to fund a 2024 political campaign.

Commerzbank confirmed the incident in a statement to BleepingComputer: "Due to technical issues at a service provider, unauthorized direct debits were made from customer accounts. There was no financial loss to customers." The bank absorbed the €30 million.

The Attack Surface That Was Not the Bank

The mechanism of this theft was straightforward in retrospect. A software update introduced a flaw into a payment processor's systems. The flaw allowed unauthorized instructions to pass through as legitimate transaction requests. Commerzbank's own infrastructure had no visibility into what was happening inside its vendor's systems until the fraudulent transactions had already cleared.

This is the defining characteristic of third-party ICT risk. The financial institution's perimeter controls, monitoring, and detection capabilities operate at the boundary between the institution and the outside world. They do not operate inside the systems of the vendors that process transactions on its behalf. A vulnerability inside a payment processor is invisible to the bank's security team unless the bank has contractual rights to audit and monitor that vendor, and is actually exercising those rights continuously.

Most financial institutions are not. The industry standard before DORA was point-in-time vendor assessment: a questionnaire at onboarding, an annual review, and contractual security clauses that imposed obligations without verification mechanisms. Under that model, a faulty software update deployed between annual reviews would remain undetected until it was exploited.

What DORA Requires Now

The EU's Digital Operational Resilience Act (DORA, Regulation 2022/2554) came into force on January 17, 2025. It applies to more than 22,000 financial entities operating in the EU, including banks, investment firms, insurance companies, payment processors, and crypto-asset service providers.

DORA's third-party ICT risk requirements (Articles 28-44) fundamentally change the standard of care for financial sector vendor management. The key requirements include:

ICT Third-Party Register. Financial entities must maintain a complete and current register of all ICT third-party service arrangements, including a risk classification for each. The register must identify which providers support critical or important functions.

Pre-Contract Due Diligence. Before entering any arrangement with an ICT provider, financial entities must assess the provider's security practices, resilience capabilities, sub-contracting chains, and data protection standards. This assessment must be documented and proportionate to the criticality of the service.

Mandatory Contractual Provisions. ICT service contracts must include specific provisions on security standards, incident notification timelines, audit rights, data return and deletion on termination, and cooperation with regulatory investigations. Contracts that predate DORA must be reviewed and updated by July 2025.

Ongoing Monitoring. DORA requires continuous monitoring of ICT third-party providers, not just annual reviews. Financial entities must track changes in provider security posture, monitor for significant incidents at providers, and conduct regular resilience testing of critical third-party dependencies.

Concentration Risk Assessment. Financial entities must identify and assess concentration risk from reliance on a single ICT provider for critical services, and demonstrate they can substitute or recover if that provider fails.

Critical Third-Party Provider Oversight

DORA's most significant structural innovation is the Critical Third-Party Provider (CTPP) designation. The Joint Committee of the European Supervisory Authorities (EBA, ESMA, and EIOPA) designates ICT providers as CTPPs based on the systemic importance of their services to the EU financial sector.

A payment processor serving major EU financial institutions, of the type involved in the Commerzbank case, is precisely the category of provider that CTPP designation was designed to reach. CTPP designation triggers direct oversight by a Lead Overseer from the European Supervisory Authorities, with powers to request information, conduct general investigations, and perform on-site inspections.

The significance is that regulatory oversight now extends to ICT providers that are not themselves regulated financial institutions. A vulnerability introduced by a faulty software update at a CTPP-designated payment processor would today fall within the direct scrutiny of EU financial supervisors, not just the contractual oversight of individual bank clients.

From Questionnaires to Continuous Assurance

The practical challenge DORA creates for financial CISOs is the gap between documentation and assurance. Financial institutions have spent years building vendor management programs that produce documentation: questionnaires completed, audits scheduled, contracts signed, clauses included. DORA does not invalidate this documentation. It requires that the documentation be backed by actual evidence of ongoing oversight.

The Commerzbank attack happened through a change event: a software update deployed at a payment processor. The window of exploitation was the period between when the faulty update was deployed and when the vulnerability was either discovered or patched. In a traditional vendor management model, this window is invisible. No questionnaire captures it. No annual audit catches it in time. Only continuous monitoring of what is actually happening inside the vendor's environment has a chance of detecting it.

DORA's ongoing monitoring requirement is the mechanism designed to close this window. It requires financial entities to move from a model where vendor security is assessed periodically to one where it is tracked continuously. This is a significant operational change for most TPRM programs.

What Financial CISOs Should Do Now

Audit your ICT third-party register for completeness. DORA's register requirement is the foundation of everything else. If your organization does not have a current, accurate inventory of all ICT third-party arrangements including sub-contractors, you cannot classify risk, negotiate appropriate contracts, or conduct meaningful ongoing monitoring. Start here.

Classify your critical ICT providers and tier your monitoring accordingly. Not all ICT vendors carry the same risk. Payment processors, core banking systems, and cloud infrastructure providers that support critical or important functions require a different level of ongoing scrutiny than commodity software tools. DORA requires classification. Monitoring intensity should follow from it.

Negotiate real audit and monitoring rights into contracts. Contractual security clauses that impose obligations on vendors are only valuable if you can verify compliance. Negotiate explicit rights to receive security logs, vulnerability disclosures, and incident notifications on defined timelines. Negotiate rights to conduct or commission security assessments of vendor environments, not just receive self-reported questionnaire responses.

Test your critical third-party dependencies in resilience exercises. DORA requires digital operational resilience testing, including testing of scenarios where critical ICT providers fail or are compromised. Run tabletop exercises that model a security failure at your most critical payment processor or cloud provider. Identify what detection you have, what your response options are, and how long substitution or recovery would take.

Implement external monitoring for critical third-party provider assets. Attack surface management tools can provide visibility into the internet-facing infrastructure of your critical ICT providers. A new vulnerability in a payment processor's external systems, an exposed admin interface, or a certificate lapse is detectable from outside before it is exploited. This is the kind of continuous monitoring DORA anticipates, and it does not require contractual access to the vendor's internal systems.

Document your ongoing monitoring as a DORA evidence trail. DORA audits by competent authorities will ask for evidence of ongoing oversight, not just a policy that says ongoing oversight occurs. Build monitoring workflows that produce timestamped records of what you checked, when, and what you found. This is the evidence base that distinguishes a compliant TPRM program from one that is compliant on paper.