Introduction
On 7 July 2026, Claudia Buch, Chair of the ECB’s Supervisory Board, sent a letter to the CEO of every significant institution under ECB Banking Supervision. Its subject was AI-enabled cybersecurity threats, and its message was unusually direct. Assess the impact of the changing threat landscape without delay, build a comprehensive action plan with named owners, resourcing and timelines, and submit it to your Joint Supervisory Team by 31 October 2026.
The letter (SSM-2026-0301) landed the same day as the European Systemic Risk Board’s warning on systemic cyber risks stemming from frontier AI models. Together, they mark a shift in how European supervisors think about cyber risk in the financial sector. They also create a hard deadline that most ICT risk functions are now working backwards from.
This post covers what the ECB is actually asking for, why the ask is harder in the cloud than on paper, and how the Orca Cloud Security Platform maps to each of the six focus areas the letter sets out.
The short version for executives: The ECB has not invented new requirements. It has told banks that existing DORA obligations now need to operate at a speed most institutions cannot currently sustain, and asked them to prove, in writing, that they have a funded plan to get there. The binding constraint for most banks will be the accuracy of their asset inventory, because every other commitment in the plan depends on it.
What the ECB actually said
The core argument of the letter is about time, not novelty. In the ECB’s own framing, emerging AI models “are capable of identifying software vulnerabilities and generating functioning exploits at unprecedented speed, compressing the timeline between vulnerability discovery and exploitation.” The letter is explicit that this “does not introduce entirely new risks,” but that it “significantly amplifies the speed and scale at which such risks materialise.” It is also explicit that this is “a long-term shift in the threat landscape rather than a temporary phenomenon or a risk tied to any single tool.”
Three things follow from that framing, and they are worth reading carefully because they shape what a credible action plan looks like.
First, responsibility sits with the management body. The letter states that strategic ICT decisions, including investment, resource allocation, and risk tolerance frameworks, “may need to be revisited,” and that governance and control systems are expected to be strengthened where necessary. This is not a submission the CISO can make alone.
Second, open findings are now a bigger liability. The ECB warns that unresolved weaknesses from prior on-site inspections, targeted reviews and the 2024 cyber-resilience stress test “may become increasingly material.” If your remediation backlog has been quietly ageing, the letter has just repriced it.
Third, DORA is the frame, not a separate exercise. The ECB is clear that DORA’s requirements “remain highly relevant and valid.” The action plan is meant to build on your existing cyber-risk strategy, not sit beside it.
There is a genuine concession in the letter, too. The ECB is extending the annual IT Risk Questionnaire deadline from September 2026 to February 2027 to free up capacity, and will consider adjustments to other supervisory activities case by case. The ECB will also run a horizontal analysis across all submitted plans and feed conclusions back to institutions, which means your plan will, in effect, be benchmarked against your peers’.
One more signal worth flagging to your board now. The letter closes by noting that progress toward practical quantum computing will require post-quantum cryptography adoption that “must start now,” with a separate ECB letter to follow. Institutions building a cryptographic inventory for the October submission should scope it with that follow-on in mind. The two efforts share a foundation. The same asset and dependency inventory this action plan requires is also the starting point for a post-quantum migration, so work done now on one has a payoff for the other.
The six focus areas, and where cloud makes them harder
The letter’s annex sets out six areas the action plan should address, four short-term and two structural. Below, each is paired with the practical obstacle banks hit when the estate in question is cloud-based, and how Orca addresses it. We have been deliberate about where Orca is central and where it is one input among many.
1. Prioritise the protection of potential attack surfaces
What the ECB asks for: Banks must identify all their ICT assets, including third-party software and open-source components, and continuously monitor and minimise internet-facing and externally exposed assets such as cloud environments and third-party VPN connections. Remediation recommendations include starting with perimeter technologies before moving to cloud and on-premises environments, with particular attention to critical internal systems and security infrastructure, since the letter also notes that threat vectors may originate internally rather than only from external networks.
Why this is hard in the cloud: Every commitment further down the plan is only as good as the inventory underneath it. Getting a complete asset inventory is one thing, but maintaining it as your environment continues to expand and contract is another. Agent-based tooling typically covers a fraction of a real cloud estate, leaving unmanaged workloads, orphaned resources, forgotten test environments and shadow deployments invisible. A bank cannot credibly commit to a patching SLA for assets it has not enumerated.
How Orca helps: Orca SideScanning™ builds a complete inventory of workloads, containers, serverless functions, data stores and identities across AWS, Azure, Google Cloud, OCI, Alibaba Cloud and Tencent Cloud. It works agentlessly, so coverage does not depend on deployment campaigns reaching every team. The Unified Data Model then correlates those assets with their exposure, permissions, data sensitivity and reachability. Orca’s Attack Surface Red Agent adds an on-demand layer on top of that inventory, probing externally exposed assets the way an attacker would whenever you run it, while Orca’s AI Asset Discovery and AI-BOM extend the same inventory logic to the AI models, services and pipelines in your estate.
For practitioners: The inventory that matters for this section of your submission is not a flat asset list. It is exposure-qualified. Orca’s attack path analysis identifies which internet-facing assets actually chain to critical systems or sensitive data, which is precisely the prioritisation logic the ECB describes. Orca also surfaces open-source and third-party components in workload images, giving you the software-composition view the letter explicitly names. Because SideScanning reads from cloud-provider snapshots rather than running agents in production, it also picks up the internally-reachable assets the letter warns about, the ones perimeter-focused tooling tends to skip.
2. Accelerate vulnerability and patch management at scale
What the ECB asks for: Banks need prioritised vulnerability scanning to keep pace with rising discovery volume and to prepare for more frequent, higher-volume patching by ensuring ICT functions are adequately staffed. Change management should enable rapid, risk-based remediation without destabilising operations, and this should be reflected in contracts and SLAs wherever a provider is involved. AI-based tooling is encouraged here too, as long as it is preceded by a thorough assessment and backed by adequate safeguards, human oversight and robust risk management.
Why this is hard in the cloud: This is the area where the AI threat model bites hardest. CERT-EU’s analysis of how AI is changing the economics of vulnerability discovery and the UK NCSC’s guidance on preparing for a “vulnerability patch wave” point at the same problem. If discovery volume rises sharply, a queue ranked by CVSS alone becomes unworkable. Most banks are not short of vulnerability data. They are short of defensible reasons to patch one thing before another.
How Orca helps: Orca’s vulnerability management scores risks using environmental context. Is the asset internet-facing? Is the vulnerable package actually loaded at runtime? What data and permissions sit behind it? Does an exploit path exist end to end? That collapses a very large finding count into a short, ordered list your change process can absorb. Orca then offers one-click auto-remediation, guided manual instructions, and AI-generated remediation guidance, with bidirectional Jira and ServiceNow integration, so emergency changes route through your existing technologies and workflows rather than around it.
For practitioners: Three capabilities are worth naming explicitly in your submission. First, runtime reachability from the Orca Sensor. Distinguishing a vulnerable package that is installed from one that is actually executing changes your effective critical count materially, and gives you an auditable basis for deferral decisions. Second, automations such as conditional workflows that ticket, assign or remediate based on severity, exposure and asset criticality are the mechanism by which “risk-based remediation” stops being an aspiration in a policy document. On the ECB’s governance caveat around AI tooling, Orca’s AI-assisted remediation produces guidance for human review and approval rather than acting autonomously, which is the posture the letter asks you to be able to evidence. Finally, the Code Security Auditor brings reasoning-driven code scanning across your full repository to catch exploitable business-logic flaws and multi-step logic bugs that traditional pattern-matching SAST tools miss, constructing full attack chains rather than isolated findings,
3. Enhance monitoring, detection and AI-enabled defensive capabilities
What the ECB asks for: Banks should strengthen monitoring of application and access logs, network traffic and other indicators so they can detect signs of compromise and attempted exploitation, particularly across internet-facing applications, cloud repositories and critical internal systems.
Why this is hard in the cloud: Cloud telemetry is abundant and fragmented. The detection problem is rarely a missing log source. It is correlating control-plane activity, workload behaviour and identity events quickly enough to recognise an exploitation attempt while it is still in progress.
How Orca helps: Cloud Detection and Response monitors the cloud control plane and workloads continuously, correlating suspicious activity against the same unified asset and risk context used for posture. The Orca Sensor adds runtime visibility into process, network and file activity on workloads. Because detection and posture share one data model, an alert arrives already framed by what the affected asset is, what it can reach and what it holds, which is what shortens containment decisions.
For practitioners: this is also where Orca’s AI story is most directly responsive to the letter. Orca AI and the Agentic Cloud Security Platform apply AI reasoning to discovery, triage, investigation and remediation planning. These are the “AI-enabled defensive capabilities” the ECB names, deployed with human oversight rather than as autonomous action. If your plan claims AI-assisted defence, be ready to show the governance wrapper. What the model sees, what it recommends, who approves, and how decisions are logged. The same detection logic extends to post-quantum cryptography. Orca discovers quantum-vulnerable algorithms and certificates across your estate and maps them into a continuously updated cryptographic inventory, so the post-quantum migration the letter flags has a starting inventory rather than a blank page, and that inventory feeds into the same compliance reporting used elsewhere in your ECB submission.
4. Strengthen governance, funding, awareness training and supply chain assurance
What the ECB asks for: Management bodies should assess whether current ICT budgeting, staffing, tooling and change capacity are sufficient, and ensure training is risk-proportionate for employees, customers, counterparties and third parties. Supply chain assurance should extend to understanding how prepared ICT providers are for accelerated vulnerability disclosure and patching. The letter also asks banks to update their risk appetite frameworks with metrics and tolerance thresholds, including for increased patch frequency, that reflect exposure from both internal AI use and indirect exposure to AI-enabled threats.
Where Orca fits and where it does not: Training, awareness and organisational funding decisions are yours; no platform substitutes for them, and any vendor claiming otherwise is overreaching. Orca contributes to the other two threads.
On risk appetite metrics, this is the most under-appreciated line in the letter and one Orca directly supports. If you are going to set a tolerance threshold for, say, critical internet-facing vulnerabilities open beyond seven days, you need a system of record that measures it continuously and reports it to the board. Orca’s compliance and executive risk reporting provides that measurement, with scheduled PDF, CSV or JSON reports to email, Slack or storage. That is the evidence trail your JST dialogue will draw on.
On supply chain assurance, Orca gives you the technical half. Visibility into third-party and open-source components running in your estate, and into the exposure created by third-party integrations and connections. Combined with your existing TPRM process, that lets you answer the ECB’s specific question of how prepared your providers are for accelerated disclosure and patching with data rather than attestations alone.
The letter’s reference to exposure from “internal use of such models” is worth reading twice. It brings your own AI estate into scope. Orca’s AI Security capabilities discover AI models, services and pipelines across your cloud environments, including shadow AI deployments teams stood up without review, and assess their posture, data exposure and permissions. An AI-BOM gives you a standing bill of materials for that AI estate, the same way a software BOM does for code, which is the kind of artefact a JST is likely to ask for once they connect the letter’s own reference to internal AI use. Our 2026 State of AI Security Report found AI moving into production far faster than the controls around it, which is the gap an ECB-driven inventory exercise tends to expose.
5. Reinforce defence-in-depth and cyber hygiene, modernise infrastructure
What the ECB asks for: Banks should adopt a posture that assumes perimeter defences will eventually be breached, including through zero-day exploitation, and reinforce it with segmentation, micro-segmentation and zero-trust principles such as continuous verification of users, devices, applications, APIs and service accounts. This should sit on top of strong baseline controls, including accurate asset inventories, secure configuration, least-privilege access, multi-factor authentication and comprehensive logging, alongside security-by-design practices in software development. Legacy, unsupported and end-of-life technology should be replaced or protected with compensating controls where replacement isn’t feasible.
How Orca helps: This area is a checklist of things a CNAPP is built to measure. CSPM continuously validates secure configuration and logging coverage. CIEM identifies over-permissioned identities, including the service accounts and non-human identities the letter calls out, a population that grows quickly wherever agentic AI is in use. API Security provides discovery, posture and drift detection for the API layer the ECB names explicitly. Application Security shifts checks into the SDLC and traces development-stage risks through to production. Orca also flags end-of-life and unsupported software across the estate, which is usually the fastest way to build the evidence base for a modernisation business case.
For practitioners: The end-of-life inventory is worth prioritising early. It is the section of the submission most likely to require multi-year funding commitments, and the ECB explicitly accepts compensating controls where replacement is not feasible, but only if you can show which assets they apply to.
6. Improve operational resilience, crisis management and information sharing
What the ECB asks for: Banks should maintain tested crisis management, incident response, backup, failover and recovery arrangements aligned with DORA, and run exercises that cover high-speed, high-volume attack scenarios, broad zero-day compromise, ransomware, destructive attacks and supply chain or cloud service disruption. The letter also calls for secure frameworks that let institutions exchange vulnerability and threat intelligence with one another.
Where Orca fits, and where it does not: Crisis management, tabletop exercises and threat-led penetration testing are programme activities, not platform features. Orca’s contribution is narrower but real/ During a high-volume incident, the constraint is usually knowing blast radius fast enough. Orca’s unified asset, exposure and data-sensitivity context answers “what else is affected” in minutes rather than days, and Orca’s reporting and integrations feed your SIEM, SOAR and ticketing systems so incident workflows draw on current state rather than a stale CMDB. For the scenario exercises the ECB describes, Orca is a useful input to scoping, as it tells you which assets a hypothetical zero-day in a given component would actually reach.
On information sharing, FS-ISAC’s sector risk advisories on AI-enabled vulnerability discovery are the obvious existing arrangement to reference in your plan, as the ECB’s annex points to them directly.
Three things to get right before 31 October
Treat inventory accuracy as the critical path. Every SLA, tolerance threshold and remediation commitment in your plan inherits the error rate of your asset inventory. If coverage is partial, the plan is partially fictional, and the ECB’s horizontal analysis across institutions will make outliers visible. Establishing agentless, complete coverage is the highest-leverage thing you can do in the time remaining.
Write metrics you can actually measure continuously. The letter asks for tolerance thresholds, not intentions. A threshold you can only evidence during a quarterly manual exercise will not survive JST scrutiny, and it will not help you manage risk between reviews. Pick metrics your platform reports automatically, such as mean time to remediate critical internet-facing vulnerabilities, count of exposed assets with paths to sensitive data, or percentage of estate under continuous monitoring, and commit to those.
Make the plan a programme, not a document. The JST will engage on the plan after submission and monitor progress against it. The institutions that come out of this well will be the ones for whom 31 October is a checkpoint in continuous compliance rather than the finish line of a documentation sprint.
How Orca supports your ECB action plan
Orca provides a single agentless platform covering the technical substance of four of the six ECB focus areas end to end, and meaningful parts of the other two:
- Complete coverage of cloud workloads, containers, serverless functions, data stores, identities, APIs and AI assets, without agents, so coverage does not depend on deployment reaching every team
- Exposure-aware prioritisation that turns rising vulnerability volume into a short, ordered, defensible remediation queue
- Continuous detection and response across the cloud control plane and workloads, sharing one data model with posture
- AI-enabled defence with human oversight, plus discovery and posture management for the bank’s own AI estate
- 200+ out-of-the-box compliance frameworks including DORA, NIS2, GDPR, PCI DSS and ISO 27001, plus custom frameworks, so you can build an ECB-focus-area view and report against it continuously
- Automated, scheduled reporting in PDF, CSV or JSON for board packs and JST engagement
If you are building an action plan for October and want to see what complete, exposure-qualified coverage of your cloud estate looks like, schedule a demo.