Picture a mid-size digital bank on the Thursday before a release. The build is green, and someone from ICT risk asks two quiet questions: who approved this change, and can you show it wasn’t the person who wrote it? Then a third: which data did the regression suite use? If the answer takes an afternoon of screenshots and chat history, the release slips, and the gap resurfaces in front of an auditor.

DORA doesn’t pick your test tool. It asks for controlled change, a standing resilience testing program, and the understanding that outsourcing the work never outsources the responsibility.

Most of that is good engineering that leaves evidence behind: a receipt, not a report, printed by the pipeline as each change happens. By the end you’ll know what to ask for at every release, and how a nearshore team can carry the work inside your controls. For delivery, see our Fintech and digital banking QA and CI/CD service.

Why release week gets frantic, and what DORA asks for

DORA requires documented, risk-based ICT change management (Article 9(4)(e)), with every change recorded, tested, approved and verified, plus independence between who approves and who implements (RTS Article 17).

The frantic Thursday rarely comes from bad engineering. It comes from controls that live in people’s heads: the trusted reviewer, the remembered test run, the “temporary” production extract. DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 and turns those habits into duties. The detail sits in the regulation and in the regulatory technical standards (RTS) on the ICT risk management framework, Delegated Regulation (EU) 2024/1774.

The duty that shapes daily work is Article 9(4)(e). You need documented policies, procedures and controls for ICT change management, covering software, hardware, firmware, systems and security parameters. They must be risk-based and part of the overall change process, so all changes are recorded, tested, assessed, approved, implemented and verified in a controlled manner, and the process must be approved by appropriate lines of management.

Article 8 adds identification. Entities other than microenterprises must perform a risk assessment upon each major change in the network and information system infrastructure, or in processes affecting ICT supported business functions, and keep asset inventories updated after such changes.

The RTS fills in the how. Its Article 17 says the change procedure must include a check that ICT security requirements are met, independence between the functions that approve changes and those that request and implement them, defined roles for planning, testing and quality assurance, and a documented purpose, scope, timeline and expected outcomes. It also needs fall-back procedures for failed changes, and safeguards for emergency changes, which are reviewed and approved after the fact.

Article 16 of the same RTS covers acquisition, development and maintenance. All ICT systems must be tested and approved before use and after maintenance, with testing commensurate to criticality. The procedure must include source code reviews covering static and dynamic testing, security testing of software packages no later than integration, and controls on source code integrity, including code delivered by a third party.

Entities eligible for DORA’s simplified framework have lighter requirements; most banks should assume the full set applies.

Testing is a program, not a phase

DORA expects a risk-based digital operational resilience testing program from all entities except microenterprises, with at least yearly tests of systems supporting critical or important functions. Articles 24 and 25 set that baseline. The program must include tests such as vulnerability assessments and scans, open source analyses, network security assessments, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. Tests must be performed by independent parties, internal or external, and an internal tester needs sufficient resources and no conflict of interest. Findings must be prioritized, classified and remedied, with an internal method to confirm each weakness is fully addressed.

Threat-led penetration testing (TLPT) is the heavy end, covered by Articles 26 and 27. It applies only to entities that competent authorities identify, at least every three years. It covers several or all critical or important functions, runs on live production systems, and includes systems supporting those functions even where they are outsourced. The competent authority validates the scope.

Where an ICT third-party service provider is in scope, the bank must ensure its participation and keeps full responsibility for compliance. Testers must meet the suitability requirements of Article 27: banks using internal testers must contract external testers every three tests, and significant credit institutions under ECB supervision may only use external testers. The detailed methodology, aligned with TIBER-EU, is in Delegated Regulation (EU) 2025/1190.

The partner writes the code, the bank keeps the responsibility

The bank stays fully responsible for compliance when a nearshore partner builds or tests its software (DORA Article 28).

It’s tempting to think a contract moves the risk to the supplier. It doesn’t. When a nearshore partner builds or tests bank software, the bank remains fully responsible for compliance, and the arrangement falls under DORA’s third-party risk rules in Articles 28 to 30. The partner becomes an ICT third-party service provider, with contract terms, oversight and exit planning to match.

Article 28 asks the bank to manage the arrangement within its ICT risk framework and record it in the register of information. Before signing, it must assess whether the service supports a critical or important function, identify the risks, run due diligence and assess conflicts of interest.

Article 29 adds a check on concentration risk and on subcontracting chains, including subcontractors outside the EU. Our outsourcing vendor selection process turns those checks into a scorecard.

Article 30 sets the minimum contract terms: a clear description of services, the locations where work is done and data is processed, data protection provisions, service levels, assistance in ICT incidents, cooperation with competent authorities, termination rights and participation in the bank’s ICT security awareness and resilience training.

Where the service supports a critical or important function, the contract goes further, with precise quantitative and qualitative service levels, notice and reporting duties, the supplier’s own contingency plans and security measures, participation in the bank’s TLPT, unrestricted rights of access, inspection and audit, and exit strategies with a mandatory transition period. Delegated Regulation (EU) 2024/1773 sets out what the bank’s policy on such contracts must contain. For release work, the location clause shapes where test data may live, and the audit clause means the partner’s pipeline, logs and access records must be ready to show to the bank, its auditors and its supervisor.

What a DORA-ready release pipeline looks like

That’s a DORA-ready release discipline: every control the regulation names is an automated step or a recorded decision, so evidence is a by-product of shipping, not a project before the audit.

Replay the scene. The same questions come, and the release manager opens one link: change ticket, test run tied to the build, an approver who isn’t the author, deployment log, data source. The same pattern works for models; see getting AI use cases into production under bank controls.

Keep production and test apart

RTS Article 8 requires production to be separated from development, testing and other non-production environments, considering all components, including accounts, data and connections. Testing in production is allowed only where it is clearly identified, reasoned, time-limited and approved. In practice we’d expect separate cloud accounts or subscriptions, separate credentials, no shared service accounts, and a ticket for any production test.

Test data is where good intentions slip. Under RTS Article 16(5) and (6), non-production environments may only store anonymized, pseudonymized or randomized production data, and the bank must protect integrity and confidentiality there too. Production data may be used only for specific testing occasions, for limited periods, with approval by the relevant function and reporting to the ICT risk management function. Build synthetic or masked datasets into the pipeline, so no regression run needs a production extract.

Gates every merge passes

Each merge should pass the same gates, in the same order, with results stored. This is the checklist we’d expect:

  1. Build from version control with signed commits or protected branches.
  2. Unit and integration tests, with coverage tracked against an agreed threshold.
  3. Static analysis and dependency scanning, including open source components, which RTS Article 16(8) requires to be analyzed, where feasible, before production.
  4. Dynamic security testing for internet-exposed systems, as required by RTS Article 16(3).
  5. A build artifact with a recorded hash, promoted unchanged from test to production.

Approvals nobody can bypass

RTS Article 17 requires independence between whoever approves a change and whoever requests and implements it, so put it in the tooling: authors can’t approve their own merge requests, the release approver is a named bank role, and production deployment credentials are held by the pipeline, not by engineers.

RTS Article 12 requires change management events to be logged and logs to be protected against tampering and deletion, so keep pipeline and deployment logs in a store the delivery team cannot edit.

Regression, performance and the judgment call

Compatibility, performance and end-to-end testing are on DORA’s list, so run a risk-based regression suite on every release, scale it up for changes touching critical or important functions, and schedule performance, load and failover tests before peak periods and major releases. Record the scope decision: “commensurate to criticality” is a judgment auditors will ask about.

Rollback you have actually rehearsed

A rollback plan on a wiki page is a hope. RTS Article 17 asks for fall-back procedures to abort or recover from failed changes, so make rollback a tested pipeline step: blue-green or canary deployment, reversible database migrations, and a rehearsal at least before each major release.

RTS Article 8 also asks for restart, rollback and recovery procedures. Emergency changes need a fast path with safeguards and a retrospective approval within a defined window.

The evidence pack: one receipt per release

An evidence pack proves a given release followed the change policy, from request to verification. If it takes more than a few minutes to assemble for any production release, the pipeline is not producing enough evidence.

Control Evidence Regulatory hook
Change recorded and assessed Change ticket with purpose, scope, timeline, expected outcome, risk and security impact assessment DORA Art. 9(4)(e); RTS Art. 17(1)(a), (d), (h)
Change tested Pipeline run with unit, integration, regression and security test results tied to the commit and artifact hash DORA Art. 9(4)(e); RTS Art. 16(2) to (4)
Independent approval Approver identity and timestamp, showing the approver is not the author or implementer RTS Art. 17(1)(b)
Controlled implementation Deployment log showing the approved artifact went to production through the pipeline DORA Art. 9(4)(e); RTS Art. 12
Verified after release Smoke test and monitoring results, sign-off that the change achieved its outcome DORA Art. 9(4)(e)
Fall-back ready Rollback plan and last rehearsal record RTS Art. 8(2)(c)(iii), Art. 17(1)(e)
Test data compliant Data source record showing masked or synthetic data, or the approval for a production data exception RTS Art. 16(5) and (6)
Findings remediated Defect and vulnerability records with priority and closure evidence DORA Art. 24(5)

Where the bank ends and the partner begins

A nearshore partner works inside the bank’s change, testing and access controls, not alongside them. The bank owns the policies, approvals, risk acceptance and the relationship with the supervisor; the partner supplies engineering and QA capacity and produces evidence in the bank’s format.

Day to day, the bank sets change policy, risk appetite and pipeline standards, and approves production changes, test scope for critical or important functions, and test data sources and exceptions. The partner prepares change records, operates the pipeline, and writes and runs automated, regression and non-functional tests on masked or synthetic data only, through named least-privilege accounts the bank reviews regularly, with no production write access by default. The partner generates evidence packs and answers audit requests, while the bank presents to auditors and supervisors and scopes and leads TLPT and resilience testing, where the partner participates and remediates if in scope. One honest limit: a partner can’t take compliance decisions off your hands, and shouldn’t try.

That’s how our QA and testing and DevOps teams work with regulated financial clients. For Raiffeisen, we introduced automated testing and CI/CD pipelines for banking platforms. For Allianz, we implemented automated testing across insurance platforms. We’ve also supported regulated financial services delivery for Dell Financial Services. Client data is never used to train shared models without a written agreement.

Before you shortlist a partner, us included, use our questions to ask a fintech AI or software partner and the due diligence questions for any regulated software partner.

Talk to an architect

If you take one thing away, make it this: under DORA, evidence should be a receipt your pipeline prints for every change, not a report someone writes before the audit.

This week, fill in the evidence pack table for your last production release; every row where the answer is “we’d have to ask someone” is a gap. Bring one release process that feels heavy or one audit finding you need to close. We will map it against DORA and show where automation can carry the evidence.

Talk to an architect

Frequently asked questions

Does DORA require a specific CI/CD tool or testing framework?

No, DORA is technology-neutral. Any toolchain that enforces documented change management, testing commensurate to criticality, independent approval and protected logs, and keeps the records, can meet the requirement.

Can developers approve their own releases under DORA?

Not on their own. The RTS on the ICT risk management framework requires mechanisms that ensure independence between the functions that approve changes and those that request and implement them, so authors don’t approve their own changes and production approval sits with a named role outside the delivery team.

Can we use production data in test environments?

Only as an exception. Non-production environments should hold only anonymized, pseudonymized or randomized production data. Production data may be stored only for specific testing occasions, for limited periods, after approval by the relevant function and with the occasions reported to the ICT risk management function.

Does every bank have to run threat-led penetration testing?

No, only the financial entities that competent authorities identify based on impact, financial stability and ICT risk criteria, and they must run it at least every three years. All other entities, apart from microenterprises, still need a risk-based testing program with at least yearly tests of systems supporting critical or important functions.

If a nearshore partner writes our code, who is responsible under DORA?

The bank is. Article 28 states that financial entities remain fully responsible for compliance when they use ICT third-party services, and the contract must include the Article 30 terms, such as audit rights, service levels, data locations and exit provisions where the service supports a critical or important function.

What should a DORA evidence pack contain for a single release?

The change request and risk assessment, test results tied to the exact build, independent approval, the deployment log, post-release verification, the rollback plan and the test data source. Your pipeline should generate it automatically for every production release.