ECB AI Cybersecurity Letter: The 31 October 2026 JST Action Plan

ByOfficer

On 7 July 2026, the Chair of the ECB Supervisory Board, Claudia Buch, wrote to the CEO of every significant institution under a letter numbered SSM-2026-0301 and titled “Addressing AI-enabled cybersecurity threats”. The ECB AI cybersecurity letter does one operationally concrete thing behind its strategic language: it gives each directly supervised bank until 31 October 2026 to hand its Joint Supervisory Team a board-owned action plan setting out how it will strengthen ICT and cyber controls against threats that artificial intelligence is making faster to execute and broader in reach.

The letter is a supervisory expectation, so it reads at the altitude of strategy, closer to a board memo than to a reporting template. For the teams who actually file, though, its centre of gravity is familiar. The ECB grounds the whole exercise in the Digital Operational Resilience Act, Regulation (EU) 2022/2554, which has applied since 17 January 2025. The message is blunt: AI raises the stakes on the rulebook banks already run, and the ECB wants the existing DORA controls reinforced and accelerated. A plan that describes a solid DORA ICT risk management framework, disciplined incident reporting and a maintained register of ICT third-party arrangements will read very differently from one that exposes gaps the 2024 cyber-resilience stress test or a recent on-site inspection already flagged.

Two dates reorganise the second half of 2026 for ICT and reporting functions. The action plan is due to the Joint Supervisory Team by 31 October 2026. To make room for the work, the ECB is moving its annual collection of the IT Risk Questionnaire back from September 2026 to February 2027. Neither of those touches the statutory clocks in DORA itself, and confusing the supervisory calendar with the regulatory one is the first mistake worth avoiding.

Related reading: our guide to DORA, AI risk and ECB ICT incident-reporting expectations.

What the ECB AI cybersecurity letter changes, and the dates that matter

Deadline pressure is the reason this letter matters operationally, so map the calendar before anything else. The dates this letter puts in play are narrow and specific:

  • 7 July 2026: the ECB issues letter SSM-2026-0301 to CEOs of significant institutions. On the same day the European Systemic Risk Board publishes its warning on systemic cyber risks stemming from frontier artificial intelligence models.
  • 31 October 2026: deadline for each significant institution to submit its ICT and cyber action plan to its Joint Supervisory Team.
  • September 2026 moved to February 2027: the annual collection of the ECB IT Risk Questionnaire shifts back, freeing ICT risk functions to work on the plan.
  • Unchanged: DORA statutory deadlines continue to run in parallel. Major-incident reporting keeps its four-hour, 24-hour, 72-hour and one-month steps, and the register of information keeps its annual cycle.

The 31 October date is a single submission, not the end of the matter. The letter is explicit that the Joint Supervisory Team will engage bilaterally with each bank to discuss the plan and monitor its progress, and that the ECB will run a horizontal analysis across all submitted plans to identify common trends, challenges and areas for improvement before feeding conclusions back to the sector. The plan opens a supervisory dialogue that continues well past the submission date.

Why the ECB built this on DORA instead of a new rulebook

Reading the letter as a fresh AI-cyber regulation would misread it. The ECB is precise that AI-enabled threats do not introduce entirely new risks; they amplify the speed and scale at which existing risks materialise, because emerging models can identify software vulnerabilities and generate working exploits quickly enough to compress the window between a vulnerability being discovered and being exploited. The supervisory response, in the ECB’s framing, is to reinforce and accelerate what DORA already requires, with no second regime layered on top.

That choice has a practical consequence. Nothing in SSM-2026-0301 is directly enforceable in the way a DORA article is. The binding obligations, the ones a supervisor can hold a bank to, remain the DORA provisions and their technical standards. What the letter adds is supervisory expectation and a deadline: the ECB expects the management body to assess the impact of the changing threat landscape without delay and to evidence, in a concrete plan, how it is closing the distance between its current controls and the resilience DORA already demands. A bank that treats the letter as optional because it is “only” a letter has misjudged how the plan will be used in the supervisory dialogue that follows.

The letter also tells banks where the ECB will not tolerate drift. It calls specifically for institutions to address, without delay, open supervisory findings and measures tied to ICT and security risks already identified in previous supervisory activity, including on-site inspections, targeted reviews and the 2024 cyber-resilience stress test. Unresolved weaknesses that looked tolerable a year ago are the ones the ECB expects to become material as the threat landscape accelerates.

What the 31 October action plan has to contain

The letter and its first annex sketch the shape of the plan while leaving the exact template to the bank. It must build on the bank’s existing cyber-risk strategy, address both immediate priorities and longer-term structural aspects, and for each measure allocate resources, assign clear roles and responsibilities and define implementation timelines. The annex groups the focus areas into short-term actions and structural measures.

In the short term, the ECB asks banks to concentrate on four areas. First, prioritise the protection of potential attack surfaces, starting from an inventory of ICT assets that includes third-party software and open-source components, with particular attention to internet-facing and externally exposed assets, cloud environments and VPN connections to third parties. Second, accelerate vulnerability and patch management at scale, preparing for more frequent and higher-volume patching and for change-management arrangements that allow rapid, risk-based remediation. Third, enhance monitoring, detection and AI-enabled defensive capabilities, including stronger monitoring of application and access logs and network traffic. Fourth, strengthen governance, funding, awareness training and supply-chain assurance, which is where the management body has to judge whether current ICT budgeting, staffing, tooling and change capacity are actually sufficient for the accelerated pace.

The structural measures run longer. The ECB asks banks to reinforce defence-in-depth and cyber hygiene and to modernise infrastructure by replacing or updating legacy, unsupported or end-of-life technologies, working from a prudent posture that assumes perimeter defences will eventually be breached and leaning on segmentation, zero-trust principles and strong baseline controls such as least-privilege access and multi-factor authentication. It also asks for improved operational resilience through tested response and recovery mechanisms, crisis management and information-sharing arrangements, with exercises that rehearse high-speed, high-volume attack scenarios, broad compromise through zero-day vulnerabilities, ransomware or destructive attacks, and supply-chain or cloud-service disruption. A reporting officer reading the annex will recognise most of it as DORA content translated into the language of an accelerated threat.

AI and the ICT risk management framework: the management body owns it

One line in the letter carries more weight than its brevity suggests: responsibility for responding to the evolving cyber-risk environment lies primarily with the bank’s management body. The action plan is a board-level commitment, owned by the management body and beyond anything a CISO can sign off alone, which is why the ECB expects strategic ICT decisions, including ICT investment, resource allocation and ICT-related risk tolerance frameworks, to be revisited, and governance and control systems to be strengthened where necessary.

This maps directly onto DORA’s own governance architecture. The ICT risk management framework in DORA rests on the management body as the accountable owner, which cannot delegate that accountability to a technology function or an outsourced provider. The letter’s specific ask, that risk appetite frameworks be reviewed to update metrics, tolerance thresholds and control measures, including those tied to increased patch-management frequency, is an instruction to fold the AI-accelerated threat into the bank’s existing risk-appetite machinery and give it first-order status. Where AI-native or AI-assisted defensive tools are deployed, the ECB is equally clear that they must come with governance, validation and human oversight, so adopting an AI security tool is not, in itself, evidence that the plan is done.

Incident reporting when AI compresses the attack timeline

If AI shortens the gap between a vulnerability being discovered and exploited, the part of DORA that feels the pressure first is incident reporting. DORA Article 19 requires financial entities to report major ICT-related incidents to their competent authority through a sequence of notifications, and those time limits do not move because the ECB extended its own questionnaire. Under Commission Delegated Regulation (EU) 2025/301, an initial notification is due as early as possible, within four hours from classification of the incident as major and no later than 24 hours from the moment the financial entity became aware of the ICT-related incident; an intermediate report is due at the latest within 72 hours from submission of the initial notification; and the final report is due no later than one month after the intermediate report or, where applicable, the latest updated intermediate report. The classification criteria and materiality thresholds sit in Commission Delegated Regulation (EU) 2024/1772, the content and time limits in Commission Delegated Regulation (EU) 2025/301, and the standard forms, templates and procedures in Commission Implementing Regulation (EU) 2025/302. Our DORA ICT incident reporting guide walks through the full notification chain.

For significant institutions the routing detail matters here. Under Article 19, a significant credit institution reports to its national competent authority, which immediately transmits the report to the ECB, so the same supervisor reading the 31 October action plan is also receiving the bank’s live major-incident reports. The two streams are read together. A plan that promises faster detection while the bank’s actual incident reports show late or thin initial notifications will not survive that comparison. The scale is not hypothetical: financial entities reported 3,383 major incidents across the EU financial sector in 2025, the first reporting year under DORA, according to the joint European Supervisory Authorities report on major ICT-related incidents. AI-accelerated exploitation is expected to push those detection-to-report clocks harder, not looser, which is why the letter treats monitoring and detection as short-term priorities.

Third-party and supply-chain exposure: back to the register of information

The letter singles out ICT service providers in critical supply chains, asking banks to verify that third-party risk management is fit for purpose in the current situation and to extend supply-chain assurance to third parties’ own preparedness for accelerated vulnerability disclosure and patching. This is where teams often underestimate their exposure, because the attack surface a bank has to defend now includes software and open-source components it does not build and providers it does not control.

DORA already provides the instrument. Article 28(3) requires financial entities to maintain and update a register of information covering all contractual arrangements on the use of ICT services provided by ICT third-party service providers, at entity, sub-consolidated and consolidated levels, distinguishing arrangements that support critical or important functions from those that do not. The register templates are set by Commission Implementing Regulation (EU) 2024/2956, and entities report to competent authorities at least yearly on the number of new arrangements, the categories of providers and the services and functions provided. A register that is accurate and current is, in practice, the evidence base for the letter’s third-party ask, and our DORA register of information guide covers how the templates fit together.

The accountability point is worth stating plainly because it is easy to get backwards. Outsourcing an ICT service does not outsource responsibility for it. DORA and its third-party standards are explicit that using an ICT third-party provider cannot reduce the financial entity’s own responsibility for managing its risks and complying with its obligations, and the ECB letter echoes it: institutions remain exposed to, and fully accountable for, risks stemming from outsourced ICT services. The same discipline extends to the bank’s DORA digital operational resilience testing programme. TLPT should be referenced only where the bank has been identified by the competent authority as required to perform threat-led penetration testing under DORA, while the ECB letter itself points more generally to whether current capacity is sufficient for resilience testing at the new pace.

How supervisors will read the plans, and what the questionnaire shift signals

The horizontal analysis is the tell for how the ECB intends to use 31 October. Instead of grading each plan in isolation, the ECB will compare plans across the population of significant institutions to find where the sector is weak, then share conclusions and potentially organise industry events or workshops depending on what it finds and on developments in frontier AI. A bank’s plan is therefore also a data point in a peer benchmark, and outliers on either side of the distribution will draw attention.

The IT Risk Questionnaire extension is the accommodation that pays for the plan, and reading it correctly avoids a false sense of relief. Moving the annual collection from September 2026 to February 2027 is a shift in one ECB supervisory data request, chosen so ICT risk functions are not doing the questionnaire and the action plan at the same time. It does not relax any DORA obligation, it does not extend incident-reporting or register deadlines, and the ECB reserves the right to adjust other supervisory activities such as on-site inspections on a case-by-case basis. The letter closes with a signal about what comes next: quantum computing and the move to post-quantum cryptography will be the subject of a separate ECB letter in due course, and the ECB frames post-quantum work as something that must start now even though its horizon is longer. For context on how these ICT themes sit inside the broader supervisory cycle, see the ECB SREP 2026 priorities, and on the governance of AI tools themselves, the EU AI Act compliance requirements for financial institutions.

Frequently Asked Questions

Does the ECB letter create new DORA obligations?

No. SSM-2026-0301 is a supervisory expectation, not a legislative act, and it introduces no new binding requirements. The enforceable obligations remain those in DORA and its technical standards. What the letter adds is a deadline of 31 October 2026 for a board-owned action plan and a clear statement of the ICT and cyber areas the ECB will scrutinise most closely in the supervisory dialogue that follows.

Which institutions have to respond?

The letter is addressed to the CEOs of significant institutions, the banking groups the ECB supervises directly under the Single Supervisory Mechanism. Less significant institutions, supervised by national competent authorities, are not addressed by this letter, although national supervisors can and often do align their own expectations with the ECB’s. The action plan is submitted to the bank’s Joint Supervisory Team, the ECB-led team that runs its day-to-day supervision.

Does the IT Risk Questionnaire extension change any DORA reporting deadline?

No, and treating it as breathing room on DORA would be a mistake. The extension moves only the ECB’s own annual IT Risk Questionnaire collection, from September 2026 to February 2027. DORA’s statutory deadlines are untouched: major-incident reporting keeps its four-hour, 24-hour, 72-hour and one-month steps, and the register of information keeps its annual reporting cycle to the competent authority.

What happens after the plan is submitted on 31 October?

The Joint Supervisory Team engages bilaterally with the bank to discuss the plan and monitor its progress, and the ECB runs a horizontal analysis across all submitted plans to identify sector-wide trends and gaps. Depending on the outcome, the ECB may adjust supervisory activities such as on-site inspections on a case-by-case basis, and it may organise additional industry events or workshops.

How does the letter connect to the register of information?

The third-party focus area maps onto DORA Article 28. The register of information, maintained under Article 28(3) and reported using the templates in Commission Implementing Regulation (EU) 2024/2956, is the practical evidence base for showing that third-party and supply-chain risk management is fit for purpose. A register that is complete and current lets a bank answer the letter’s supply-chain questions with data instead of assertions.

Does deploying AI defensive tools satisfy the letter?

Not on its own. The ECB encourages AI-native and AI-assisted defensive tools but requires that they be deployed with appropriate governance, validation and human oversight. The deliverable is a resourced action plan with clear ownership and timelines, assessed against how it strengthens the bank’s overall ICT resilience, so buying an AI security product counts as one possible measure inside the plan, never a substitute for it.

Is quantum computing covered by this letter?

No. The letter flags that advances in quantum computing will affect the cybersecurity landscape and that the migration to post-quantum cryptography must begin now, but it states that the ECB will address that emerging risk in a separate letter in due course. Quantum sits outside the AI-enabled cybersecurity deliverable described in this letter, but the ECB still says post-quantum cryptography work must start now and will be addressed in a separate letter.

Related Articles

Key Takeaways

  • The ECB AI cybersecurity letter (SSM-2026-0301, 7 July 2026) requires every significant institution to submit a board-owned ICT and cyber action plan to its Joint Supervisory Team by 31 October 2026.
  • The letter creates no new binding obligations. It rests on DORA, Regulation (EU) 2022/2554, and expects banks to accelerate and evidence what DORA already requires.
  • The plan must cover four short-term areas (attack-surface protection, vulnerability and patch management at scale, monitoring and AI-enabled detection, governance and supply-chain assurance) and structural measures on defence-in-depth, legacy modernisation and tested response and recovery.
  • Responsibility sits with the management body: ICT investment, resource allocation and risk-tolerance frameworks are expected to be revisited, and adopting an AI tool does not close the plan.
  • DORA statutory clocks are unchanged. Major-incident reporting keeps its four-hour, 24-hour, 72-hour and one-month steps, and the register of information keeps its annual cycle.
  • Only the ECB IT Risk Questionnaire collection moves, from September 2026 to February 2027, to free capacity for the plan.
  • The ECB will run a horizontal analysis across all plans, so each submission is also a peer benchmark, and open findings from earlier inspections and the 2024 cyber-resilience stress test must be addressed without delay.

Sources and References

  • ECB Banking Supervision, letter to CEOs “Addressing AI-enabled cybersecurity threats”, SSM-2026-0301, 7 July 2026: https://www.bankingsupervision.europa.eu/press/letterstobanks/shared/pdf/2026/ssm.2026_letter_on_AI_enabled_cybersecurity_threats.en.pdf
  • European Systemic Risk Board, warning on systemic cyber risks stemming from frontier artificial intelligence models: https://www.esrb.europa.eu/pub/pdf/warnings/esrb.warning260625_on_systemic_cyber_risks_stemming_from_frontier_ai_models~ef424708cf.en.pdf
  • Regulation (EU) 2022/2554 (Digital Operational Resilience Act, DORA), applicable from 17 January 2025: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554
  • Commission Delegated Regulation (EU) 2024/1772 (RTS on classification of ICT-related incidents and materiality thresholds): http://data.europa.eu/eli/reg_del/2024/1772/oj
  • Commission Delegated Regulation (EU) 2025/301 (RTS on content and time limits for major ICT-related incident reports): http://data.europa.eu/eli/reg_del/2025/301/oj
  • Commission Implementing Regulation (EU) 2025/302 (ITS on forms, templates and procedures for reporting major ICT-related incidents): http://data.europa.eu/eli/reg_impl/2025/302/oj
  • Commission Implementing Regulation (EU) 2024/2956 (ITS on the register of information templates): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2956
  • Joint European Supervisory Authorities, 2025 report on major ICT-related incidents (June 2026): https://www.eba.europa.eu/sites/default/files/2026-06/29b60c21-4ff3-4e1e-9308-7c8225d5cc01/ESAs%202025%20report%20on%20major%20ICT-related%20incidents.pdf
  • CERT-EU (2026), “AI is changing the economics of vulnerability discovery. Defenders should adapt now”: https://www.cert.europa.eu/blog/ai-vulnerability-discovery-defenders-must-adapt
  • Directive (EU) 2022/2555 (NIS2): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555

Turning SSM-2026-0301 into a plan the JST will respect

The practitioner reading of this letter is short. Between now and 31 October 2026, a significant institution has to convert a strategic supervisory message into a concrete, resourced and board-owned plan, and the material that plan is graded on is the bank’s own DORA posture: how well it runs its ICT risk management framework, how fast and complete its major-incident reporting is, and how accurate its register of ICT third-party arrangements has become. The banks that will do well are the ones already treating DORA as an operating discipline rather than a compliance artefact, because the ECB has just asked them to prove it under an accelerating threat and against their peers.

Last updated: July 2026

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts