On 7 July, the European Central Bank wrote to the CEO of every significant bank it supervises about AI-enabled cyber threats. The message is short: AI models can now find software vulnerabilities and generate working exploits fast enough to shrink the time between discovery and attack.

The ECB is clear that this is a significant, long-term shift in the threat landscape: one that doesn't create new risks so much as speed them up.

So it asked each bank for an action plan, due to the bank's Joint Supervisory Team (JST) by 31 October 2026. The plan has to set out concrete measures, the resources behind them, who owns what, and when it gets done.

A lot of what the letter asks for lands on the teams who run the cloud: know what you have, be able to change it fast without breaking production, and be able to rebuild it when something gets through. 

Here is what the letter says, where cloud infrastructure fits, and what to have ready once the plan is in:

What the plan has to cover first, and where cloud sits

The letter splits the work into short-term priorities and longer-term structural measures. The short-term list has four areas:

  1. Protect the attack surface, starting with identifying ICT assets and monitoring everything internet-facing, cloud environments included.
  2. Accelerate vulnerability and patch management at scale.
  3. Strengthen monitoring, detection and AI-enabled defense.
  4. Revisit governance, funding, training and supply chain assurance.

Cloud runs through the first two.

Asset identification. You can't prioritize remediation on assets you can't see. In many cloud estates, some of what's running was created by hand in a console and never codified. Those resources don't show up in the Terraform, and they're the ones nobody remembers to patch.

Patching without breaking things. The ECB expects more frequent, higher-volume patching. It also asks for change management that allows rapid, risk-based remediation while keeping operations stable. That balance is hard when production and its code have drifted apart. An emergency fix becomes a console edit nobody can review, and the next deploy quietly undoes it.

Both problems have the same fix: a live inventory of every resource, codified, with drift caught as it happens. Then an emergency fix goes through the same review as any other code change.

Assume breach: What every plan should answer

The structural part of the letter contains the line that belongs at the top of every plan. 

A prudent security posture, the ECB says, assumes the perimeter will be breached, especially as frontier AI speeds up the discovery and exploitation of vulnerabilities, zero-days included.

If you accept that, the next question becomes: if that happens, how fast can you rebuild your cloud, and when did you last test it?

Most teams answer with their backups. Backups restore data. A running service also needs its IAM roles, VPC configuration, Kubernetes secrets, load balancer rules, DNS records and observability stack. None of that lives in a database snapshot, and after a destructive attack it may be exactly what the attacker went after.

Rebuilding into the environment that was compromised isn't much of a recovery either. You want to come back somewhere clean: an isolated region or account the attacker can't reach, built from versioned infrastructure snapshots they couldn't encrypt or corrupt.

The ECB lists recovery among its structural measures, not its short-term ones. It still expects banks to have it, and to have tested it.

What tested recovery looks like for cloud infrastructure

The letter calls for robust, regularly tested backup, failover, restoration and recovery arrangements, aligned with DORA. It also suggests exercises for harder scenarios, three of which put cloud infrastructure at the center:

For a cloud team, "tested" should mean four things you can show:

  1. A current inventory of everything the environment contains, across clouds, Kubernetes and SaaS.
  2. Code that matches production, with drift detected and fixed as it happens. Redeploying stale code rebuilds an environment that no longer exists.
  3. A rebuild you can run on demand for each scenario, into a clean region or account, then tear down.
  4. A measured result. Each test produces a recovery time you can compare against your RTO, plus a log of what ran.

The last point is the one regulators care about. A runbook that promises two hours is nothing compared to real evidence, like a logged test with a measured recovery time.

After 31 October, what’s coming?

Submitting the plan starts the next phase. The ECB says each JST (Joint Supervisory Teams: the main forms of cooperation between the ECB and national supervisors) will discuss the plan with its bank and monitor progress. The ECB will also run a horizontal analysis across all submitted plans and share what it finds with the banks.

In practice, a line in the plan that says "regularly tested recovery" will get questions. When was the last test? What did it cover? How long did it take, and how does that compare with the RTO you documented?

The teams with easy answers will have three things ready:

  • Recovery test logs, by scenario, with measured times
  • An inventory that matches what's actually running today
  • A record of changes made under the plan, through code, with review

The ECB also pushed its annual IT Risk Questionnaire from September 2026 to February 2027 so banks can focus on this work. In its words, the point is to let institutions focus resources on the key areas.

If your bank isn't ECB-supervised, here’s what’s at risk

The letter is addressed to significant banks in the euro area. The threat it describes doesn't stop at that border, and the ECB's own annex reads like a reading list for everyone else.

If you run cloud infrastructure at a UK or US bank, the same three questions apply whether or not anyone has asked them yet. Do you know every asset you run? Can you patch fast without breaking production? If the perimeter falls, how fast can you rebuild, and when did you last test it?

Where Firefly fits: proven recovery and resilience

Firefly was built for a plan like this. It keeps a live, codified inventory of your cloud and catches drift between your IaC and production as it happens, so the environment you’d rebuild is the one that’s currently running.

When something gets through, Firefly rebuilds the full environment, with every resource and dependency, into a clean region or account from immutable IaC snapshots. Recovery runs from an independent control plane, so it doesn’t depend on the environment that failed, and your services are back in minutes instead of the days a manual runbook takes.

Every test and recovery is logged with your actual RTO and RPO. Firefly keeps that record continuously as audit-ready evidence for DORA, so when your JST asks when you last tested recovery and how long it took, you answer with measured numbers instead of a spreadsheet pulled together the week before. It covers what the JST will look for: recovery logs by scenario, an inventory that matches production, and a record of changes made through code. The same evidence answers your board and your cyber insurer.

The question to start with is the one in the letter: if the perimeter is breached, how fast can you rebuild, and when did you last test it? Take the Cloud Resilience Assessment to see where your answer stands right now.

‍