Beyond SAST Tickets: How Banks Prove DORA Compliance With Runtime Reachability

DORA compliance requires financial entities to maintain an ICT risk management framework that identifies, classifies, and documents risks to operational resilience on a continuous basis. Auditors expect evidence that the framework reflects how systems behave in production. Runtime reachability is one of the strongest forms of evidence regulators are starting to accept.

A CISO at a Tier-2 European bank sat across from a DORA auditor last quarter. The auditor asked what should have been an easy question: of the 47,000 vulnerabilities in her tracking system, how many were actually running in the customer-facing payment journey that morning?

Her team needed two weeks to come back with an answer.

This is the gap DORA was written to close. Auditors no longer treat a tidy backlog as proof of resilience; they want to see which risks actually matter, and they want the evidence to be current.

The DORA shift: from policy to provable resilience

The Digital Operational Resilience Act (DORA) has been in force since 17 January 2025. Article 6 requires financial entities to maintain an Information and Communication Technology (ICT) risk management framework that supports continuous identification of risks to operational resilience. Article 8 goes further and asks institutions to identify, classify and document every ICT-supported business function and its dependencies on an ongoing basis.

The regulatory direction is clear: financial institutions are expected to move beyond documenting that controls exist. They need to show that ICT risks are identified, classified, documented, and connected to the business functions they may affect.

In practice, this turns evidence into the centre of the audit conversation. Not “we have a SAST tool.” Not “we have a vulnerability management process.” But: “we can show which risks affect which critical or important functions, when they were identified, and what is being done about them.”

Before DORA, a tier-1 or tier-2 bank could usually pass an ICT review by demonstrating that a security program existed at all: a SAST tool, a vulnerability scanner, a triage queue, an SLA. DORA raises that bar. Institutions need to demonstrate which risks are material to operational resilience. Material has a specific meaning here: reaching customer-facing or critical business functions in production.

Why SAST backlogs don't equal DORA ICT risk management

The math doesn't work in the bank's favour. A typical large European bank runs static analysis across hundreds of microservices and inherits tens of thousands of findings from open-source dependencies. Most security teams respond by triaging on CVSS score, vendor severity, or how much noise a CVE has made in the press.

Runtime reachability assessments tend to reveal the same pattern: only a small fraction of scanner findings are actually relevant to production risk. Many sit in code paths that never load, functions that never execute, or libraries imported but never invoked.

The exact percentage will vary by environment, architecture, and workload. For a bank preparing for DORA, the important point is not whether the reachable number is 3%, 7%, or 12%. It is whether the team can prove which findings are reachable, which business function they affect, and whether remediation is being prioritised accordingly.

DORA auditors are not interested in documentation exercises. They want to know whether you can identify which ICT risks threaten which critical functions, and whether your remediation effort is proportionate. A backlog of 47,000 findings does not answer that question, it mostly demonstrates that the framework producing the backlog cannot tell the difference between a vulnerability in a dormant logging library, and one in the payment initiation service.

This is the conversation that keeps going wrong in DORA tabletop exercises. Teams can describe their tooling, their processes, and their SLAs. They cannot describe, with evidence, which of their findings are material.

What runtime reachability evidence looks like under DORA

Runtime reachability answers four questions that an auditor cares about.

1. Which packages and libraries are loaded by which services in production right now? 
2. Which functions inside those packages execute under real customer traffic? 
3. Which code paths touch your critical business functions, such as payment initiation, KYC, or settlement? 
4. And of the vulnerabilities your scanners flag, which ones sit on those reachable paths?

None of this is theoretical telemetry, it’s what production already knows about itself, captured continuously rather than reconstructed during an audit. A CISO with thirty days of runtime evidence can walk an auditor through the answer to "how many of your 47,000 findings are running in the payment journey?" in under a minute, and back it up with the call graph that produced the number.

The shift this enables is meaningful. Instead of handing the auditor the volume of findings and the velocity of ticket closure, the security team hands over a smaller set: the findings that touch critical functions, with evidence of reachability and the remediation status of each. The conversation that took two weeks now takes thirty seconds.

DORA does not mandate runtime reachability, and it does not prescribe a specific security tool category. What it does require is a well-documented ICT risk management framework and a clear understanding of the ICT assets, dependencies, and business functions that support operational resilience.

Runtime evidence helps produce that record in a way that is current, defensible, and tied to production reality. Instead of reconstructing the answer during an audit, teams can show which vulnerable components are loaded, which code paths execute, and which findings can actually reach a critical or important function.

Mapping runtime to DORA's five pillars

DORA organizes its requirements into five pillars. Runtime evidence has a practical answer for each.

For ICT Risk Management (Articles 5–15), auditors want continuous identification and classification of risk against critical functions. Runtime supplies the function-to-finding mapping in real time, rather than in a quarterly export.

For ICT-Related Incident Reporting (Articles 17–23), when a vulnerability turns into an incident, regulators want to understand the blast radius: which services were affected and which customer journeys touched the vulnerable code. Runtime reachability is the audit trail that answers this without a forensics project.

For Digital Operational Resilience Testing (Articles 24–27), including Threat-Led Penetration Testing, the red team needs to scope exercises against critical functions and the components that support them. Runtime evidence tells them, and the regulator, which components actually matter.

For ICT Third-Party Risk (Articles 28–44), most third-party exposure lives in open-source dependencies that vendors ship inside their software. Runtime tells you which of those dependencies execute in your environment and which sit dormant. That turns an unmanageable SBOM into a short list of components worth scrutinising.

For Information Sharing (Article 45), when the sector circulates threat intelligence on a newly weaponised CVE, runtime tells you within minutes whether the CVE is reachable in your production estate. A sector-wide alert becomes a specific decision instead of a project.

The pattern is consistent across the pillars. DORA asks financial institutions to demonstrate that ICT risk is understood in the context of operational resilience. Runtime evidence is one of the most defensible ways to make that demonstration concrete.

Walking your own team through this? We built a DORA ICT Risk Self-Assessment Template structured around the same five pillars. Download it here and use it before your next internal review.

The audit conversation, reframed

Picture the same auditor twelve months later, asking the same question.

"Of the 47,000 vulnerabilities in your tracking system, how many are running in your customer-facing payment journey today?"

The CISO opens a dashboard. "Forty-three. Twenty-nine are in three shared libraries loaded by the payment initiation service. Two are in active remediation; the rest have compensating controls documented in section 4.2. The other fourteen are in transitive dependencies that load but never execute under our production call paths. Here is the evidence for each."

The bank has not magically fixed its vulnerability problem, findings still existWhat has changed is that the bank can show which findings matter and which do not. That is the line between a security program and an ICT risk management framework, and DORA is asking for the second.

How to start a DORA compliance program (no rip-and-replace required)

The reassuring part is that producing DORA-grade evidence does not mean tearing down your existing AppSec stack. SAST, SCA, and vulnerability scanners keep doing what they already do. Runtime sits alongside them and tells you which of their findings are material.

A reasonable starter sequence: pick one critical function (payment initiation is the obvious candidate for most banks), instrument the services that support it, and capture thirty days of runtime evidence. Then compare the runtime-reachable count against your existing backlog for those services, and walk the delta through internal audit before your next external review.

Teams that run this pilot usually find the same two things. They have been spending most of their remediation effort on findings that posed no material risk, and they have been carrying a small number of genuinely reachable findings that should have been prioritised months earlier. Both findings, awkwardly, are exactly the kind of evidence DORA auditors are starting to ask for.

Want to see this in practice? Want to see this in practice? Watch our webinar on how banking security leaders use runtime evidence to identify which vulnerabilities are actually reachable in critical payment functions and focus remediation on the risks that matter most.

Or start with the template. The DORA ICT Risk Self-Assessment Template walks you through the five pillars and the evidence each one expects, in a format you can take to your next internal audit conversation.

Kodem helps fintech SaaS, wealth-tech, and lending platforms produce the runtime evidence modern procurement reviews demand. This piece is part of our 2026 series on the structural shifts reshaping AppSec in regulated industries.

References

1. Digital Operational Resilience Act (DORA). DORA.
2. Kodem Security. November 4, 2025. From Reachability to Reality: Proving Vulnerable Code was Executed & Exploited in Production. Kodem Security.