DORA is live: what supervisors actually sample on the software side
DORA has stopped being a preparation project; it is now an examination reality. On the software side, supervisors sample vulnerability management records, third-party software oversight, and the evidence trail behind both. The entities having easy examinations are the ones whose tooling produces that evidence as a side effect of operating.
The Digital Operational Resilience Act now applies to EU financial entities. The preparation era, gap assessments, and policy drafting are over; what remains is the operating era, in which supervisors examine whether the capabilities described in all those policies actually run. On the software layer, that examination has a predictable shape.
What DORA asks of the software you run
DORA’s pillars are broad, but three land directly on application and software security:
ICT risk management requires identifying and protecting the assets your services run on, which includes knowing the software estate and its weaknesses. Vulnerability management is named practice here, not implied.
Resilience testing requires a program that includes vulnerability assessments and scanning as a baseline, scaling to threat-led penetration testing for entities designated as significant. The baseline layer is continuous, not annual.
ICT third-party risk makes the software and services you procure your supervised responsibility. The vendor wrote it; you answer for it. This is the pillar most entities under-implement on the technical level, managing contracts carefully while never analyzing the delivered artifacts at all.
What examination actually looks like
Supervisory examinations sample. On the software side, the requests tend to be concrete:
- Show the vulnerability management records for these systems: identification dates, severity, remediation dates, and who approved any exceptions.
- Show how a critical vulnerability disclosed on a given date was handled: when you knew, what was affected, what was done.
- Show how you assess the software this third party delivers to you, beyond their questionnaire answers.
- Show that the testing program covers the estate, and what happened to the findings.
Notice what these have in common: they are evidence questions, not policy questions. A beautifully written vulnerability-management policy answers none of them. A tracked findings queue with an immutable audit trail answers all of them, mechanically.
The two-speed reality
Entities are diverging into two groups. The first assembled evidence manually for their initial DORA push: spreadsheets, ticket exports, screenshots. It worked once, and it is quietly falling apart under quarterly operation, because manual evidence assembly does not survive contact with staff turnover and audit cadence.
The second group made the evidence a by-product of the tooling: scanning runs continuously across applications, dependencies, containers, and hosts; findings land in one queue with SLAs and an audit log; third-party artifacts and supplier SBOMs are analyzed and monitored like first-party code. When the examiner asks, the answer is an export, not a project.
The airgap wrinkle
A detail specific to financial infrastructure: the environments DORA cares most about are often the least connected. Core processing networks, settlement systems, and trading infrastructure are segmented or fully airgapped, which quietly rules out SaaS scanning platforms for exactly the systems supervisors care most about. Tooling that operates entirely inside the perimeter is not a preference in this sector; it is a deployment prerequisite.
If your DORA posture is still manual
The gap is closable in a quarter, because the capabilities are ordinary: continuous scanning, one prioritized queue, SLA tracking, an audit trail, and third-party artifact analysis. That stack is precisely what SecuNexa deploys inside a financial network, and our DORA guide maps each supervisory expectation to the evidence the platform produces. The examinations are not getting lighter; the evidence might as well get automatic.