Evidence, Not Intent: What Your JST Will Want to See in Your AI-Cyber Action Plan
Ivan Milenkovic
, Vice President, Cyber Risk Technology
In June 2026 the European Systemic Risk Board (ESRB) rated systemic cyber risk "severe" because of highly capable frontier AI models. On 7 July it published a formal warning on frontier AI models. These models can find a flaw and turn it into a working exploit in minutes or hours, work that used to take days or weeks.
The same day, the European Central Bank (ECB) wrote to the CEO of every bank it supervises directly. Submit an action plan to your Joint Supervisory Team (JST) by 31 October, with measures, resources, owners and timelines. In effect: no new rulebook, no approved tools list, just a request to show that you can fix the vulnerabilities that matter before someone else uses them.
The deadline falls on a Saturday, so the working deadline is Friday 30 October. The easy draft leans on intent: commitments to accelerate, enhance and prioritise. What holds up in front of a JST is evidence. By evidence I mean figures drawn from your own environment, with a date and a stated scope, that a supervisor can check today and check again in six months.
The evidence on speed
The ECB says these developments "do not introduce entirely new risks"; they "significantly amplify the speed and scale at which such risks materialise." The vulnerabilities are familiar. The time you have to fix them has collapsed. Three sources show it, each measuring something different. How fast attackers move. Google's M-Trends 2026 estimates the mean time to exploit, the average gap between a patch's release and a vulnerability's exploitation, at negative seven days. In Google's words, that means "exploitation is routinely occurring before a patch is even released". CERT-EU notes the same figure was (positive) 63 days in 2018. How attackers get in, in Europe. In its Threat Landscape 2026, the European Union Agency for Cybersecurity (ENISA) found that vulnerability exploitation accounted for 60.4% of unauthorised-access incidents where the intrusion vector was identified. How fast defenders fix. The 2026 Verizon Data Breach Investigations Report (DBIR) found that exploitation overtook credential abuse as the most common initial access vector for the first time in the report's 19 years (31% against 13%). The same DBIR found that only 26% of critical vulnerabilities, defined as those on CISA's Known Exploited Vulnerabilities (KEV) catalogue, were fully remediated, down from 38%. The median time to full resolution rose to 43 days, from 32. Attacker timelines are measured in hours or negative days. Defender timelines are measured in weeks, fewer vulnerabilities are being fixed, and the median fix takes longer. The ECB describes this as "a long-term shift in the threat landscape rather than a temporary phenomenon or a risk tied to any single tool." Your plan describes how you will run from now on, and the JST will read it that way.
What the letter asks for
Responsibility sits with the bank's management body, which may need to revisit ICT investment, resourcing and risk tolerance. Open supervisory findings should be addressed without delay. And the plan builds on the Digital Operational Resilience Act (DORA), whose requirements "remain highly relevant and valid".
The annex sets out six focus areas with actions offered for consideration. Four are short term: attack surfaces; vulnerability and patch management at scale; monitoring, detection and AI-enabled defensive capabilities; and governance, funding, training and supply chain. Two are structural: defence in depth, cyber hygiene and infrastructure modernisation; and operational resilience.
Three instructions follow for your draft.
- Put internet-facing and third-party exposure first. The annex leads with attack surfaces, including third-party software and open-source components.
- Name your emergency change route. The ECB wants change management that enables "rapid, risk-based remediation while maintaining operational stability." Your plan should say which route a fix for a confirmed-exploitable issue takes, who can authorise it out of hours, and how you roll it back.
- Name the human approval gate for any AI tooling. The ECB allows for AI-enabled defence, subject to "adequate safeguards, human oversight and robust risk management." If AI finds, prioritises or fixes, say who approves what it proposes.
The European Supervisory Authorities backed the ESRB's warning on 7 July and on 31 July set out supervisory expectations for the wider financial sector, so insurers, investment firms and payment institutions should expect similar scrutiny under DORA.
What the JST will want to see
There is no published scoring rubric. The letter does say the JST will discuss and monitor the plan, and the ECB will run a horizontal analysis comparing plans across every significant institution. Read with the annex, that points to four tests.
1. Is it concrete? "Accelerate patching" is an intention. A target with a scope and a clock is a measure. As an illustrative starting point, which you should calibrate to your own estate and change capacity: confirmed-exploitable vulnerabilities on internet-facing assets (or KEV-listed ones, until you can validate exploitability) are mitigated or isolated within 72 hours of public disclosure (for the KEV fallback, of KEV listing, if later) and patched within 7 days of the patch's release. Tier everything else below that. What matters is that the target exists, is dated, and separates what is exploitable from what merely scores high.
2. Is it owned and resourced? The ECB asks whether budget, staffing, tooling and change capacity can support faster patching. The model I would put in the plan: the asset owner, typically through the CIO's organisation, owns remediation. The CISO sets the target and measures performance against it. The management body signs risk acceptances, and every acceptance carries an expiry date. Having sat on the CISO side of these conversations, I would resist any plan that makes the CISO the owner of patching. It looks decisive and removes the only independent measurement in the chain.
3. Can progress be measured? The annex asks for risk appetite metrics and tolerance thresholds, "including those related to increased patch management frequency". Three metrics cover most of what a JST will ask:
- Exposure window: for confirmed-exploitable vulnerabilities on internet-facing assets (or KEV-listed ones, until you can validate exploitability), time from public disclosure to mitigation, as a median and 90th percentile. Report detection lag (disclosure to first detection) as a separate sub-figure.
- Percentage of KEV-listed vulnerabilities fully remediated, and the share of those within your target. The first figure is the one comparable with the DBIR's 26%.
- Risk acceptances past expiry. The target is zero. Anything above it should be treated as a governance failure.
4. Will it hold up side by side? A plan is comparable when it uses standard metrics a peer would recognise, such as KEV listing and exposure windows; gives a dated baseline with its data source; and states its scope: which legal entities, which asset classes, and what is excluded and why.
What changes in the operating model
A monthly patch cycle and a spreadsheet of Common Vulnerability Scoring System (CVSS) scores cannot keep up when exploitation starts, on average, a week before the patch and the median fix takes 43 days. Your plan should describe four shifts.
- Prioritise on validated exploitability. A CVSS threshold tells you how bad a flaw could be. Validation tells you whether it can be exploited in your environment, past your controls. Queue work on the second.
- Pre-approve an emergency change route for confirmed-exploitable issues on internet-facing assets, agreed in advance with the change advisory board, rollback included. If the route is invented on the day, the 72 hours are gone before anyone patches.
- Treat mitigation and isolation as a time-limited interim control. Where a patch does not exist or cannot go in safely, a compensating control or isolation closes the exposure. Give it an expiry date so interim does not become permanent.
- Make remediation SLAs belong to asset owners and report performance against them to the management body, by business entity, every quarter.
Between now and 30 October
By Friday 2nd October
Baseline the metrics and check coverage. Pull the three figures above from your own data, dated and scoped, and check your draft against the six annex. If you cannot produce the exposure window, that is itself a finding
By Friday 9th October
Assign owners and SLAs. Name the asset owner for each internet-facing estate and agree targets and the emergency change route with them and the CIO.
By Friday 16th October
Management body sign-off on risk appetite. Take targets, tolerance thresholds and resourcing asks to the board or its risk committee, and minute the decision.
By Friday 23rd October
Confirm every measure has an owner and a date, and that the figures match what the management body signed off.
By Friday 30th October
Submit. The 31 October deadline falls on a Saturday.
- By Friday 2 October (or immediately, if you are reading this later): baseline the metrics and check coverage. Pull the three figures above from your own data, dated and scoped, and check your draft against the six annex areas. If you cannot produce the exposure window, that is itself a finding.
- By Friday 9 October: assign owners and SLAs. Name the asset owner for each internet-facing estate and agree targets and the emergency change route with them and the CIO.
- By Friday 16 October: management body sign-off on risk appetite. Take targets, tolerance thresholds and resourcing asks to the board or its risk committee, and minute the decision.
- By Friday 23 October: finalise. Confirm every measure has an owner and a date, and that the figures match what the management body signed off.
- By Friday 30 October: submit. The 31 October deadline falls on a Saturday.
How Qualys helps
Qualys provides capability and evidence for the two areas the ECB lists first, attack surfaces and vulnerability and patch management, as one loop: detect, validate, remediate, confirm. It does not write your action plan; governance, staffing, training and crisis management sit with the bank.
Detect. Qualys VMDR runs continuous vulnerability assessment through Cloud Agents and other sensors. Qualys Enterprise TruRisk Management (ETM) imports security and risk data from third-party tools into the same risk view. For fresh disclosures, an advisory-matching capability in ETM, launched in August, compares new vendor advisories against your existing asset inventory and flags affected assets within minutes for supported technologies, before a scan runs. It covers assets already in your inventory, and the scan still follows. For the AI your own teams are deploying, Qualys TotalAI flags shadow models (unapproved AI models of unknown origin) and scans large language models for prompt injection and sensitive information disclosure.
Validate. TruConfirm, part of ETM, classifies each finding as Confirmed Exploitable, Blocked by Control or Not Validated. It uses modified benign payloads: no exploit kits, data extraction or configuration changes. It validates findings from VMDR and supported third-party scanners, and Cloud Agent-based validation extends it to host-level and post-authentication vulnerabilities. It is continuous validation of individual findings and does not replace DORA threat-led penetration testing.
Remediate. TruRisk Eliminate patches Windows, Linux and macOS, mitigates where no patch exists or patching is not feasible, and isolates vulnerable assets. Patch jobs and partial mitigations can be rolled back. Wave-based patching, orchestrated by an AI agent, is available now to stage rollouts.
Confirm and report. After a fix, an AI agent re-runs the TruConfirm validation to confirm the exploit path is closed. ETM's TruRisk score includes a Risk Appetite component, trended for the organisation and each business entity: the baseline for your plan and the trend for your progress reports. The raw material for the first two metrics (when each vulnerability was publicly disclosed and detected, whether it is KEV-listed and confirmed exploitable, when it was fixed and when the fix was revalidated) comes out of that loop. Risk acceptances and their expiry dates usually live in your GRC process or scanner exceptions, so pull them from there.
- For the AI agents, apply the ECB's own condition of human oversight before you rely on them. Decide which patch waves need a named approver before they proceed. Route agent-initiated changes through your change control, including the emergency route. Require an audit trail of what each agent proposed, who approved it and what it changed, and ask any vendor, us included, to show you that trail.
31 October is the start
Submitting the plan opens a supervisory conversation, and DORA continues to apply throughout. The IT Risk Questionnaire, the ECB's annual self-assessment of banks' ICT risks and controls, is now due in February 2027, pushed back from September so banks can focus on the plan.
Use the same baseline, metric definitions and scope in your progress updates and your February questionnaire answers, so the numbers can be compared. Fix them now and change them only with an explanation.
Once you have checked coverage yourself, and before the draft goes to the management body, Book a 45-minute Action Plan Review as soon as possible. We will map your draft plan against the six annex areas and show where your own data can supply the baseline the JST will ask for.
Before anything else, pull that one measure: how long your confirmed-exploitable vulnerabilities on internet-facing assets (or KEV-listed ones) stayed unmitigated after public disclosure last quarter, as a median and 90th percentile. Everything else in the plan builds on it.