ECB cybersecurity requirements: why your action plan needs application runtime visibility

The European Central Bank (ECB) has set new supervisory expectations for how directly supervised banks should respond to AI-enabled cyber threats. Significant institutions are expected to submit a concrete cybersecurity action plan by Oct 31, 2026, setting out how they will strengthen their defenses as vulnerability discovery and exploitation accelerate. [1]

For bank security leaders, this creates an immediate planning task and an operational question: do your teams have the visibility and controls to understand what is happening inside the applications they need to protect?

The wider breach data reinforces the urgency. Verizon’s 2026 Data Breach Investigations Report reports that 31% of breaches began with vulnerability exploitation and 48% involved a third party. These are cross-industry findings based on 2025 data, not statistics specific to ECB-supervised banks. [2]

For application teams, those trends make two questions particularly relevant: which vulnerable code actually runs, and what can that code do once it is running? Supplier oversight remains essential, but application security also needs to account for the behavior of third-party libraries inside production workloads.

Raven’s Application Detection and Response (ADR) helps teams answer those questions. It shows which vulnerable code executes, traces sensitive actions to the libraries behind them and applies runtime policies to block covered unauthorized behavior. That gives AppSec, engineering and the SOC evidence they can use to prioritize remediation and protect production applications.

What the ECB expects

The action plan should identify concrete measures, resources, accountable owners and implementation timelines, and go to the bank’s Joint Supervisory Team. The priorities include exposed assets, accelerated patching, stronger monitoring and detection, third-party preparedness, defense in depth, and tested response and recovery. These expectations build on DORA.

The deadline is for submitting the plan, not completing every remediation. The ECB does not mandate ADR or endorse a particular vendor. Raven can support relevant application-security objectives within that broader response; the following sections explain where runtime visibility, detection context and prevention fit.

How this fits with DORA

The letter builds on the Digital Operational Resilience Act (DORA), connecting the response to AI-enabled threats with banks’ existing ICT risk management, incident handling, resilience testing and third-party oversight.

It also references the ESRB’s warning on systemic cyber risks, national initiatives stemming from NIS2, and guidance from cybersecurity agencies and industry bodies. These provide supporting context. Raven’s runtime evidence can contribute to application-level controls within that broader program; it does not establish compliance on its own.

Where runtime visibility and ADR support the ECB response

Raven supports selected application-security objectives within a broader resilience program. The ECB does not prescribe ADR.

ECB priority	Application security question	How Raven helps
Faster remediation	Which vulnerable code actually runs?	Runtime execution evidence helps prioritize investigation alongside severity and exposure.
Stronger monitoring and detection	Which code triggered a sensitive action?	ADR connects the action to the application and library chain behind it.
Defense in depth	What can stop unauthorized behavior before remediation?	Runtime policies can block covered unauthorized actions on supported workloads.
Incident response	What happened, and did the control work?	Event context shows the attempted action and policy outcome to support investigation.

Why runtime visibility belongs in that response

A software inventory tells you what is present. Runtime visibility adds evidence about what loads, what executes and which code is involved in a sensitive action.

That distinction can change a security decision. A library installed in a service is not the same observation as a vulnerable function executing. A process-level event is not the same explanation as the library chain responsible for it.

Raven brings that application-level context into conversations between AppSec, engineering and the SOC. The value is not simply another stream of alerts. It is a clearer basis for deciding what to investigate, what to fix and what to control.

Prioritize remediation with evidence from running applications

Faster remediation requires a useful order of work. A severity score alone does not describe an application’s exposure, business importance or observed use of vulnerable code.

Raven shows which libraries are loaded, which execute and whether a function associated with a vulnerability was observed running. Teams can combine that evidence with severity, exploit conditions and service criticality to decide what to investigate first.

For example, two critical findings may look identical in a backlog. Runtime evidence can reveal that the vulnerable function in one finding has executed in a key service. Engineering now has a concrete reason to examine that finding closely.

Observed execution is evidence of code use, not proof of exploitation. No observed execution is not proof of safety: rare or newly triggered paths may still run.

The connection to your plan: document how runtime evidence informs investigation and remediation decisions, alongside your existing risk criteria.

Give AppSec and the SOC a clearer view of application threats

When an application attempts a sensitive action, responders need to know which workload was involved, which libraries triggered it and whether a policy allowed or blocked it.

Raven connects those details, giving AppSec, engineering and the SOC a shared starting point for investigation. Teams can use that context to investigate the affected code, determine next steps and document how the runtime control behaved.

For your action plan, identify where this application-level context could strengthen detection and incident investigation.

Add a runtime control for unauthorized behavior

Visibility explains activity. Prevention can restrict what the application is allowed to do.

Raven evaluates sensitive actions against permissions for the library chain performing them. On supported workloads, active policies can block covered unauthorized process execution, file access or network activity without first identifying the underlying vulnerability.

A parser may legitimately process incoming data without needing permission to launch a process. Enforcing that boundary creates a control that does not depend on recognizing a particular exploit signature or published CVE.

The connection to your plan: evaluate runtime enforcement as an additional layer of application defense, including protection while remediation proceeds. Validate coverage, policy behavior and operational impact in your environment.

Make application security part of your ECB response

The ECB’s priorities reach into production: faster remediation, stronger detection and layered defenses depend on understanding what applications are doing and being able to act when that behavior becomes dangerous.

Raven’s ADR brings runtime visibility and prevention to that work. It helps teams prioritize vulnerable code, trace sensitive actions to the libraries behind them and block covered unauthorized behavior while remediation proceeds.

As you prepare your action plan, identify where those capabilities could close gaps in your application security program.