← Blog

The ECB Gave 110 Banks Until October 31 to File AI Cyber Plans: What Supervisors Will Inspect

On July 7, 2026 the ECB Supervisory Board wrote to the 110 banks it directly supervises and gave them until October 31 to submit plans against AI-enabled cyber threats. This walks the ECB asks item by item, separates the ones a policy gateway produces evidence for from the ones it has nothing to do with, and describes what a supervisor will actually inspect in the filing.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Industry Verticalsai-securityai-compliancedoraregulationai-governanceaudit
The ECB Gave 110 Banks Until October 31 to File AI Cyber Plans: What Supervisors Will Inspect

On July 7, 2026 the Supervisory Board of the European Central Bank wrote to the 110 banks it directly supervises and set a deadline. By October 31, each bank has to submit a plan describing how it will address AI-enabled cyber threats. Bloomberg and Euronews reported the letter the same day, and American Banker summarized the ask as "fix AI cyber gaps by Oct. 31." The ECB framed the newest models as a long-term shift in the threat landscape rather than a temporary spike, and it moved its annual IT Risk Questionnaire from September 2026 to February 2027 to give banks room to respond.

I want to walk the ECB's asks item by item, because the letter is broad IT-resilience guidance and only part of it touches the AI request layer where a policy gateway operates. I will be direct about which asks a gateway has nothing to do with, and which ones it produces the exact evidence a supervisor will ask to see.

The letter and the deadline

The ECB directly supervises roughly 110 significant institutions across the eurozone under the Single Supervisory Mechanism. The July 7 letter went to all of them. It is supervisory correspondence rather than a new regulation, which matters for how banks should read it: this is the ECB telling its own supervised population what it expects to inspect, and the October 31 filing is the artifact it will inspect against.

The June 3, 2026 speech from the ECB, "Strengthening operational resilience for the age of AI," set up the letter. The specific asks in the correspondence, as reported by American Banker and Euronews, cover faster vulnerability and patch management, stronger monitoring and detection, closer scrutiny of third-party technology providers and supply-chain risk, modernization of legacy technology, and better crisis-management and information-sharing. That is five workstreams. Only two of them sit anywhere near AI request traffic.

The asks a gateway has nothing to do with

I will name these plainly so the rest of the article stays honest. Three of the ECB's five asks are outside the boundary of an AI policy gateway.

Faster vulnerability and patch management is a cadence and tooling problem across your whole estate. A proxy on AI traffic does not shorten your patch window. Legacy technology modernization is a multi-year architecture program that has nothing to do with LLM calls. Crisis management and information-sharing is an organizational capability built on runbooks, ISAC membership, and tabletop exercises. A bank that files a plan claiming an AI gateway addresses these three is going to lose credibility with its Joint Supervisory Team on the first read.

Say what each control actually covers. When the filing describes patch management, it should describe patch management. Padding those sections with AI-gateway language reads as vendor influence, and supervisors have seen enough of it to discount it.

The two asks where AI request evidence is the point

Two of the ECB's asks land on the AI request layer.

The first is scrutiny of third-party technology providers and supply-chain risk. Every large bank in the eurozone now routes some inference through OpenAI, Anthropic, Azure OpenAI, or Amazon Bedrock, often more than one at once. Those are third-party technology providers in the exact sense the letter means. Supervisors will want to know which model providers process what categories of data, under what contractual terms, and with what evidence that the bank supervises the relationship continuously rather than at procurement time. This connects directly to the ICT third-party register work that DORA already requires of EU banks.

The second is monitoring and detection. The ECB wants to see that a bank can observe what its systems are doing, and AI request traffic is a data channel most monitoring stacks are blind to. Network DLP inspects encrypted web traffic and cannot read the prompt. A gateway that terminates the AI request and records who sent what to which model closes that specific observability gap.

What a supervisor will inspect in the filing

A plan is a document. A Joint Supervisory Team will test it against operational reality in follow-up review, so the filing has to describe controls that produce inspectable evidence.

For the third-party provider ask, the inspectable artifact is a record, per AI request, of the model provider called, the data classification involved, and the identity that authorized the call. For the monitoring ask, the inspectable artifact is a decision log a supervisor can read without trusting the application that generated it. The self-attestation problem applies here with full force: a record written by the system under review is weaker evidence than a record written by an independent decision point. A bank that can produce a signed, identity-bound record for every model call has answered the monitoring and third-party asks with evidence rather than narrative. This aligns with the EU AI Act Article 12 traceability requirement the same banks are already mapping.

DeepInspect

This is the gap DeepInspect closes for the two in-boundary asks. DeepInspect is a stateless proxy at the AI request boundary. It binds every model call to the natural-person or agent identity the application supplies, classifies the prompt content against the regulated categories a bank recognizes, applies per-route and per-role policy, and commits a signed per-decision audit record before the response returns.

For the October 31 filing, that produces two inspectable artifacts a Joint Supervisory Team can request. The third-party provider record names which model provider handled which class of data under which identity, on a continuous basis rather than at contract signing. The monitoring record is an independent decision log the bank does not have to reconstruct after the fact. Neither of these addresses patching, legacy modernization, or crisis management, and the filing should be explicit about that division so the AI section reads as precise rather than oversold.

If you are one of the 110 banks writing this plan before October 31, let's talk today.

Frequently asked questions

What did the ECB actually send on July 7, 2026?

The ECB Supervisory Board sent a letter to the roughly 110 significant institutions it directly supervises under the Single Supervisory Mechanism. The letter asks each bank to submit, by October 31, 2026, a plan describing how it will address AI-enabled cyber threats. The asks span faster vulnerability and patch management, stronger monitoring and detection, closer scrutiny of third-party technology providers and supply-chain risk, legacy technology modernization, and improved crisis management and information-sharing. The ECB also moved its annual IT Risk Questionnaire from September 2026 to February 2027, reported by Bloomberg and Euronews on July 7.

Is this a new regulation?

No. It is supervisory correspondence from the ECB to its directly supervised banks, not a legislative instrument. It carries weight because the ECB inspects against its own stated expectations through the Joint Supervisory Teams. The October 31 plan becomes the artifact supervisors measure the bank against in subsequent review, so the practical effect on a supervised bank is close to a binding requirement even though it is not law in the way DORA or the EU AI Act are.

Which ECB asks does a policy gateway address?

Two of the five. Scrutiny of third-party technology providers maps to recording which model provider processes which data class under which identity, continuously. Monitoring and detection maps to producing an independent, inspectable log of AI request decisions. The other three asks, patch management, legacy modernization, and crisis management, sit outside the AI request layer and should be addressed by the controls that actually own them. A filing that claims a gateway covers all five will not survive supervisory review.

How is this different from DORA compliance?

DORA's ICT third-party risk regime owns the register of critical providers, the exit-strategy mandate, and the concentration-risk test, which I covered separately. The July 7 ECB letter is narrower and time-boxed: it asks for a specific plan against AI-enabled threats by October 31, 2026, and it tells you what supervisors will inspect this cycle. A bank that has done its DORA register work has a head start on the third-party section of the ECB filing, because the model-provider inventory is the same underlying data.

What evidence should the October 31 filing point to?

For the in-boundary asks, point to per-request records rather than policy statements. A supervisor testing the third-party section will ask what proves the bank supervises its model providers continuously, and a per-request record of provider, data class, and authorizing identity answers that. A supervisor testing monitoring will ask what the bank can show about AI request activity without trusting the application that generated the traffic, and an independent signed decision log answers that. Narrative alone tends to generate follow-up questions the bank then has to answer under time pressure.