All insights

DORA · Compliance

DORA and the Secure SDLC: What Your Engineering Team Needs to Prove

· 13 min read · Sebastian Andersen

Under the Digital Operational Resilience Act (DORA), a bank’s supervisor can ask how a single change reached production. DORA’s technical standards spell out what the answer must show: security requirements approved before work started, code tested before release, dependencies checked, no real customer data in test, and approval from someone other than the developer. If you build software for a bank, insurer or payment company, the same questions reach you through your client’s contract.

Most engineering teams already do much of this. Under DORA, the question is whether they can prove it. If you run a solid Secure Software Development Lifecycle (Secure SDLC), you are most of the way there.

DORA, formally Regulation (EU) 2022/2554, exists to keep financial services running when technology fails or is attacked. The main text sets the principles, while the detailed rules sit in the Regulatory Technical Standards (RTS) on Information and Communication Technology (ICT) risk management, Delegated Regulation (EU) 2024/1774. Its Article 16 (not to be confused with DORA’s own Article 16) is essentially a Secure SDLC policy written by the regulator. This post maps each requirement to your lifecycle, so you can see what to keep, what to add and what to evidence.

Who actually needs to care about DORA?

DORA covers 20 types of EU financial entities, plus the ICT companies that serve them (DORA Art. 2).

SectorEntities in scope
Banking and paymentsCredit institutions, payment institutions, account information service providers, e-money institutions
Investment and marketsInvestment firms, trading venues, central counterparties, central securities depositories, trade repositories, data reporting service providers
FundsAlternative investment fund managers, UCITS management companies
Insurance and pensionsInsurers and reinsurers, insurance and reinsurance intermediaries, occupational pension funds
CryptoCrypto-asset service providers and issuers of asset-referenced tokens (under the Markets in Crypto-Assets Regulation)
OtherCredit rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitisation repositories
TechnologyICT third-party service providers to any of the above

Some small entities within these types are left out entirely, for example alternative investment fund managers below the EU size thresholds, insurers too small for Solvency II (the EU’s capital rules for insurers), pension funds with no more than 15 members, and insurance and reinsurance intermediaries that are micro, small or medium-sized enterprises (DORA Art. 2(3)).

For everyone in scope, DORA scales. The rules apply in proportion to a company’s size and overall risk profile, and to the nature, scale and complexity of its services (DORA Art. 4). A small payment institution can run a lighter setup than a large bank, but both must be able to show the evidence.

The key rule is that a financial entity stays fully responsible for meeting DORA, even when it outsources to a software or cloud provider (DORA Art. 28(1)).

Who answers to whom under DORA Competent authorities (national supervisors, and the ECB for the largest banks) supervise financial entities directly, and EU supervisors oversee critical ICT providers directly. Financial entities stay fully responsible and pass DORA obligations to software providers and critical ICT providers through contracts. WHO ANSWERS TO WHOM UNDER DORA SUPERVISES DIRECTLY OVERSEES DIRECTLY CONTRACTS (DORA ART. 28–30) COMPETENT AUTHORITIES NATIONAL, PLUS THE ECB EU SUPERVISORS (ESAS) EBA, EIOPA, ESMA FINANCIAL ENTITIES FULLY RESPONSIBLE, ART. 5–30 SOFTWARE PROVIDERS COVERED VIA CONTRACTS CRITICAL ICT PROVIDERS 19 DESIGNATED, ART. 31–44 DIRECT SUPERVISION OBLIGATIONS PASSED ON THROUGH CONTRACTS Who answers to whom under DORA Competent authorities (national supervisors, and the ECB for the largest banks) supervise financial entities directly, and EU supervisors oversee critical ICT providers directly. Financial entities stay fully responsible and pass DORA obligations to software providers and critical ICT providers through contracts. WHO ANSWERS TO WHOM UNDER DORA SUPERVISES DIRECTLY CONTRACTS (ART. 28–30) OVERSEES DIRECTLY COMPETENT AUTHORITIESNATIONAL, PLUS THE ECB FINANCIAL ENTITIESFULLY RESPONSIBLE, ART. 5–30 SOFTWARE PROVIDERSCOVERED VIA CONTRACTS CRITICAL ICT PROVIDERS19 DESIGNATED, ART. 31–44 EU SUPERVISORS (ESAS)EBA, EIOPA, ESMA DIRECT SUPERVISION OBLIGATIONS PASSED ON THROUGH CONTRACTS
WhoHow DORA appliesWhat they are responsible forKey articles
Banks, insurers, funds, payment companies and other financial entitiesDirectly, supervised by their competent authority (national, or the ECB for the largest banks)The full ICT risk framework, including the SDLC rules in this post, testing, incident reporting and managing their providersDORA Art. 5–30,
RTS 2024/1774
Certain small or exempted entities listed in DORA Art. 16(1)Directly, under a lighter regimeA simplified ICT risk framework, set out in RTS 2024/1774 Title III instead of the Article 16 rules in this postDORA Art. 16,
RTS Title III
Software and ICT providersIndirectly, through client contractsSecurity, incident support and termination terms in every contract, plus audit rights and exit terms when the service supports a critical or important functionDORA Art. 28–30
Critical ICT providersDirectly, overseen by the EU supervisory authoritiesOversight by a Lead Overseer, who assesses their ICT risk management and can issue recommendations, on top of their contract dutiesDORA Art. 31–44

For software vendors, this means DORA arrives as security questionnaires, audit rights and questions about how you build and test your software. Having software bills of materials (SBOMs), scan results, penetration test summaries and a vulnerability disclosure process ready makes each client review easier. Only a few providers are designated as critical. The first 19, mostly large cloud and platform companies, were named in November 2025.

What DORA requires from engineering

The rules for engineering sit in two places. Article 16 of the RTS covers how software is built, and the rest of DORA covers the governance and operations around it. The lifecycle below shows the rule behind each phase, and how what you learn in operation feeds back into planning.

Secure SDLC: eight phases mapped to DORA The eight phases of a secure SDLC, from Plan to Operate, each labelled with the DORA or RTS article that applies. A feedback arrow shows lessons learned from operations feeding back into planning. SECURE SDLC · 8 PHASES MAPPED TO DORA LESSONS LEARNED FEED THE NEXT CYCLE 1PLANDORA ART. 5, 13(6) 2REQUIREMENTSRTS ART. 15, 16(1) 3DESIGNDORA ART. 8, 9 4CODERTS ART. 16(3), 16(7) 5BUILDRTS ART. 10, 16(4) 6TESTDORA ART. 24, 25 7RELEASERTS ART. 17 8OPERATEDORA ART. 10, 11, 13 Secure SDLC: eight phases mapped to DORA The eight phases of a secure SDLC, from Plan to Operate, each labelled with the DORA or RTS article that applies. A feedback arrow shows lessons learned from operations feeding back into planning. SECURE SDLC · 8 PHASES MAPPED TO DORA LESSONS LEARNED FEED THE NEXT CYCLE 1PLANDORA ART. 5, 13(6) 2REQUIREMENTSRTS ART. 15, 16(1) 3DESIGNDORA ART. 8, 9 4CODERTS ART. 16(3), 16(7) 5BUILDRTS ART. 10, 16(4) 6TESTDORA ART. 24, 25 7RELEASERTS ART. 17 8OPERATEDORA ART. 10, 11, 13

Article 16, requirement by requirement

Article 16 of the RTS has nine paragraphs. Together they tell you what your secure development policy must contain, and what your teams and pipeline must actually enforce.

Article 16 · what your SDLC policy must say and enforce
Para.RequirementYour policy must sayYour SDLC must enforce
16(1)(a)Name your security practicesWhich secure development methods and frameworks you follow (e.g. NIST SSDF, OWASP SAMM)Teams work to that standard, and any deviation is documented
16(1)(b)Define requirements up frontEvery system needs technical specs and security requirements, approved by the business owner and the ICT asset ownerNo development or purchase starts without approved security requirements
16(1)(c)Prevent tamperingHow you stop accidental or deliberate changes during development, maintenance and deploymentProtected branches, mandatory review, restricted deploy rights, signed artifacts
16(2)Test and approve before go-liveA procedure to test and approve every system before use and after maintenance, with depth matched to criticalityA release gate: tests passed and approval recorded, plus retesting after maintenance and changes
16(3)Review code, static and dynamicSource code review must cover static and dynamic testing, plus security testing of internet-facing systemsStatic (SAST) and dynamic (DAST) application security testing in the pipeline, with every finding analysed, given a fix plan and tracked to closure
16(4)Test software packages earlyPackages and dependencies are security-tested no later than integrationDependency scanning in the build that blocks known critical vulnerabilities
16(5)–(6)Keep real data out of testNon-production holds only anonymised, pseudonymised or randomised data, and is protectedData masking or synthetic data by default. Any real-data use is one-off, time-limited, approved and reported to the ICT risk function
16(7)Protect source code integrityIntegrity controls apply to code built in-house and code delivered by vendorsRepository access control, commit signing, integrity checks on delivered code
16(8)Test third-party and open-source codeVendor software and, where feasible, vendor and open-source source code are analysed and tested like your ownNo deployment without the scan, and a recorded reason when source code is not available
16(9)Include shadow ITAll of the above applies, risk-based, to tools built or run outside the IT functionAn inventory of spreadsheets, scripts and low-code apps, with a lighter review process

How much testing a system needs depends on whether it supports a critical or important function, meaning one whose failure would seriously harm the company’s finances, the continuity of its services or its compliance. Companies classify their own systems, and every system that supports such a function must be tested at least once a year (DORA Art. 24(6); microenterprises are exempt). A public payments API therefore needs far more than an internal report tool. Some firms, selected by their supervisor based on impact, systemic importance and ICT risk profile, must also run threat-led penetration testing (TLPT) on live production systems at least every three years (DORA Art. 26).

Automated scans are the baseline, not the whole testing programme. SAST, DAST and dependency scanning find known patterns, such as injection flaws and vulnerable libraries, but not flaws in business logic, authorisation or timing: a transfer from someone else’s account, a negative amount, or two identical requests that create two transfers. DORA’s testing programme must include a range of tests, and its examples run from vulnerability scans and source code reviews to scenario-based tests and penetration testing (DORA Art. 24(2), 25(1)). The tests must be carried out by independent testers, internal or external (DORA Art. 24(4)). Expert-led penetration testing of the systems that matter most finds what the scanners miss.

Paragraphs 16(4), 16(7) and 16(8) also cover code you did not write. In practice, that means an SBOM for every build, scanned and pinned dependencies, and contracts that give you security commitments and, for critical or important functions, audit rights from your vendors (DORA Art. 28–30). The SBOM also covers a separate duty to track the third-party and open-source libraries used by systems supporting critical or important functions (RTS Art. 10(2)(d)).

Around the code

Around the code · governance and operations
AreaWhat DORA asksHow to do itWhere it says so
GovernanceManagement owns ICT risk and staff are trainedA board-approved policy and secure coding trainingDORA Art. 5, 13(6)
DesignKnow your risks and dependenciesThreat modelling and mapping dependenciesDORA Art. 8, 9
AccessLeast privilege for people and pipelinesSeparate developer and production access, short-lived pipeline credentials and logged admin accessRTS Art. 8, 20, 21
EncryptionProtect data and keysEncryption in transit and at rest, no secrets in code, managed keys with rotationRTS Art. 6, 7
ReleaseControlled, approved changesChange tickets, a separate approver and a rollback planDORA Art. 9,
RTS Art. 17
OperateMonitor, patch and learnWeekly vulnerability scans of systems supporting critical or important functions, patch deadlines by severity, retests after fixes and post-incident reviewsDORA Art. 10, 11, 13,
RTS Art. 10

None of this has to slow delivery. Most of these controls run as automated gates in the pipeline. Approval is always independent of the developer, but its depth follows the risk: a low-risk change gets a quick check, a high-risk one a full review (RTS Art. 16(2), 17). Every gate logs its result, so the audit trail builds itself.

Practical example: Securing a payment API

To see how this works in practice, follow one change through the lifecycle. A payments company adds a new endpoint to its public API that lets customers schedule transfers. Governance from the Plan phase is already in place, so the change starts at requirements. Step through it below to see what happens in each phase and what evidence it leaves behind.

Example · one change through the lifecycle

A payments company adds a “schedule transfer” endpoint to its public API.

Step 1 of 7RTS Art. 16(1)(a), 16(1)(b)
Requirements

The team works to the company’s secure development standard, based on NIST SSDF. Before any code is written, the product owner, as business owner, and the payments system owner, as ICT asset owner, approve the security requirements, including strong customer authentication, per-client rate limits and an audit log entry for every scheduled transfer. Each requirement becomes an acceptance criterion with a matching test case.

EvidenceApproved requirements and test cases
Step 2 of 7DORA Art. 8, 9
Design

A threat model of the new flow maps out how an attacker might abuse it, for example by tampering with the amount, replaying a request or scheduling a transfer from someone else’s account. The design then mitigates each threat with signed requests, idempotency keys and object-level authorisation checks on every call.

EvidenceThreat model and planned mitigations
Step 3 of 7RTS Art. 16(1)(c), 16(3), 16(7), 16(8)
Code

The developer opens a pull request against a protected branch with signed commits. CODEOWNERS routes it to a payments reviewer, and secrets scanning runs on every push. The pull request also adds a new open-source library for parsing recurring schedules. The pipeline flags it as a new dependency, and the reviewer approves it after checking that it is actively maintained and has no known vulnerabilities. SAST flags a SQL injection in the scheduling query, which is fixed with a parameterised query before merge.

EvidenceSigned commits, review history, SAST results, dependency approval
Step 4 of 7RTS Art. 10(2)(d), 16(4), 16(7), 16(8)
Build

An ephemeral runner with short-lived OIDC credentials builds the container and produces a CycloneDX SBOM. The pipeline scans the dependencies, the container base image and the infrastructure-as-code templates, and blocks an older date library, already in the project, that has a known critical vulnerability, so the team pins a patched version. A fraud-scoring software development kit from a vendor is checked against the vendor’s signed release, then scanned and tested like in-house code before it is integrated. The image is signed with SLSA provenance.

EvidenceSBOM, scans, verified vendor code, signed image
Step 5 of 7RTS Art. 16(2), 16(3), 16(5) and DORA Art. 24(4), 25
Test

Staging has the same access controls as production and holds only synthetic customer data. There, authenticated DAST runs against the API using its OpenAPI specification. Because the endpoint faces the internet, it must also be security tested, and the company’s policy makes that a penetration test by an independent tester, focused on the business logic, such as negative amounts and race conditions on the idempotency key. One medium finding goes into the vulnerability action plan with an owner and a 30-day deadline, and the system owner formally accepts the risk before release.

EvidenceDAST results, pen test report, risk acceptance
Step 6 of 7RTS Art. 17
Release

The deploy job links the release to a change ticket with a risk assessment. Because it touches payments, the change is classed as high risk and gets a full review. Like every change, it is approved by someone other than the author. An admission policy only runs signed images, and a canary rollout with automatic rollback limits the impact of any fault.

EvidenceChange record, approval, rollout log
Step 7 of 7DORA Art. 10, 13, 24(6) and RTS Art. 10
Operate

Alerts fire on unusual scheduling patterns, such as many transfers to the same new payee. The stored SBOM is checked daily against new vulnerability advisories, so a newly published flaw in a running component raises a ticket straight away. The medium finding is fixed and retested within its deadline, and a new SAST rule plus a line in the coding standard stop the same bug from returning. Because the API supports a critical function, the law requires it to be tested every year, and the company’s policy makes that a new penetration test each time.

EvidenceClosed finding, SBOM monitoring, new SAST rule, yearly pen test

Five questions to ask your engineering team this week

DORA rarely asks for brand-new practices. It asks you to connect the ones you have to the rules, and keep the evidence. These five questions show quickly where you stand. Each is something a supervisor or a client’s auditor can ask, and the example above shows what a good answer looks like. Under each answer is a typical gap to look for.

Five questions · what a good answer looks like
#QuestionA good answerWhere it says so
1Can we show who approved the security requirements before work started?Requirements signed off by the business owner and the ICT asset owner, each linked to a test caseTypical gap: Requirements approved only by the development team, not by the business owner and the ICT asset ownerRTS Art. 16(1)(b)
Example: step 1
2Can we trace every security finding to a fix or a formal risk acceptance?Each finding logged with an owner and a deadline, then retested after the fix or accepted by the system ownerTypical gap: Findings marked as fixed without a retest, or accepted risks with no owner or end dateDORA Art. 24(5),
RTS Art. 10(2)(g)–(h), 16(3)
Example: steps 5, 7
3Can we show that every release was tested and independently approved?A release record with test and scan results, a penetration test where the risk calls for it, and an approver other than the developerTypical gap: Developers approving their own changes, or tests skipped for “small” releasesRTS Art. 16(2), 17
Example: steps 5, 6
4Can we list the third-party libraries in a running system, and see when one becomes vulnerable?An SBOM for every build, dependency scans that block known critical flaws, and daily checks against new advisoriesTypical gap: A vendor SDK that was never scanned, or dependency alerts that nobody follows upRTS Art. 10(2)(d), 16(4)
Example: steps 3, 4, 7
5Can we explain which systems need yearly, independent testing, and why?A classification of the systems that support critical or important functions, a testing programme that covers each of them every year, and testers independent of the teamTypical gap: No written reason why one system gets a penetration test and another does notDORA Art. 8(1), 24(4), 24(6)
Example: steps 5, 7

If the honest answer to any of them is “not sure”, start there. Pick one critical system, run a single change through the steps in the example, and close the gaps you find.

Want a second opinion on your answers, or need independent penetration testing for your DORA testing programme? SSA IT reviews your Secure SDLC against DORA, runs the penetration tests you need, and helps you build the security gates and evidence trail into your pipeline.

Get in touch.

References

Found this useful? Share it with your network.