ECB AI Cybersecurity Action Plan: The Complete Guide

On 7 July 2026, the European Central Bank issued Letter SSM-2026-0301, "Addressing AI-enabled cybersecurity threats", signed by Claudia Buch, Chair of the ECB Supervisory Board, and addressed to the CEO of every significant institution (SI) under direct ECB supervision. The letter is not a new regulation. It is a supervisory instrument built on the Digital Operational Resilience Act (DORA), requiring in-scope banks to submit a comprehensive action plan by 31 October 2026 outlining concrete measures to address AI-enabled cybersecurity threats, along with the resources, roles, responsibilities, and timelines to deliver them.

Miss the deadline and there are no immediate fines, but there is supervisory scrutiny with real teeth through the Supervisory Review and Evaluation Process (SREP), which can affect capital requirements and remediation orders. Underneath the deadline, the obligation runs on DORA: continuous testing evidence against AI-class attacks. The deadline expires; the DORA obligation stays. The ECB was explicit in a parallel warning by the European Systemic Risk Board (ESRB/2026/3, 25 June 2026) that Frontier AI Models (FAIMs) can now craft weaponised exploits "in a matter of minutes or hours", which is why the ECB is asking questions the annual pentest cadence was never built to answer.

This guide covers exactly what Letter SSM-2026-0301 requires, the six focus areas from Annex 1 that the action plan must cover, who the letter applies to, how it sits alongside DORA, NIS2, TIBER-EU and the EU AI Act, and how banks satisfy it step by step. Ethiack's agentic AI pentester Hackian is one way banks produce the continuous testing evidence the action plan calls for, with reproducible proof of exploit for every validated vulnerability.

Key takeaways

• Primary source: Letter SSM-2026-0301, "Addressing AI-enabled cybersecurity threats", signed by Claudia Buch, Chair of the ECB Supervisory Board, dated 7 July 2026, addressed to CEOs of significant institutions
• Not a regulation: a supervisory instrument built on DORA, with SREP consequences for non-compliance rather than direct fines
• Deadline 31 October 2026: significant institutions must submit a comprehensive action plan to their Joint Supervisory Team (JST) outlining concrete measures, resources, roles, responsibilities, and timelines
• The action plan must cover six focus areas set out in Annex 1: (1) attack surface protection, (2) vulnerability and patch management at scale, (3) monitoring, detection and AI-enabled defensive capabilities, (4) governance, funding, awareness training and supply chain assurance, (5) defence-in-depth and infrastructure modernisation, (6) operational resilience and information sharing
• Scope: the letter is addressed directly to significant institutions (SIs). Similar expectations are widely anticipated to extend to less significant institutions (LSIs) through national competent authorities, with some NCAs already issuing parallel guidance
• Built on DORA: sharpens Article 25 focus on AI-class attacks; banks with DORA-compliant continuous testing programmes already have most of the evidence the action plan requires
• ECB extension: the deadline for the annual IT Risk Questionnaire has been extended from September 2026 to February 2027 to allow banks to focus resources on the action plan
• Practical next step: start with the DORA mechanism you already have and extend it to AI-class attacks specifically, mapped to the six focus areas of Annex 1

What is the ECB AI Cybersecurity Action Plan?

The ECB AI Cybersecurity Action Plan refers to Letter SSM-2026-0301, "Addressing AI-enabled cybersecurity threats", issued on 7 July 2026 by the ECB's Supervisory Board. The letter requires significant institutions to develop a comprehensive action plan and submit it to their Joint Supervisory Team by 31 October 2026. The action plan is what banks build; the letter is the supervisory instrument that requires it.

The primary source: Letter SSM-2026-0301

Letter SSM-2026-0301 is a supervisory instrument signed by Claudia Buch, Chair of the ECB Supervisory Board, dated 7 July 2026. It is not a regulation with fines and no EUR-Lex entry exists for it. It is a formal supervisory communication addressed to CEOs of significant institutions, sitting on top of DORA (Regulation (EU) 2022/2554). The letter includes two annexes: Annex 1 sets out the six focus areas the action plan must cover; Annex 2 lists international guidelines from CERT-EU, ENISA, FS-ISAC, UK NCSC, and other authorities that inform the expected posture.

How the letter sits alongside the Supervisory Priorities 2025-2027

Letter SSM-2026-0301 is a standalone supervisory instrument, not directly derived from the ECB's Supervisory Priorities 2025-2027. The Priorities established operational resilience as a standing supervisory priority for the cycle; the July 2026 letter translates that priority into a concrete per-bank deliverable with a hard deadline. Distinguishing between the two matters: the Priorities set the context, the letter creates the specific obligation. Conflating them weakens the regulatory precision the action plan depends on.

What the letter is not (why it is not a regulation)

The letter is not a new regulation. There is no direct fines regime and no directly effective legal obligation. It is a supervisory instrument, which in ECB banking supervision means a formalised communication of what supervisors will look for and how they will react if they do not see it. That reaction runs through the SREP process, not the courts. Banks that treat the letter as advisory misread it; the ECB has committed to horizontal analysis across all submitted action plans and continuous JST engagement on execution.

Why now: the ESRB warning on Frontier AI Models

The ECB letter did not arrive in isolation. On 25 June 2026, the European Systemic Risk Board (ESRB) adopted Warning ESRB/2026/3, published as C/2026/3795, on "systemic cyber risks stemming from frontier artificial intelligence models". The warning is the systemic-risk assessment that gives the ECB letter its urgency and direction.

The ESRB warning names Frontier AI Models (FAIMs) as the specific driver of the risk escalation. FAIMs are highly capable in the cybersecurity domain, able to discover vulnerabilities and craft working exploits at speed, scale and accuracy rivalling leading human experts. The warning quantifies the shift starkly: "The crafting of weaponised exploits was previously largely done manually and took human experts days or weeks, whereas it can now be done by FAIMs in a matter of minutes or hours." That collapse of the defensive time buffer is the systemic-risk signal the ECB letter answers.

Three asymmetries in the ESRB warning frame the supervisory concern. First, the asymmetry between EU and third-country jurisdictions given the geographical concentration of leading AI providers outside the Union. Second, the asymmetry between attackers and defenders as FAIMs reduce the cost of admission for offensive operations while defenders remain constrained by regulatory obligations. Third, the asymmetry between well-resourced and less well-equipped financial institutions. The ECB letter is a supervisory intervention against the second and third of these asymmetries, calling on significant institutions to build the resilience the systemic-risk assessment says the sector needs.

The ECB is a supervisor, not a legislator. It cannot pass a regulation to close the gap between annual pentest cadence and machine-speed attackers. It can issue a supervisory instrument with SREP consequences for banks that do not respond. Letter SSM-2026-0301 is that instrument.

Who does the ECB AI Cybersecurity Action Plan apply to?

Letter SSM-2026-0301 is addressed directly to CEOs of significant institutions (SIs) under direct ECB supervision. The letter itself does not extend obligations to less significant institutions (LSIs), third-country branches, or non-eurozone banks. In practice, similar expectations are anticipated to reach a wider set of institutions through parallel supervisory channels.

Significant institutions (SIs) directly

Significant institutions are eurozone banks under direct ECB supervision, typically banks with more than €30 billion in total assets, cross-border operations at material scale, or top-3 status in their Member State by size. They are supervised directly by ECB Joint Supervisory Teams. Letter SSM-2026-0301 is addressed to the CEO of every SI, reaching each bank through its JST channel.

Less significant institutions (LSIs) via national competent authorities

While the letter is addressed directly to significant institutions, similar expectations are widely anticipated to extend to LSIs through national competent authorities, with some NCAs already issuing parallel guidance. LSIs are supervised by the NCA of their Member State with ECB oversight; when NCAs cascade the expectations, proportionality typically applies, calibrated to the scale, complexity and AI-exposure profile of each institution.

Third-country branches

Third-country branches operating in the eurozone (a US bank's Frankfurt branch, for example) are supervised either by the ECB or by the NCA depending on scope. Letter SSM-2026-0301 does not directly address them. Where a branch is material and part of a broader systemic-risk profile, supervisors are likely to raise equivalent expectations through the applicable channel. Immaterial branches face lighter treatment.

What about non-eurozone European banks?

The ECB's supervisory remit does not extend to non-eurozone European banks (UK, Nordics, Switzerland). These banks are supervised by their national authorities and Letter SSM-2026-0301 does not apply. However, similar continuous testing expectations are appearing in EBA guidance, national supervisory priorities across the EU/EEA, and joint statements such as the Bank of England, FCA and HM Treasury joint statement on frontier AI models and cyber resilience. Non-eurozone banks with EU subsidiaries or branches typically face equivalent expectations through those entities.

The 31 October 2026 deadline: what is actually due

By 31 October 2026, each significant institution must submit a comprehensive action plan to its Joint Supervisory Team. The letter is explicit that the action plan should build upon the bank's existing cyber-risk strategy and address both immediate priorities and longer-term structural aspects. Annex 1 identifies six focus areas the action plan should cover: four short-term and two structural.

The action plan itself must contain, per the letter, "concrete measures to strengthen relevant controls, allocating the necessary resources, assigning clear roles and responsibilities, and defining timelines for implementation". The expectation is a credible plan with named ownership and budget, not a fully implemented programme by the deadline.

Short-term focus areas (Annex 1, areas 1-4)

1. Prioritise the protection of potential attack surfaces.

Identify ICT assets including third-party software and open-source components; minimise and continuously monitor internet-facing and externally exposed assets including cloud environments and VPN connections to third parties. The letter names perimeter technologies as the priority for early remediation, followed by cloud and on-premises environments, with a particular focus on ICT critical internal systems and security infrastructure. Threat vectors may originate from internal as well as external sources.

2. Accelerate vulnerability and patch management at scale.

Prioritised vulnerability validation to keep pace with the increasing speed and volume of vulnerability discovery. The letter permits AI-based approaches subject to prior assessment, human oversight and robust risk management. Preparation for more frequent, higher-volume patching becomes necessary as vendors, open-source communities and internally developed software all identify and remediate vulnerabilities faster. ICT change management arrangements should enable rapid, risk-based remediation while maintaining operational stability, with corresponding terms in ICT service provider contracts and SLAs.

3. Enhance monitoring, detection and AI-enabled defensive capabilities.

Strengthened monitoring of application and access logs, network traffic and other indicators, to improve detection of indicators of compromise and attempted exploitation, especially across internet-facing applications, cloud repositories and critical internal systems.

4. Strengthen governance, funding, awareness training and supply chain assurance.

Management bodies and senior management assess whether ICT budgeting, staffing, tooling and change capacity are sufficient. Training and awareness for employees, customers, counterparties, third parties and other stakeholders, calibrated to risk. Adequate supply chain assurance, including understanding of ICT service providers' preparedness for accelerated vulnerability disclosure and patching. Risk appetite frameworks reviewed to incorporate metrics and tolerance thresholds consistent with the evolving risk profile.

Structural focus areas (Annex 1, areas 5-6)

5. Reinforce defence-in-depth and cyber hygiene, modernise infrastructure.

A prudent security posture assumes perimeter defences will be breached. The letter names segmentation and micro-segmentation, zero-trust principles including continuous verification of users, devices, applications, APIs and service accounts. Strong baseline controls: accurate asset inventories, secure configuration, least-privilege access, multi-factor authentication, comprehensive logging. Security-by-design in software development. AI-native and AI-assisted defensive tooling subject to appropriate governance, validation and human oversight. Replacement or updating of legacy, unsupported or end-of-life technologies, or comprehensive compensating controls where replacement is not feasible.

6. Improve operational resilience, including crisis management, and information-sharing arrangements.

Robust and regularly tested crisis management, incident response, backup, failover, restoration and recovery arrangements aligned with DORA. Exercises covering high-speed, high-volume attack scenarios, broad compromise through zero-day vulnerabilities, ransomware or destructive attacks and supply chain or cloud service disruption. Secure frameworks for exchanging sensitive cyber information across institutions, including vulnerabilities, threat intelligence, defensive strategies and remediation approaches, leveraging existing trusted information-sharing arrangements.

What the JST does after submission

The letter states that the JST will further engage with the bank to discuss the action plan and monitor its progress. The ECB will additionally conduct a horizontal analysis of the submitted action plans to identify trends, challenges and areas for improvement, and share conclusions with significant institutions to strengthen sector-wide ICT resilience. Additional industry events or workshops may be organised depending on the outcomes of the analysis and developments in frontier AI. Submission on 31 October 2026 is the beginning of a supervisory dialogue, not its end.

ECB extension: IT Risk Questionnaire moved to February 2027

In recognition of the resource demands of the action plan, the ECB has extended the deadline for the annual IT Risk Questionnaire from September 2026 to February 2027. The letter notes that potential adjustments to other supervisory activities (on-site inspections, deep dives) will be considered on a case-by-case basis through the ongoing JST dialogue. This extension is a supervisory signal: the ECB is prioritising the action plan work and expects banks to redirect capacity accordingly.

What happens if a bank misses the 31 October 2026 deadline?

There are no direct fines for missing Letter SSM-2026-0301. This is one reason banks sometimes underestimate the supervisory instrument. The consequences flow through the Supervisory Review and Evaluation Process, which has real teeth.

How SREP works

SREP is the annual supervisory assessment the ECB performs on each significant institution, producing a bank-specific supervisory decision. It evaluates business model, governance, capital, and liquidity risks. Non-compliance with supervisory instruments feeds into the qualitative side of the assessment. The SREP outcome shapes the next 12 months of supervisory attention and directly affects capital requirements.

Pillar 2 capital add-ons

Where the SREP identifies material weaknesses in governance or risk management, the ECB can impose Pillar 2 capital add-ons: additional capital requirements above the Pillar 1 minimum. AI-cyber governance and the treatment of Letter SSM-2026-0301 sit squarely inside this scope. Capital add-ons are the most tangible financial consequence and land through the SREP decision rather than a fines regime.

Remediation orders and public disclosure

Under Article 16 of the SSM Regulation, the ECB can issue remediation orders requiring specific corrective action. Failure to remediate can lead to further supervisory measures including restrictions on distributions (dividends, share buybacks, variable remuneration). Persistent non-compliance can be publicly disclosed, either through the ECB's own communications or through the bank's Pillar 3 disclosures.

Reputational and market consequences

For listed banks, supervisory action typically becomes market-known through the SREP decision cycle. Analysts and investors track Pillar 2 requirements and remediation orders as a signal of governance quality. The reputational and market consequences of a supervisory finding often exceed the direct capital cost, which is why in-scope banks treat supervisory instruments as effectively mandatory.

How the letter connects to DORA, NIS2, TIBER-EU, and the EU AI Act

Letter SSM-2026-0301 does not stand alone. The letter itself opens by anchoring on DORA: "The requirements set out in the Digital Operational Resilience Act (DORA) remain highly relevant and valid in view of the impending change in the cybersecurity landscape." Analyst commentary from KPMG and A&O Shearman map the letter to DORA broadly (Articles 5 to 45), covering ICT risk management, patch management, and governance, not solely threat-led testing. Article 25 is the most relevant DORA overlap for continuous testing evidence specifically; the letter as a whole sits on the broader DORA ICT framework.

DORA: the broad continuous testing framework

Built on DORA: sharpens Article 25 focus on AI-class attacks; banks with DORA-compliant continuous testing programmes already have most of the evidence the action plan requires. In practice, banks with mature Article 25 continuous testing evidence typically need to extend scope (to AI-driven services), cadence (to trigger-based), and reporting (to map into the six Annex 1 focus areas). See continuous testing and DORA for the deeper framing on Article 25 obligations and TIBER-EU integration under Article 26.

TIBER-EU: the threat-led penetration testing overlap

TIBER-EU is the ECB's framework for intelligence-led red team exercises on critical financial infrastructure, referenced under DORA Article 26. It runs on a multi-year cadence and simulates real threat actors against production critical functions. The letter does not replace TIBER-EU; the two are complementary. Continuous testing evidence between TIBER-EU set-piece engagements is exactly what the letter's Annex 1 focus areas 2 and 3 (vulnerability and patch management at scale; monitoring, detection and AI-enabled defence) ask about.

NIS2: the parallel obligation for financial-market infrastructure

NIS2 (Directive (EU) 2022/2555) applies to essential and important entities across critical sectors, including some banks and financial market infrastructure operators. Article 21 requires cybersecurity risk-management measures including regular testing. Banks in NIS2 scope carry the ECB letter and NIS2 obligations in parallel. The evidence artefacts largely overlap: continuous testing evidence produced for the action plan also serves NIS2 audit needs. See NIS2 for financial institutions for sector-specific detail.

EU AI Act: obligations for banks shipping AI features

Banks deploying high-risk AI systems (credit scoring under Annex III, recruitment tooling) carry EU AI Act obligations in addition to the ECB letter. Article 15 requires appropriate levels of accuracy, robustness, and cybersecurity for high-risk AI systems. The letter focuses on the cyber-defence side: validating what an attacker can exploit in AI-driven services. The EU AI Act adds the model-side obligation: robustness against adversarial inputs, resilience against errors, and testing evidence at development and post-market monitoring stages.

ECB AI Cybersecurity Action Plan compliance stack - DORA, TIBER-EU, EU AI Act, NIS2 framework overlap

Step-by-step: how banks satisfy the action plan

Six operational steps from mapping to reporting, structured against the six Annex 1 focus areas. Written for a bank CISO scoping the programme.

Step 1: Assign a named owner at executive level

The letter requires "assigning clear roles and responsibilities". Typical accountability sits with the CISO or Chief Risk Officer, senior enough to sign off on the budget and testing plan and to represent the bank in JST supervisory conversations. Formalise the appointment in writing, with a memo to the board and a line item in the bank's governance framework. The action plan submission needs named ownership; functional accountability without a named individual will not satisfy the JST.

Step 2: Scope the AI-cyber threat landscape against the six focus areas

Map the bank's exposure surface across four layers: customer-facing AI (chatbots, virtual assistants, RAG-powered search), internal AI (copilots, RAG document search, agentic workflows), AI features embedded in commercial products (fraud detection, KYC, credit scoring), and third-party AI dependencies under DORA Article 28. Cross-reference the mapping to the six Annex 1 focus areas so the action plan speaks to each area explicitly. Missing internal RAG copilots and third-party AI dependencies is the most common scoping gap.

Step 3: Budget for continuous testing evidence

Allocate budget across three testing modalities: continuous exploitability validation (adversarial exposure validation on the application layer of AI-driven services), control efficacy validation (breach and attack simulation against detection and response), and set-piece testing (TIBER-EU intelligence-led red team on the multi-year cadence). The letter's focus area 4 (governance, funding) asks management bodies to assess whether ICT budgeting, staffing, tooling and change capacity are sufficient. Under-budgeting is a common finding; supervisors have data on peer institutions and calibrate accordingly.

Step 4: Implement continuous testing evidence

Continuous testing means dated findings with reproducible proof, produced at a cadence that matches the pace of AI-service change. Adversarial exposure validation runs continuous adaptive attacks on the customer-side application layer of AI-driven services, validating what attackers can exploit with reproducible proof of exploit for every validated vulnerability. Breach and attack simulation runs continuous scenarios against controls. Both feed a live evidence stream. TIBER-EU sits above them on a set-piece cadence.

Step 5: Produce and store evidence

Evidence is a queryable audit trail, not a folder of PDFs: dated validated vulnerabilities, mapped to specific controls, with proof of exploit attached, tracked through remediation and retest, and mapped back to DORA and (where applicable) NIS2 and EU AI Act obligations. Modern compliance-reporting workflows produce this natively. Ad-hoc spreadsheet management does not satisfy the reproducibility expectation supervisors ask about.

Step 6: Report to the JST and integrate into DORA ICT risk management

The action plan submission feeds the SREP. Integrate it into the bank's DORA ICT risk-management framework rather than treating it as a parallel report. The JST reviews the submission against the wider DORA framework, TIBER-EU cycle status, and any NIS2 or EU AI Act evidence. Integration reduces reporting overhead and reduces the risk of contradictory evidence across supervisory frameworks. Fragmented reporting is another common finding.

Common mistakes banks make with the action plan

Five patterns show up repeatedly in early JST feedback and in analyst commentary on peer banks' submissions. Avoiding these is easier than fixing them post-SREP.

Mistake 1: Treating it as a checkbox

Letter SSM-2026-0301 asks for a functioning continuous programme, not a submitted document. Banks that treat 31 October 2026 as a compliance filing (submit and forget) will find the JST returning across the SREP cycle asking for six months of evidence. The letter commits the ECB to horizontal analysis and continued JST engagement, so the deadline is the beginning of supervisory visibility, not the end.

Mistake 2: Scoping too narrowly

Scoping only public-facing AI (the chatbot on the retail app) and missing internal RAG copilots, model-serving APIs for internal decisioning, third-party AI dependencies under DORA Article 28, and AI features embedded in commercial products. The letter's Annex 1 area 1 (attack surface protection) explicitly asks for identification of ICT assets "including third-party software and open-source components". Broad scoping is safer than narrow.

Mistake 3: Point-in-time testing

Submitting evidence of a single annual pentest is insufficient. The letter asks for continuous defensive measures against AI-class attacks; annual snapshots do not match the pace of AI-driven attacker capability nor the pace of the bank's own AI-service change. Supervisors treat point-in-time evidence as a signal of programme immaturity, not compliance sufficiency.

Mistake 4: No accountable owner

Distributing accountability across a security committee or "the CISO's team" without a named individual. The letter explicitly requires "assigning clear roles and responsibilities". Committee-level accountability without a designated owner reads to the JST as absence of governance rather than sophistication.

Mistake 5: Parallel to DORA rather than integrated

Reporting the action plan as a separate exercise from the bank's DORA ICT risk-management framework. Letter SSM-2026-0301 is built on DORA and expects integration. Parallel reporting produces contradictory evidence, doubles operational overhead, and misses the strategic point that the letter sharpens focus on AI-class attacks within an existing framework rather than introducing a new one.

Approaches compared: how banks produce continuous testing evidence

Four approaches produce evidence that supports the action plan. Most banks combine two or three, aligned to the specific Annex 1 focus areas each best addresses.

Adversarial exposure validation (AEV)

AEV runs continuous adaptive attacks on the application layer of AI-driven services, producing reproducible proof of exploit for every validated vulnerability. Purpose-built agentic AI pentesters chain vulnerabilities dynamically, generate payloads on the fly, and adapt to context. Output is a dated evidence stream mapped to specific controls. AEV maps most directly to Annex 1 area 2 (vulnerability and patch management at scale) and area 3 (monitoring, detection and AI-enabled defensive capabilities). See AI security testing for the specific application-layer scope.

Breach and attack simulation (BAS)

BAS runs library attack techniques (typically mapped to MITRE ATT&CK) against the bank's control stack (EDR, SIEM, SOAR, email security) and scores control efficacy. BAS maps to Annex 1 area 3 (monitoring, detection and AI-enabled defensive capabilities). It complements AEV: BAS validates whether controls would catch a technique; AEV validates whether attackers can exploit exposure. Together they cover control efficacy and exposure validation. See the CTEM vs BAS piece for the detailed comparison.

Manual pentesting and internal red team

Manual pentesting delivers depth on specific bespoke scenarios and creative attacks that automation cannot yet reach. It runs on scoped engagements rather than continuously, which fits set-piece validation and depth-critical investigations, but does not by itself satisfy the letter's expectation for continuous evidence across the six focus areas. Most banks pair manual with continuous mechanisms. See the Manual vs Automated Pentesting piece for the tradeoff structure.

TIBER-EU threat-led penetration testing

TIBER-EU is the ECB framework for intelligence-led red team exercises on critical functions, referenced under DORA Article 26. It runs on a multi-year cadence and simulates real threat actors end-to-end. It is what Letter SSM-2026-0301 complements rather than replaces: the letter asks for continuous evidence between TIBER-EU engagements, addressing the gap between multi-year set-pieces and the machine-speed velocity the ESRB warning documents. Banks under TIBER-EU cycles carry both obligations and typically align budgets across the two.

How Ethiack helps banks meet the ECB AI Cybersecurity Action Plan

This is the section where Ethiack sits explicitly, applied to the specific parts of the action plan Ethiack's platform addresses. Scope is applied honestly, including what Ethiack does not cover.

What Ethiack covers

Ethiack runs continuous adaptive AI-driven attacks on the application layer of AI-driven services with reproducible proof of exploit for every validated vulnerability. Purpose-built agentic AI pen testing through Hackian chains vulnerabilities, generates payloads on the fly, and adapts to context. Every validated vulnerability ships with the payload, the evidence, and mitigation guidance. False-positive rate below 0.5% (Ethiack-reported); 30x faster than manual pentesting on the same surface (Ethiack-reported). Dated per validated vulnerability, mapped to specific controls, ready for the JST evidence pack. This maps to Annex 1 focus areas 1 (attack surface protection), 2 (vulnerability and patch management at scale), and 3 (monitoring, detection and AI-enabled defence).

The scope guardrail (what Ethiack does not test)

Ethiack tests the customer-side application layer of AI-driven services (chatbots, RAG applications, AI agents on customer infrastructure) and third-party integrations reachable from the customer's surface. Ethiack does not test AI models themselves: weights, training data, model internals. For Letter SSM-2026-0301, this covers the exploitability side of the six focus areas. Banks with high-risk AI systems under the EU AI Act (Article 15 obligations on model robustness and accuracy) should pair Ethiack with a model-testing specialist.

Compliance evidence and EU sovereignty

The evidence Ethiack produces is designed for supervisory review: reproducible proof of exploit dated per validated vulnerability, mapped to DORA controls, integrated into the adversarial exposure validation compliance workflow. All data storage and processing occur exclusively in the EU, on servers in Belgium; structural, not contractual. Especially relevant for eurozone banks under Letter SSM-2026-0301, and for banks looking to close the EU sovereignty question the JST sometimes raises during SREP conversations. See Ethiack for financial services.

See what a real AI-driven attack validates on your bank's AI services. Ethiack runs an external test in 24 hours with reproducible proof of exploit for every validated vulnerability, and packages the output for your JST evidence pack. Book a demo aligned to Letter SSM-2026-0301 and the six focus areas, or run a free external test to see the output format first.

Frequently asked questions about ECB AI Cybersecurity Action Plan

What is the ECB AI Cybersecurity Action Plan?

The ECB AI Cybersecurity Action Plan refers to Letter SSM-2026-0301, "Addressing AI-enabled cybersecurity threats", signed by Claudia Buch, Chair of the ECB Supervisory Board, dated 7 July 2026. It requires significant institutions to submit a comprehensive action plan by 31 October 2026 covering six focus areas set out in Annex 1. It is not a regulation with fines; it is a supervisory instrument built on DORA.

When is the ECB AI Cybersecurity Action Plan deadline?

The deadline is 31 October 2026. By that date, in-scope significant institutions must submit their comprehensive action plan to their Joint Supervisory Team, covering the six Annex 1 focus areas with concrete measures, resources, roles, responsibilities, and timelines. Banks are not expected to have completed implementation by that date, but they are expected to have committed and started.

Is the ECB AI Cybersecurity Action Plan mandatory?

Letter SSM-2026-0301 is a supervisory instrument, not a regulation. Non-compliance does not trigger immediate fines. It feeds into the Supervisory Review and Evaluation Process, which can lead to Pillar 2 capital add-ons, remediation orders, restrictions on distributions, and reputational exposure. In practice, in-scope significant institutions treat it as mandatory.

Does the ECB AI Cybersecurity Action Plan apply to my bank?

Letter SSM-2026-0301 is addressed directly to significant institutions supervised by the ECB (typically banks with more than €30 billion in assets, cross-border operations, or top-3 status in a Member State). Similar expectations are widely anticipated to extend to less significant institutions through national competent authorities, with some NCAs already issuing parallel guidance. Non-eurozone banks are not in direct scope.

What are the six focus areas of the ECB action plan?

Annex 1 of Letter SSM-2026-0301 identifies six focus areas. Short-term: (1) attack surface protection, (2) vulnerability and patch management at scale, (3) monitoring, detection and AI-enabled defensive capabilities, (4) governance, funding, training and supply chain assurance. Structural: (5) defence-in-depth and infrastructure modernisation, (6) operational resilience and information sharing.

What are the penalties for missing the 31 October 2026 deadline?

No direct fines. Consequences flow through the SREP: Pillar 2 capital add-ons, remediation orders under Article 16 of the SSM Regulation, restrictions on distributions, and public disclosure of supervisory findings in some cases. Reputational and market consequences are typically the largest cost, which is why in-scope banks treat the 31 October 2026 deadline as effectively mandatory.

How does Letter SSM-2026-0301 relate to DORA?

Built on DORA: sharpens Article 25 focus on AI-class attacks; banks with DORA-compliant continuous testing programmes already have most of the evidence the action plan requires. The letter itself is anchored on DORA broadly (analyst commentary maps it to DORA Articles 5 to 45, not Article 25 alone), covering ICT risk management, patch management, governance, and testing. Article 25 is the most relevant overlap for continuous testing evidence specifically.

What evidence do banks need for the 31 October 2026 deadline?

The action plan must contain, per the letter, concrete measures to strengthen relevant controls, allocating necessary resources, assigning clear roles and responsibilities, and defining timelines for implementation, across all six Annex 1 focus areas. Adversarial exposure validation produces the continuous testing evidence type that supports focus areas 2 and 3 directly, dated per validated vulnerability with reproducible proof of exploit.

Does the ECB AI Cybersecurity Action Plan apply to non-eurozone banks?

Not directly. Letter SSM-2026-0301 is addressed exclusively to CEOs of eurozone significant institutions. Non-eurozone European banks (UK, Nordics, Switzerland) are supervised by their national authorities. However, similar continuous testing expectations are appearing in EBA guidance, national supervisory priorities across the EU/EEA, and joint statements such as the Bank of England, FCA and HM Treasury joint statement on frontier AI models and cyber resilience. Non-eurozone banks with EU subsidiaries face the requirement through those entities.

How does the action plan connect to TIBER-EU?

TIBER-EU is the ECB's threat-led penetration testing framework, referenced under DORA Article 26. Letter SSM-2026-0301 does not replace TIBER-EU; it complements it. TIBER-EU covers the multi-year intelligence-led red team set-piece; the action plan asks for continuous testing evidence between TIBER-EU engagements to address the machine-speed velocity documented in ESRB Warning ESRB/2026/3. Both feed the SREP evidence pack.

Is continuous testing required by the ECB AI Cybersecurity Action Plan?

Continuous testing is not written into the letter word-for-word, but the six Annex 1 focus areas (particularly area 2 on vulnerability and patch management at scale, and area 3 on monitoring, detection and AI-enabled defence) implicitly require continuous mechanisms. Supervisors treat point-in-time pentesting as insufficient evidence against AI-class attacks that ship continuously. The practical answer is yes: banks need continuous testing evidence, produced by adversarial exposure validation, breach and attack simulation, or an equivalent continuous mechanism.

Where does the EU AI Act fit into the ECB action plan?

The EU AI Act (Regulation (EU) 2024/1689) applies to banks deploying AI systems, particularly high-risk systems (credit scoring, recruitment). Article 15 requires appropriate levels of accuracy, robustness, and cybersecurity for high-risk AI. Letter SSM-2026-0301 sharpens this on the cyber-defence side: banks must not only ship compliant AI systems but continuously validate their exploitability from an attacker's perspective as part of the six focus areas.