The ESAs just told you what DORA expects about AI-driven attacks¶
The article-by-article series ended with the point that DORA is a chain, and that everything downstream inherits the quality of your asset and function map. On 31 July 2026 the three ESAs published a joint statement that tests exactly that claim. It is about frontier AI models being used to find and exploit vulnerabilities faster than your patch cycle can close them, and it says the rulebook you already have is the rulebook you are expected to use.
The document is JC 2026 25, "Toward a consistent and risk-based approach for ICT risks from frontier AI models". It is a statement, not a technical standard. Nothing was added to the Level 2 family, which still stands at thirteen acts in the DORA resource library. Read it anyway, because it is the clearest signal yet of what supervisors will ask about in 2027.
What it actually says¶
Three things are worth your time.
First, the ESAs are explicit that no new framework is coming. Their words: DORA and the AI Act "provide a solid foundation", the requirements in DORA "remain highly relevant", and the framework "remains technology-neutral". The Annex goes further and states that it does not establish additional requirements and is not a checklist. So the answer to "do we need an AI resilience programme" is no. You need the ICT risk management framework you were already supposed to have, running faster.
Second, the pressure point is timing. The argument in the statement is that shorter vulnerability discovery and exploitation cycles break controls that are periodic by design. Annual penetration tests, scheduled compliance checks, quarterly patch windows, periodic risk reporting to the management body. None of those are non-compliant. They are just sized for a slower adversary. The statement asks entities to move toward continuous scanning, continuous monitoring, proactive and automated patching for high risk systems, and faster escalation.
Third, and this is the part most firms will skip, paragraph 7 asks for the Risk Appetite Framework to be reviewed and updated with metrics, tolerance thresholds and control measures for this risk, covering both your own use of these models and your indirect exposure to them. That is a board-level artefact with a date on it. It is also the easiest thing for a supervisor to ask for.
Where it lands in DORA¶
The statement is not freestanding. Each theme maps to something you are already obliged to do.
| What the statement pushes | Where the obligation already lives |
|---|---|
| Continuous asset inventory, criticality and dependency mapping | Art. 8, and RTS 2024/1774 |
| Automated security controls, DevSecOps, patching | RTS 2024/1774 Art. 10, cited directly in the Annex |
| Continuous vulnerability scanning and behavioural monitoring | Arts. 9 and 10 |
| Incident response and continuity for multi-system failure | Arts. 11 and 12, RTS 2025/301 |
| Resilience testing against AI-assisted scenarios | Arts. 24 to 27, RTS 2025/1190 |
| Supply chain assurance down to software and open source | Arts. 28 to 30, RTS 2024/1773, RTS 2025/532 |
| Proportionality by size, risk profile, complexity | Art. 4, cited by name in paragraph 8 |
Note the last row. The ESAs anchored proportionality in Article 4 explicitly, and said a one-size-fits-all response would be neither proportionate nor efficient. That is your defence against gold-plating this into a programme you cannot staff.
The bit about your providers¶
Paragraph 10 is short and easy to miss. The ESAs, as Lead Overseers, have already run targeted engagement with critical ICT third-party providers on how they handle these risks. Those findings have fed the annual risk assessment cycle and the prioritisation of the 2027 Oversight Plan, AI risk is being embedded into the Oversight Examination Methodology, and it is expected to be in scope for oversight examinations in 2027.
So the questions are coming to your major providers whether you ask them or not. If you have a contract renewal or an annual review in the next two quarters, that is the cheap moment to ask what their answer is going to be.
The takeaway¶
Do not open a new workstream. Take the three or four controls in your framework that are still calendar-driven, patching, scanning, testing scope and board reporting cadence, and ask whether the interval you chose still makes sense against an attacker that does not wait for your quarter to end. Write down the answer, including where you decided the interval is fine. That document is the evidence.
Verified against the primary source: JC 2026 25, 31 July 2026. The full set of official DORA texts sits in the DORA resource library.