Guide · Cybersecurity · DORA

Application security under DORA: SAST, DAST, SBOM and a secure software lifecycle for banking and insurance

DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025 and turns software security into a supervised obligation: financial entities must identify, protect, detect and test the ICT systems that support their critical or important functions, and prove it with evidence. This guide translates those obligations into concrete application-security practices (SAST, DAST, SBOM, secrets management, resilience testing) and explains how we build them into the software lifecycle of banks and insurers.

This is not legal advice: it is an operational guide for CISOs, CTOs, engineering leads and compliance teams. Regulatory references checked on 15 September 2026; the specific obligations depend on the type of entity and the criticality of each function.

What DORA requires from software, and where it says so

DORA names no tools or methodologies: it sets outcomes. Its ICT risk management framework (Articles 5 to 16) requires entities to inventory assets, protect them, detect anomalies and recover; the incident chapter (Articles 17 to 23) requires classification and notification; the digital operational resilience testing chapter (Articles 24 to 27) requires an annual testing programme; and the third-party chapter (Articles 28 to 30) extends all of the above to the software and services the entity buys.

Delegated Regulation (EU) 2024/1774, which develops the ICT risk management framework, goes into the detail a development team cares about: the ICT project management policy must cover the acquisition, development and maintenance of systems, every requirement, including security requirements, must be tested before approving a system for production, and the results of security tests must be tracked and turned into updated measures without undue delay where the system supports a critical or important function.

Article 8 — identification: an up-to-date inventory of ICT assets, dependencies and the functions they support.
Article 9 — protection and prevention: security policies, patch and update management, segmentation and access control.
Article 10 — detection: anomaly-detection mechanisms with alert thresholds and continuous monitoring.
Article 11 — response and recovery: tested ICT business continuity and recovery plans.
Articles 24 and 25 — testing: an annual programme that includes, among others, vulnerability assessments and scans, open-source analyses, source code reviews where feasible, scenario-based tests, end-to-end tests and penetration tests.
Article 26 — TLPT: threat-led penetration testing (TIBER-EU framework) at least every three years for the entities designated by the authority.
Articles 28 to 30 — third parties: contracted ICT software and services fall under the same framework, with minimum contractual clauses and a register of arrangements.

From regulation to practice: nine application-security controls

These are the controls that cover the obligations above in a modern software lifecycle. The order matters: each one produces the evidence the next one needs and the supervisor will ask for.

1. Inventory and classification by critical function

Every application, service and component linked to the business function it supports and to its criticality. Without this you can neither prioritise nor justify the scope of testing (Article 8).

2. Threat modelling at design time

Before writing code: which assets the application handles, who could attack it and through which paths. It is the cheapest control and the one that prevents the most defects; it feeds the security requirements the RTS requires you to test.

3. SAST on every code change

Static analysis integrated into the pipeline, with gates that block promotion to production by severity. It is the practical way to meet the source code review DORA asks for "where feasible" (Article 25) and to leave a trail of every finding and its fix.

4. SCA and SBOM: the software supply chain

An inventory of third-party components (SBOM) and composition analysis to track their vulnerabilities over time. It covers the third-party risk of Articles 28 to 30 and the supply-chain security that NIS2 also requires.

5. Secrets management and infrastructure as code

No secrets in repositories or images; credentials rotated and managed centrally; infrastructure declared as code and analysed like the software itself (Article 9).

6. DAST and penetration testing before production

Dynamic testing against the pre-production environment for every relevant release, plus penetration testing planned within the annual programme (Articles 24 and 25). Findings enter the same remediation flow as SAST findings.

7. Vulnerability management with deadlines by criticality

A single vulnerability register (code, components, infrastructure) with remediation deadlines by severity and function criticality, and evidence of patching (Article 9).

8. Logging, detection and response

Centralised logs, continuous detection (SIEM/SOC) and rehearsed response playbooks (Articles 10 and 11). Major incidents are classified and notified to the authority within the deadlines of DORA's technical standards: an initial notification within hours, then intermediate and final reports.

9. Resilience testing and TLPT

A documented annual programme for every critical or important system (Article 24) and, for designated entities, threat-led penetration testing every three years (Article 26), with findings fed into the remediation plan.

Useful overlaps: NIS2 and ISO/IEC 27001

For financial entities DORA is the sector-specific law and prevails over NIS2 (Directive (EU) 2022/2555) in what it regulates, but it pays to know both: NIS2 applies to other companies in the group and to many suppliers, and its Article 21 lists measures that match the controls above point by point: security in the acquisition, development and maintenance of systems, vulnerability handling and disclosure, supply-chain security, cryptography, access control and multi-factor authentication.

ISO/IEC 27001:2022 is the most efficient way to organise the evidence: the Annex A controls on the secure development lifecycle, application security requirements, secure architecture, secure coding, security testing in development and acceptance, outsourced development and separation of environments (8.25 to 8.31) are exactly what a DORA inspector wants to see documented. Vermont Solutions operates under ISO/IEC 27001:2022 certification.

A twelve-point checklist for the CISO and the CTO

Application inventory linked to critical or important functions, reviewed at least yearly.
Security requirements defined per application and tested before every promotion to production.
SAST with quality gates in the pipeline and evidence of remediation per finding.
SBOM generated on every build and composition analysis with alerts for new vulnerabilities.
Centralised secrets management and infrastructure-as-code scanning.
DAST in pre-production and an annual penetration test documented within the testing programme.
A single vulnerability register with remediation deadlines by severity and criticality.
Centralised logs, continuous detection and rehearsed response playbooks.
A procedure for classifying and notifying major incidents, with deadlines and owners.
Security, audit and exit clauses in ICT software and service contracts.
An annual resilience testing programme approved by management and, where applicable, TLPT planned.
Evidence of all of the above generated by the process itself, not gathered by hand before the inspection.

How we do it at Vermont Solutions

We integrate the controls into the entity's delivery pipeline, not into a separate project: SAST, composition analysis and SBOM on every build, DAST in pre-production, secrets management and infrastructure-as-code analysis, with quality gates that leave automatic evidence. We design least-privilege identity models (IAM/PAM, Zero Trust) and deploy continuous visibility and detection (SIEM/SOC) with response processes aligned with business continuity.

We work on critical banking and insurance platforms that cannot stop (legacy cores, calculation grids, hybrid Kubernetes) and under ISO/IEC 27001:2022 certification. At a European insurer, hardening access (MFA on critical roles and removal of legacy protocols) raised the Microsoft 365 security score by 30% over a baseline of 11.48% with no friction for users.

Frequently asked questions

Does DORA require SAST and DAST?

It names no tools. It requires testing security requirements before production, reviewing source code where feasible and running penetration tests within an annual programme. SAST and DAST are the practical, traceable way to comply.

How often must security tests be run?

The digital operational resilience testing programme is annual for systems supporting critical or important functions (Article 24), with vulnerability assessments and penetration tests within it. Entities designated by their authority also run threat-led penetration testing (TLPT) at least every three years (Article 26).

What about software we buy from third parties?

It falls under the same framework: Articles 28 to 30 require due diligence, minimum contractual clauses (security, audit, incidents, exit) and a register of arrangements. In practice it is covered with SBOM, composition analysis and security clauses in contracts.

Does NIS2 also apply to a bank or an insurer?

For financial entities DORA is the sector-specific law and prevails in what it regulates. NIS2 remains relevant for other group companies and for many suppliers, and its Article 21 measures match the controls in this guide.

What are the deadlines for notifying a major incident?

DORA's technical standards set an initial notification within a few hours of classifying the incident as major, an intermediate report within days and a final report roughly a month later. The exact deadlines depend on the technical standard in force and on the competent authority; the internal procedure must fix them with names and hours.

Application security assessment under DORA

We review your inventory of critical applications, your delivery pipeline and the evidence available, and deliver the control plan with owners and deadlines. Nothing changes in production until the plan is approved.

Request an assessment →