Banks’ AI-cyber plans are due Saturday. Your questionnaire may be next.

Banks’ AI-cyber plans are due at the ECB by Saturday

On 7 July 2026 the ECB’s banking supervisors sent one letter to the CEO of every significant institution they supervise directly. It asks each bank to give its Joint Supervisory Team (JST) a comprehensive action plan for AI-enabled cybersecurity threats by 31 October 2026, which falls on Saturday [1].

This issue walks through what that plan has to contain, the six focus areas the ECB lists in Annex 1, and the DORA articles that already sit behind them [1][2]. Then it turns to the part that matters if you sell to banks. Our read (inference): the questions in those plans will flow down to MSPs, software vendors and ICT third parties. The letter itself is addressed to banks only.

One letter, every significant bank

The letter carries reference SSM-2026-0301, is dated 7 July 2026 in Frankfurt am Main, and is signed by Claudia Buch, Chair of the ECB Supervisory Board [1]. It is addressed “To the CEO of the significant institution”, so it lands with the chief executive of every bank the ECB supervises directly, not only with the security team. The subject is “Addressing AI-enabled cybersecurity threats”.

The ask is simple to state: submit an action plan to your JST by 31 October 2026. Two annexes follow. Annex 1 sets out six focus areas, with specific actions that are “provided for consideration”, and Annex 2 points to international guidance [1].

Why now: the gap between a bug and its exploit is closing

The ECB says emerging AI models can identify software vulnerabilities and generate “functioning exploits at unprecedented speed, compressing the timeline between vulnerability discovery and exploitation” [1]. It does not treat this as a brand-new risk. It calls it “a long-term shift in the threat landscape rather than a temporary phenomenon or a risk tied to any single tool” [1]: familiar risks, arriving faster and at greater scale.

The European Systemic Risk Board puts the gap in plain terms. Weaponising an exploit used to take human experts “days or weeks”; frontier AI models can now do it in “minutes or hours”, which it calls a “collapse of defensive time buffers” [3]. Banks may then have to choose between staying exposed and cutting patch testing [3]. The timeline on the slide is illustrative, not to scale.

Four dates that set the pace

The ESRB adopted its warning on frontier AI cyber risk on 25 June 2026 [3]. The ECB letter followed on 7 July, noting that the ESRB warning was published the same day [1]. The action plan is due at the JST on Saturday 31 October 2026. To let banks “prioritise their efforts and focus resources on the relevant key areas”, the ECB also moved the annual IT Risk Questionnaire collection from September 2026 to February 2027 [1].

After submission, the JST will discuss each plan and monitor progress, the ECB will run a horizontal analysis and share its conclusions with banks, and other supervisory work such as on-site inspections or deep dives may be adjusted case by case [1]. None of these follow-up steps has a date. The 116-day count from letter to deadline is our own arithmetic.

What the plan must contain

The letter says DORA’s requirements “remain highly relevant and valid”, and in line with them asks banks to assess the impact of the evolving threat landscape without delay [1]. The plan then needs four building blocks: concrete measures to strengthen relevant controls, the necessary resources, clear roles and responsibilities, and timelines for implementation.

It should cover both immediate priorities and longer-term strategic aspects, and build on the bank’s existing cyber-risk strategy rather than start from scratch. Alongside the plan, the ECB wants open supervisory findings in the ICT areas in focus addressed without delay, including those from on-site inspections, targeted reviews and the 2024 cyber-resilience stress test [1]. Responsibility sits primarily with the management body, which may need to revisit ICT investment, resource allocation and ICT risk tolerance frameworks [1].

The plan map: six focus areas from Annex 1

Annex 1 groups the suggested actions into six focus areas [1]. Four are short-term priorities: protecting attack surfaces, including third-party software and open-source components; vulnerability and patch management at scale; monitoring and detection, including AI-enabled defensive capabilities; and governance, funding, training and supply-chain assurance.

Two are structural. Defence-in-depth and cyber hygiene covers assume-breach thinking, segmentation, zero trust and replacing legacy or end-of-life systems. Response and recovery covers crisis management, backup, failover, exercises and information sharing. The ECB says protecting perimeter and internet-facing assets is “key to preparing for the rise in AI-enabled cybersecurity threats” [1]. Note the wording on the annex: its specific actions are “provided for consideration”.

Protect the edge first, then work inward

Annex 1 also suggests an order for remediation [1]. Prioritising perimeter technologies “helps safeguard the most exposed assets”, and can be followed by cloud and on-premises environments, with a particular focus on critical internal systems and ICT security infrastructure.

What counts as exposed is broad: internet-facing and externally exposed assets, cloud environments, VPN connections to third parties, and third-party software and open-source components [1]. Our read: if you are a supplier with a VPN link into a bank, or software running on its perimeter, you sit in the first ring. The letter also notes that threat vectors may originate from internal sources, not only external networks [1], so the inner rings still matter.

The legal hook is DORA

The letter cites DORA as a whole [1]. The article-by-article mapping on this slide is our reading of the EUR-Lex text [2], not ECB wording.

Article 5(2)(a) puts ultimate responsibility for ICT risk on the management body. Article 8 asks banks to identify and classify assets, map the critical ones and document processes that depend on ICT third-party providers. Article 9(4)(e) and (f) cover controlled ICT change management and documented patch and update policies. Article 10 requires mechanisms to promptly detect anomalous activity. Article 28(1)(a) keeps the bank fully responsible when it uses ICT services, and Article 30 sets out what contracts with ICT providers must contain [2]. Our read: much of what the ECB asks for already has a legal hook.

How Saturday’s plan flows down the supply chain

Two Annex 1 passages point outward [1]. Under area 2, rapid, risk-based change arrangements “should also be reflected in contractual terms and service level agreements when an ICT service provider is involved.” Under area 4, banks “remain exposed to, and fully accountable for, risks stemming from outsourced ICT services”, and supply-chain assurance should include an understanding of providers’ “preparedness for accelerated vulnerability disclosure and patching.”

Inference: put those next to DORA Articles 28 and 30 [2] and we expect banks to push the plan down the chain, with questionnaires to ICT providers, contract changes for MSPs and their subcontractors, and questions about open-source components. The letter goes to banks only. This flow-down is Killswitch analysis, not a direct ECB requirement on suppliers.

The questions heading to suppliers

What might arrive in your inbox? The slide turns each Annex 1 area, plus two DORA articles, into a plain-English supplier question [1][2]. It is illustrative, not an ECB form, and your bank clients’ wording will differ.

Expect questions on which third-party and open-source components sit inside what you supply, which of your services face the internet or connect over VPN, how fast you can ship a critical fix and what your emergency change path is, and whether you have the staff for more frequent, higher-volume patching. Others may cover which logs you can share to detect attempted exploitation, how ready you are for accelerated vulnerability disclosure, what in your stack is legacy or end-of-life, and whether you will join supply-chain or cloud-disruption exercises, plus threat-led penetration testing where it covers your service (DORA 30(3)(d), critical or important functions).

Contract clauses to expect: they are already in DORA

Many contract terms a bank may ask for are already written into DORA Article 30 [2]. For ICT services supporting critical or important functions, Article 30(3) calls for service levels with precise quantitative and qualitative performance targets, notice periods and reporting obligations, tested business contingency plans and ICT security measures, and participation in the bank’s threat-led penetration testing. Article 30(2) covers ICT contracts generally, including incident assistance at no additional cost or at a cost set in advance, and whether subcontracting is permitted and on what conditions.

The grey line under each clause on the slide is Killswitch’s advice, not ECB or DORA text: for example, add a patch SLA by severity and exposure. The ECB sets no patch-time number, so any figure is one you and your client agree.

Supplier checklist: get ahead of your bank clients

This is Killswitch guidance for MSPs, vendors and ICT third parties, built from Annex 1 [1] and DORA Articles 8, 9, 28 and 30 [2]. It is not legal advice.

Eight steps: build a component list, including open source, for each service you sell to banks; inventory every internet-facing endpoint and every VPN link into a client; write a patch SLA by severity and exposure, plus an emergency change path; check you have the people to patch more often, at higher volume; decide which logs you can share and how fast; document how you would handle a sudden wave of vulnerability disclosures; flag legacy and end-of-life components with a replace-or-protect date; and price incident support and name a contact for exercises and TLPT. The aim is to have answers and evidence ready before the questionnaire lands.

Sources and what we could not confirm

Every claim in this issue traces to the sources listed at the end. Some things we could not confirm, and we say so. What each bank actually submitted is not public, and nothing here describes a real plan. The letter sets no patch-time number. Less significant institutions are not addressed; A&O Shearman expects national supervisors to follow [4], which is opinion, not confirmed. No date is given for the ECB’s horizontal analysis or for JST follow-up.

The supplier flow-down and the DORA article mapping are Killswitch analysis, not ECB text. Quotes were checked word for word against the official ECB letter text, and this issue cites no page numbers. AI model names and the “four months” framing seen in press and law-firm coverage are not in the letter; the 116-day count is our arithmetic.

Saturday is the banks’ deadline. Get your answers ready now.

The banks’ plans go in on Saturday. Our read: follow-up questions to suppliers come after that, and the suppliers who already hold the evidence will answer fastest. Start with the checklist on slide 12 and the contract clauses on slide 11.

If you want more, there are four places to go next. Subscribe free at killswitch.work for security, AI security and GRC briefings, each with its full slide deck. Try the live GRCompliance demo. If you prefer to run it yourself, GRCompliance Core installs free from GitHub and is self-hosted. And Sectutor has security books and kits for teams building these skills. This issue is not legal advice, so check your own contracts and your bank clients’ actual requests.

Next steps

About the author. Emmanuel Aigbehi Walstra is a CISO who also serves as a virtual CISO (vCISO) for several organisations, with 30+ years in cybersecurity, 10,000+ people trained, and author of the CCSP Excellence books.

Sources

1. ECB Banking Supervision, letter SSM-2026-0301, “Addressing AI-enabled cybersecurity threats”, 7 July 2026 (incl. Annex 1–2). www.bankingsupervision.europa.eu/press/letterstobanks/shared/pdf/2026/ssm.2026_letter_on_AI_enabled_cybersecurity_threats.en.pdf
2. Regulation (EU) 2022/2554 (DORA), OJ L 333, 27.12.2022, Arts 5, 8, 9, 10, 28 and 30. data.europa.eu/eli/reg/2022/2554/oj
3. ESRB, Warning of 25 June 2026 on systemic cyber risks stemming from frontier artificial intelligence models (ESRB/2026/3), OJ C/2026/3795, 16.7.2026. www.esrb.europa.eu/pub/pdf/warnings/esrb.warning260625_on_systemic_cyber_risks_stemming_from_frontier_ai_models~ef424708cf.en.pdf
4. A&O Shearman, “ECB requires significant institutions to address AI-enabled cybersecurity threats”, 9 July 2026. Secondary source, used for corroboration only. www.aoshearman.com/en/insights/ecb-requires-significant-institutions-to-address-ai-enabled-cybersecurity-threats

Not legal advice. Where we infer, we say so: lines marked “Our read” or “Inference” are Killswitch analysis, not ECB or DORA text.