What Did the ECB Ask Banks to Do?
The ECB addressed its letter to the CEOs of significant institutions under its banking supervision. It asked them to assess the evolving threat landscape without delay and develop a comprehensive action plan with concrete measures, resources, owners, and implementation timelines. Banks must submit that plan to their respective Joint Supervisory Team by 31 October 2026.
The ECB identifies three near-term priorities: accelerate vulnerability and patch management; improve monitoring, detection, and AI-enabled defence; and check whether third-party risk management is fit for purpose. It also calls for longer-term work on cyber hygiene, legacy technology, response, and recovery. The ECB says its Joint Supervisory Teams will discuss the plans with banks and monitor progress.
Why Does the Letter Focus on Internet-Facing Assets?
According to the ECB, emerging AI models can find software weaknesses and generate working exploits more quickly. That can shorten the time between discovery and exploitation. The letter therefore prioritises internet-facing and externally exposed ICT assets, including third-party software and open-source components.
For a bank, the relevant exposure may include public web applications, APIs, remote access infrastructure, cloud services, and connections to third parties, all territory covered by attack surface management. The ECB also points to critical internal systems and security infrastructure as subsequent areas of focus. An asset inventory and a vulnerability scan can help locate and flag potential problems. A controlled penetration test can then examine whether selected weaknesses can be used in practice and what an attacker could reach. These activities answer different questions and should be scoped according to risk.
Does the ECB Letter Require a Penetration Test?
No specific pentest is mandated by this letter. It asks for a risk assessment and an action plan, and offers measures for banks to consider. A bank should not describe a commercial pentest as an ECB-required test solely on the basis of this letter. For how penetration testing sits alongside explicit and risk-based compliance obligations more broadly, see Is Penetration Testing Required for Compliance?
The letter is a supervisory communication. It carries real weight, because Joint Supervisory Teams will discuss the plans and monitor progress, but it does not create a new legal testing obligation. Separate requirements under EU law continue to apply in parallel, and those are set out next.
How Do DORA and NIS2 Apply Alongside the ECB Letter?
Three instruments are in play, and they work differently. Confusing them is the most common error in how this letter is being discussed.
The ECB letter
A supervisory communication, not binding legislation. It asks for an assessment and an action plan by 31 October 2026. It prescribes no testing method and sets no testing deadline.
DORA
Regulation (EU) 2022/2554 applies directly across member states without national transposition. Articles 24 to 27 establish a digital operational resilience testing framework. Article 24 requires financial entities to maintain a testing programme. Article 25 sets out the range of tests that programme may include, with penetration testing named among them. Article 26 requires financial entities identified by the competent authority to carry out advanced threat-led penetration testing (TLPT) at least every three years, subject to the Regulation’s provisions. See also What Is the Digital Operational Resilience Act (DORA)?
An ordinary external penetration test does not automatically meet the requirements of a DORA TLPT. The two are compared further down.
NIS2
Directive (EU) 2022/2555, known as NIS2, sets cybersecurity risk-management duties for essential and important entities across many sectors. Article 21 requires entities to take appropriate measures and, among other things, to have policies and procedures to assess the effectiveness of those measures. Unlike DORA it is a Directive, so the detail sits in national transposing law and varies by member state. It does not name penetration testing as a required activity.
Banks frequently ask whether they must satisfy both DORA and NIS2 in parallel. Generally they do not. NIS2 Article 4(1) provides that where sector-specific Union legal acts require essential or important entities to adopt cybersecurity risk-management measures or to notify significant incidents, and those requirements are at least equivalent in effect, the relevant provisions of NIS2 do not apply to those entities. For financial entities in DORA’s scope, DORA is that sector-specific act, so the NIS2 risk-management and incident-reporting provisions generally stand down in favour of DORA’s.
Two qualifications matter. The carve-out is not total: duties that fall outside it, such as certain registration requirements, are not displaced. And the assessment of whether an entity is in DORA scope at all is not always obvious, particularly for group structures and for ICT third-party providers. Both points should be confirmed with counsel rather than assumed.
The practical consequence for testing is straightforward. A bank in DORA scope should plan its testing programme against DORA Articles 24 to 27 and the ECB’s supervisory expectations, not against NIS2 Article 21. An entity outside DORA scope, including some technology and service providers in a bank’s supply chain, may face NIS2 obligations instead, and a bank assessing third-party exposure may need to understand which regime its providers sit under.
| Instrument | Legal status | What it says about testing | Relevance to the ECB action plan |
|---|---|---|---|
| ECB letter, 7 July 2026 | Supervisory communication, not binding law | Prescribes no test and sets no testing deadline | The action plan itself is the deliverable, due 31 October 2026 |
| DORA Articles 24 to 25 | Regulation, directly applicable | Requires a resilience testing programme; names penetration testing among the methods | Existing obligation, unchanged by the letter; test output can inform the plan |
| DORA Article 26 (TLPT) | Regulation, directly applicable | Threat-led penetration testing at least every three years for entities the competent authority identifies | A separate formal exercise; does not replace the action plan |
| NIS2 Article 21 | Directive, transposed into national law | Requires assessment of the effectiveness of risk-management measures; does not name pentesting | Generally displaced for DORA-scope financial entities under NIS2 Article 4(1) |
What Should an Action Plan Show?
A useful plan explains how the institution will address AI-enabled cyber threats, with concrete measures, resources, owners, and timelines. It should show:
- Which exposed assets and supporting dependencies have priority, and how the bank will identify new ones.
- How it will find, triage, patch, and verify high-risk weaknesses.
- How monitoring, detection, and response will adapt, including governance of any AI-enabled defensive tools.
- How it will assess relevant third-party and open-source exposure.
- Who owns each measure, what resources it needs, and when it will be implemented.
Test results can support the plan by documenting an exploitable path, a remediation decision, a retest outcome, or a residual risk, the same categories of technical evidence covered in What Evidence Do Auditors Expect From Penetration Testing? A test report on its own is not the action plan.
Where Can Penetration Testing Add Useful Evidence?
A risk-based test can help a bank move from a list of potential vulnerabilities to an understanding of actual exposure. Depending on scope and authorisation, useful questions include:
- What is exposed? Are internet-facing applications, APIs, remote access systems, cloud services, and relevant third-party connections accurately inventoried?
- Which weaknesses are exploitable? Can a tester use a finding in the bank’s actual configuration, given existing controls and access paths?
- What could an attacker reach? Could an initial foothold expose sensitive data, privileged functions, or a critical service?
- How quickly can the bank act? Are there owners, priorities, and target dates for remediation, especially for high-impact exposed assets?
- Did the fix work? Has retesting confirmed that the exploit path has been closed without introducing another issue?
Mapped against what the plan has to demonstrate, the evidence looks like this:
| What the plan must show | Evidence a test can supply | Where it comes from |
|---|---|---|
| Which exposed assets have priority | A verified inventory of reachable internet-facing assets and services, including ones not on the official list | Reconnaissance and attack surface mapping |
| Which weaknesses are real | Confirmation that a specific finding is exploitable in the live configuration, with reproduction steps | Human validation of a finding, not scanner output |
| What an attacker could reach | A documented path from initial foothold to business impact, within agreed scope | Post-exploitation analysis |
| Whether remediation worked | A retest result closing the finding, with date and outcome | Retest record |
| What residual risk is accepted | An exception record naming the owner, the compensating control, and a review date | Risk decision documented against the finding |
Findings should record the affected asset, evidence of exploitability, likely impact, recommended fix, accountable owner, and retest result, in line with what a penetration test report should include. A penetration test is one source of evidence within a broader programme that also includes asset management, scanning, monitoring, patching, third-party oversight, and response exercises.
How Should a Bank Scope Testing in Response?
Start with the institution’s critical services and the assets that support them. Map the internet-facing entry points and identify changes, known weaknesses, and dependencies that raise risk. Set written rules of engagement, documented approval, production safeguards, and a path to escalate critical findings discovered during a live test. Confirm consent and applicable terms before testing any third-party, cloud, SaaS, or shared infrastructure; a bank’s own authorisation may not be sufficient.
Prioritise assets where exposure and potential impact meet: for example, a public authentication flow tied to a critical service or an externally reachable administrative interface. Keep evidence traceable from asset and finding through the risk decision, remediation owner, and retest result. Document exceptions with an accountable owner, compensating controls, and a review date. Plan time to remediate and retest as applications and infrastructure change.
How Is This Different From Threat-Led Penetration Testing?
An external penetration test typically examines a defined set of assets for exploitable weaknesses. Threat-led penetration testing (TLPT) is a distinct intelligence-led resilience test focused on an entity’s critical or important functions and supporting ICT systems. It follows applicable DORA conditions for governance, scope, testers, authority coordination, and closure. The ECB letter does not turn every external test into TLPT. See DORA Articles 24 to 27 and the ECB’s TIBER-EU framework.
| Activity | Question it answers | Role in the ECB response |
|---|---|---|
| Asset inventory | What is exposed? | Informs the risk assessment |
| Vulnerability scanning | What weaknesses may exist? | Identifies findings to investigate and manage |
| External penetration test | Which selected weaknesses are exploitable? | Can supply supporting evidence; does not itself fulfil the action-plan request |
| DORA TLPT | How could an intelligence-led attacker compromise critical or important functions? | Separate formal exercise for entities identified under DORA Article 26; does not replace the action plan |
| NIS2 effectiveness assessment | Are the risk-management measures working? | Generally not applicable to DORA-scope banks; relevant when assessing providers outside DORA scope |
| Action plan | What will be done, by whom, with what resources, and when? | The direct deliverable requested in the ECB letter |
Conclusion
The ECB asks significant banks for an action plan by 31 October 2026. The letter creates no new testing obligation, and for banks already inside DORA’s scope it does not add a NIS2 layer either. What it does is raise the supervisory bar on knowing which exposed assets matter and proving that remediation works. Scoped penetration testing helps answer both questions with evidence rather than assertion.
