Along with the Bank of England in May, the ECB is requiring organisations to produce an action plan against AI-driven cyberattacks (opens in a new tab). What it wants, however, is not a strategy paper but proof of operational readiness:
On 7 July, ECB Banking Supervision sent a letter to around 110 financial services organisations. The instruction: submit a dedicated action plan against AI-driven cyberattacks by 31st October 2026. That the ECB is taking up the topic surprises no one. What is striking is how specific it has become. A mere strategy paper response is no longer enough; what is required is proof of operational capability. This is identified as a must in patching pace. Where three months once seemed defensible for closing a vulnerability, what counts today is a response within hours. And accountability for it rests with the management board. It is no longer optional.
The letter was deliberately addressed to senior management, not to the IT department. It is accompanied by a warning from the ESRB of 25th June about systemic cyber risks arising from AI models, and at the same time the supervisor has postponed the annual IT risk questionnaire. The signal is unmistakable: this topic is now a Board level concern.
The basis of the action plan
The required action plan doesn't require a new rulebook. It makes concrete what DORA already requires, only with a markedly higher demand for speed and verifiability. Regulation (EU) 2022/2554 on digital operational resilience has been fully applicable since 17th January 2025. It consolidates the financial sector's resilience into five pillars: the management of ICT risk, the handling and reporting of ICT-related incidents, the testing of digital resilience, the management of third-party risk and information sharing.
The AI cyber action plan is not a reinvention. It requires three of these pillars to be sharpened under the pressure of AI-driven attacks: ICT risk management (Do I know what I have to protect? How quickly can I respond?), resilience testing (Do my assumptions hold up under real stress?), and third-party risk (How dependent am I, and on whom?). Those who have already taken DORA seriously do not have to start from scratch. Those who treated it as a mere documentation exercise will now feel where the gaps are.
How the supervisor will assess implementation
The relevant Joint Supervisory Team will not read the wording of the document; it will however examine the substance behind it. Four things separate a robust plan from a mere declaration of intent:
- Tangible measures instead of principles: The plan must show which systems are affected, in what order they will be addressed, and which target values apply. Vague intentions to improve are not enough.
- Named individuals, not just committees: What is required is the appointment of a person who owns the plan. Equipped with a real mandate, not merely with responsibility.
- Allocated resources: Budget and staff, visibly committed rather than vaguely promised.
The fourth element is at the same time the decisive question: can you prove what you claim? Here, proving means being able to furnish three pieces of evidence on request:
- On patching pace: an analysis that shows, for the most recently disclosed critical vulnerabilities, how many hours or days elapsed between disclosure and full-fleet patching. It should present the figures as a distribution and over time, with timestamps. A rounded average will not satisfy the supervisor. For example: 95% of critical CVEs were closed within 72 hours.
- On asset transparency: a reconciliation between the inventory actually discovered and your CMDB that makes the difference visible. It shows how many endpoints, servers, and cloud workloads exist that appear on no official list, and by what means you track down these unmanaged and outdated systems. The discrepancy itself is the most telling piece of evidence.
- On progress: a report you can generate at short notice, i.e. within minutes and from a single data source, dated and traceable. If the JST asks today, the answer should be ready and not have to be pieced together manually from various systems first.
The common denominator: figures with timestamps, from a reliable source, reproducible at any time.
Where the difficulties lie in practice
The requirements sound self-evident. That many institutions are likely to struggle with them is not a matter of will, but of structures that have grown over time. Five patterns recur again and again:
- A fragmented tool landscape: Inventory, vulnerabilities, patching and reporting are spread across separate solutions. Every question from the supervisor turns into a data-gathering exercise across system boundaries.
- A CMDB that lags behind: The configuration database reflects the target state, not the actual one. Between reality and the database lies a gap that no one can close in real time.
- Blind spots. Unmanaged devices, shadow IT and outdated systems don't appear on a list. They are precisely the entry points attackers focus on.
- Separate worlds of IT and Security: Whoever finds a vulnerability is often not the one who closes it. Every handover costs time that today is in short supply.
- Dependence on the maintenance window: When AI produces exploits in hours, reactive, periodic patch cycles are no longer enough.
On top of this: many organizations still produce the evidence for the supervisor manually, using spreadsheets that someone assembles overnight. This is neither repeatable nor robust and it does not scale should the JST ask at short notice.
The organisations that succeed will be those that see the deadline not as a tiresome compliance exercise but as a catalyst to implement the automation and operational changes that are long overdue.
Your roadmap for the coming weeks
In the short time until 31st October, what matters is what underpins the plan operationally:
- Establish your complete inventory. Obtain a complete, real-time overview of all endpoints, servers and cloud workloads, including the unmanaged and outdated systems. Reconcile the result with your CMDB, because the difference will be your risk. Only once you know what you operate can you prioritize.
- Make pace measurable. Define the time from the disclosure of a critical vulnerability to full-fleet patching as a metric (mean time to patch) and begin to record it. Decouple the measurement from the maintenance window, otherwise you are measuring your calendar, not your ability to respond.
- Set up the evidence. Ensure that progress can be demonstrated at the push of a button from a single data source, with timestamps and ready to submit to the JST. A report you can generate in minutes is more convincing than one you spend days compiling.
- Anchor accountability. Appoint an accountable person with a mandate and budget, and bring the topic into a fixed board cadence against the same metrics by which the supervisor will measure you.
The sequence in practice: transparency and metrics first, automation and evidence built on top, and governance running alongside from the outset. Organisations that follow this pattern will have, on 31st October, a plan and more importantly, the evidence to support it.
From plan to demonstrable reality
As a platform for Autonomous IT, Tanium brings inventory, vulnerabilities, patching and evidence together in a shared, always-current data foundation. A lightweight agent thereby replaces the fragmented tool landscape. The result: real-time visibility across all endpoints, automated patch execution and autonomous responsiveness. A credible action plan thus becomes a demonstrable operational reality that withstands supervisory scrutiny.
The deadline is set. The question is not whether you can submit a plan, but whether it is robust.