DORA secure development: code review and test data rules

What DORA requires for secure development and who pays to meet it

If your organization is a financial entity or an ICT provider preparing for DORA, you need to show how you build and buy software. Article 16 of Delegated Regulation (EU) 2024/1774 requires every ICT system to be tested and approved before first use and after maintenance, with source code reviewed through static and dynamic testing, and third-party and open-source code analysed before it reaches production. What this costs you depends on how many systems are in scope, how critical each one is to important or critical functions, and how much usable evidence already exists in your delivery pipeline. A team with mature code review, tested release gates and a current software inventory starts well ahead of one that has none of these.

You own the controls. Your management body accountable for ICT risk, your ICT function and your system owners decide what is tested, how often, and who approves a release. An implementation partner such as DeployOpen can plan, configure and document the testing pipeline, the code review tooling and the evidence trail inside your own environment. Only an independent auditor or the competent authority assesses whether the result meets the requirement. Ask any partner to state in writing which parts of the work it performs and which remain with your staff.

The cost components are predictable even though the totals are not. One-time effort includes mapping existing build and release processes to Article 16, setting up scanning and test environments, and writing the procedures. Recurring effort includes triaging findings, maintaining rules, reviewing new third-party components and keeping the inventory current. Ask for a quote that separates these two streams, lists the systems and environments covered, names the evidence each deliverable produces, and states what your own staff must supply, such as access to repositories, pipeline administrators and named approvers.

How the secure development rules apply to in-house, bought and user-built software

When the ICT function writes the software, Article 16 of Delegated Regulation (EU) 2024/1774 applies in full. Systems must be tested and approved before first use and again after maintenance, with the depth of testing scaled to criticality. Source code must be reviewed using both static and dynamic testing, and internet-exposed systems need security testing on top. Article 15 adds project governance: a documented ICT project management policy covering planning, project risk assessment, milestones, change management and approval before production, with reporting to the management body on projects that affect critical or important functions.

Pre-production approval: a named approver signs off test results before release, and the record links to the change ticket.
Static and dynamic review: code scanning runs in the pipeline, and dynamic testing covers running builds, including authentication and input handling.
Source integrity: protected branches, signed commits or builds, and restricted deployment rights keep code from being altered between review and production.
Project records: risk assessments, milestones and management body reports for projects touching critical or important functions.

Check that each in-house system has a recorded criticality rating, and that the pipeline output is retained as evidence rather than only shown on a dashboard.

Why production data cannot simply be copied into test environments

Under Article 16(5) and (6) of Delegated Regulation (EU) 2024/1774, a financial entity's non-production environments may hold only anonymised, pseudonymised or randomised production data. A straight copy of live customer or transaction records into development, testing or staging is therefore not permitted by default. The only way around the rule is a derogation that is approved for a limited period and reported to the ICT risk management function. Before any test environment is refreshed, the team should confirm which of the three permitted forms is used, who approved the data transformation, and whether the copy process is documented well enough for an assessor to follow it end to end.

The documentation an assessor will ask for is practical. Expect to produce a description of each non-production environment and its data source, the masking, pseudonymisation or randomisation method applied, the owner of that method, and the refresh schedule. For every derogation, you need the business justification, the approval record, the start and end dates, the compensating controls applied to the copied data, and evidence that the ICT risk management function received the report. Assessors commonly sample a handful of test environments, trace their data back to the production source, and check whether the transformation was actually applied. They also look for derogations that quietly became permanent because nobody closed them.

Masking pipelines are one of the parts organizations most often outsource, because building and validating a transformation that keeps test data useful without exposing personal or financial fields is specialist work. An implementation partner can build and document the pipeline, but the financial entity still owns the decision to approve it, the derogation register and the evidence. When you scope such work, ask for the masking rules in writing, a method for proving that re-identification is not practical, and a process for re-running the pipeline after schema changes. Confirm with your own data protection and risk teams how they classify the output of each method, since that classification drives which controls apply.

What makes secure development work heavier or lighter

Five to six factors decide how much DORA secure development work an organization carries. Most of them can be controlled through scoping, architecture and tooling choices made before the first build starts, so the effort is planned rather than discovered at audit time.

Number of ICT systems supporting critical functions

Article 16 of Delegated Regulation (EU) 2024/1774 applies testing and approval before first use and after maintenance, scaled to criticality. Every system that supports a critical or important function adds a release gate, a source code review and a test record. Start by maintaining a current list of which applications support those functions, because that list sets the testing depth for each one. Ask whether the list is tied to the asset inventory and reviewed when a function is reclassified.

Internet-exposed applications

Systems reachable from the internet need security testing in addition to code review, which raises the cost of each release. Public APIs, customer portals and partner interfaces each need their own test cases and retesting after changes. Count these applications separately from internal tools, and confirm that the testing team can reproduce findings on the same build that goes to production.

In-house code versus third-party and open-source components

Each third-party or open-source package used by a critical service must be analysed before production use and tracked for vulnerabilities over time. A codebase that relies heavily on libraries generates more component records, more license checks and more upgrade work. Maintain a software bill of materials for each service, and use Dependency-Track to flag known vulnerabilities, outdated components and license risk as the inventory changes.

Teams building outside the ICT function

Business units, data teams or vendors that build or manage systems outside the ICT function fall under Article 16(9), which applies these rules on a risk basis. These teams often lack a code review habit or a separate test environment. Map who builds what, agree the minimum review and testing standard for each group, and confirm who accepts the residual risk when a team skips a step.

Existing CI/CD and code review maturity

A pipeline that already runs automated scans on every merge makes the required static and dynamic testing a routine step rather than a separate project. Teams without branch protection, protected build credentials or a defined review rule will need that work first. Ask whether reviews are recorded, whether scan results block a merge, and whether the pipeline can run scanning tools such as Semgrep Community Edition across the repositories in scope.

Proportionality principle

Article 4 of DORA scales obligations to the size, risk profile and complexity of the financial entity. A small firm with a few internally built systems can document a lighter, proportionate process, while a large bank with many critical services needs more testing depth and governance. Record the proportionality decision in the ICT risk framework, with the reasons, so that a supervisor can see why a given system received a given level of testing.

How to analyse open-source code before it reaches production

Under Article 16(7) and (8) of Delegated Regulation (EU) 2024/1774, a financial entity must analyse third-party and open-source code before it is deployed to production, and must protect the integrity of its own source code. In practice this means treating every imported library, container base image and vendored package as code that goes through the same review gate as in-house changes. Article 10(2) adds a monitoring duty: the entity must track the third-party and open-source libraries used by ICT services that support critical or important functions, so the team needs a current inventory of those components and their versions before the analysis can mean anything.

A practical starting point is a pipeline gate that blocks promotion to production until the scan results are recorded. Semgrep Community Edition (LGPL-2.1-only) scans a wide range of languages, including Java, Python, Go, TypeScript and Terraform, and can run in CI/CD pipelines against repositories on every change. Dependency-Track (Apache-2.0) complements it by consuming CycloneDX SBOMs and VEX documents, flagging components with known vulnerabilities, outdated or modified components, and licence risk, with licence use tracked by SPDX license ID. Together they produce dated scan output and component records that an assessor can sample. Confirm before relying on them that the rule sets cover your languages and frameworks, since community rules vary by language, and that your SBOM generation covers every package manager your teams use.

Article 10(2) also requires the entity to check that its ICT third-party providers handle vulnerabilities and report critical ones in a timely way. Ask vendors for their vulnerability handling process and SBOMs for delivered software, and write the reporting expectation into the contract. For self-hosted open-source platforms, the implementation partner or internal team owns the upgrade path, so the decision to accept a finding, defer it or patch it should be recorded with an owner and a reason. An assessor will look for that decision trail as much as for the scan itself.

How a DORA secure development review runs from scoping to evidence

The sequence moves from defining which systems fall under the secure development rules to a documented evidence file that internal audit or a competent authority can test. Each phase produces a named output that feeds the next.

Scope systems supporting critical or important functions
Start by listing the ICT systems that support critical or important functions, using the entity's own function mapping and register of ICT services. Include internally built software, vendor products configured in-house, and systems built or managed by business users outside the ICT function, since Article 16(9) of Delegated Regulation (EU) 2024/1774 reaches those on a risk basis. Mark which systems are internet-exposed, because they need security testing as well as code review. The output is a scoped system inventory signed off by the ICT risk management function, with each system tagged by criticality and exposure. You know it is done when every in-scope system has an owner and a stated reason for its classification.
Baseline current code review and test data practices
Collect the existing state for each in-scope system: whether source code is reviewed before release, which tools run and where, how pipelines are configured, and what data sits in development, test and staging environments. Interview engineering leads and inspect a sample of recent releases and environment copies. Compare what happens today against the requirements in Article 16 of the RTS, including testing before first use and after maintenance, and the rule that non-production environments hold only anonymised, pseudonymised or randomised production data. The output is a gap baseline with one line per requirement and the evidence reviewed. Confirm each finding with the system owner before moving on.
Close gaps in static and dynamic testing
Add or configure static analysis of source code in the build pipeline and dynamic testing for internet-exposed systems before release and after maintenance. Open-source static analysis tools such as Semgrep Community Edition can scan many common languages with community or custom rules and run in CI/CD pipelines, but the entity must confirm that the languages in its estate are covered and that rule sets match its own policy. Define who triages findings, what severity blocks a release, and how exceptions are approved. The output is a pipeline configuration record, a findings triage procedure and a set of test results tied to specific releases. Check completion by running a sample release through the gated pipeline and reviewing the recorded outcome.
Replace production data in test environments
Work through each non-production environment and identify where real customer or account data appears. Replace it with anonymised, pseudonymised or randomised datasets generated from the production schema, and restrict who can copy production data into test areas. Where a temporary derogation is needed while a replacement is built, document its scope, the approver, the period and the risk accepted, and report it to the ICT risk management function as the RTS requires. Derogations are time-limited by design, so the register should show an expiry and a closure owner. The output is a test data standard, a refreshed dataset for each environment and a derogation register. You know it is done when a sample of test databases contains no unmasked production identifiers.
Protect source code and track third-party components
Confirm that source repositories enforce access controls, protected branches and change history so that code integrity can be shown. Then build the open-source and third-party component register. Generate a software bill of materials for each in-scope system in a standard format such as CycloneDX, and load it into a component tracker such as OWASP Dependency-Track, which can flag known vulnerabilities, outdated or modified components and license risk using SPDX identifiers. Analyse new third-party and open-source code before it reaches production, and record the decision. The output is a repository access record, a component register per system and an approval log for each new package. Verify completion by checking that every deployed component appears in the register with an owner and a recorded review.
Document derogations and residual risk decisions
Bring every exception found in earlier phases into one decision log. This covers production data copies approved temporarily, findings accepted without remediation, systems exempted from dynamic testing, and components retained despite open issues. Each entry needs the risk owner, the reasoning, the compensating control, a review date set by the entity and a link to the affected system. Route the log to the ICT risk management function and, where the project affects critical or important functions, make sure the reporting to the management body described in Article 15 of the RTS covers it. The output is a signed exception log. Confirm the log is complete by testing a random sample of exceptions against the system inventory and the component register.
Assemble the evidence file for audit and supervision
Gather the artefacts into one structured file per system: scoping record, baseline, pipeline configuration and sample scan results, test data standard and environment attestations, source access records, SBOM and component register, approval logs, and the exception log. Map each artefact to the RTS article it supports so that internal audit can trace a requirement to its proof. Ask internal audit to test the file independently, and keep the same file ready for a competent authority request. The output is an indexed evidence pack with a version date and an owner. Note that DeployOpen can prepare systems, controls and evidence for an assessment, but only the entity's internal audit function or the competent authority assesses compliance, and no external certificate is issued for this work.

What must exist before an assessor reviews your software practices

An assessor reviewing DORA secure development will look for written rules, recorded decisions and named people before reading any code or test output. The six items below are the records that connect a software release to the requirements of Delegated Regulation (EU) 2024/1774, and each one can be checked for existence, currency and ownership.

Written ICT project management policy

Article 15 of the RTS expects a policy that covers governance, planning, project risk assessment, milestones, change management and testing, with security testing and approval before production. Check that the policy names the approvers for each stage, states how projects touching critical or important functions are reported to the management body, and carries a version date and sign-off. A policy that no project team has followed is a finding in its own right.

Test records showing approval before production

For each release, the assessor will ask for a record that the system was tested and approved before first use and after maintenance, with the test scope scaled to criticality. Check that every production change links to a test result and an approval by someone other than the developer. Gaps usually appear around hotfixes, so confirm that emergency releases produce the same records afterward.

Code review standard with static and dynamic testing

Article 16 requires source code reviews using static and dynamic testing, with security testing for internet-exposed systems. The standard should state which tools run on each repository, which findings block a merge, who can accept a risk, and how dynamic testing is run against deployed builds. Confirm that the standard names the internet-exposed systems it covers, because the assessor will test that list against your asset inventory.

Inventory of open-source and third-party components

Article 10(2) of the RTS expects tracking of third-party and open-source libraries used by ICT services that support critical or important functions. The inventory should list each component, its version, its license and the service it supports, and it should be generated from build outputs rather than typed by hand. Check that every component has an owner and a record of its security analysis before it reached production, as Article 16 requires.

Anonymisation procedure for test data

Article 16 allows non-production environments to hold only anonymised, pseudonymised or randomised production data. The procedure should name the technique for each data class, the person who approves a dataset before it moves, and how the copy is tracked and deleted. Ask for a sample dataset and check it for real identifiers, since an assessor may take one and test it.

Derogation log and named owners

Any use of unmasked production data in a test environment needs a derogation approved for a limited period and reported to the ICT risk management function. Keep a log with the justification, approver, start and end dates, and closure evidence, and make sure each control in this list has a named owner with authority to act. An empty log is acceptable only if the team can show how it confirmed that no derogations were in use.

Which tooling and delivery model fits your software estate

This table compares three ways to run DORA secure development testing: in-house tooling operated by the entity, self-hosted open-source tooling with an implementation partner's help, and outsourced testing by an independent tester. Read each row for when the model fits and which evidence it produces, then match the model to how much of your code and third-party software sits in critical or important functions.

Model	When it fits	Evidence it produces	Watch for
In-house tooling run by the entity	Mature engineering teams with staff who can tune scanners, triage findings and keep pipelines running	Scan configurations, pipeline logs, triage records and approval history kept by the entity's own ICT function	Gaps in coverage for languages or repositories nobody owns, and reliance on individuals who maintain the rules
Self-hosted open-source tooling with an implementation partner	Entities that want scanning inside their own infrastructure and need help installing, integrating and documenting it	Versioned scan results from CI/CD, component inventories and license records, plus the documented procedure the entity owns	Community rules may need custom tuning, and the entity must still approve exceptions and remediation deadlines
Outsourced testing under an independent tester	Systems that are internet-exposed or support critical functions and need an external view of code and applications	Independent test reports with scope, method and findings, which the entity tracks to closure in its own register	Testing is point-in-time unless repeated, and the entity must still own code review, approval and remediation
Static code review in the pipeline	Every repository that builds software used in production, including user-built systems	Pipeline results for each commit or merge request, showing rule set, language coverage and blocked findings	Scanning language coverage must match the stack, so confirm supported languages for each repository
Dynamic testing of internet-exposed systems	Applications and APIs reachable from the internet or from third parties	Test scope, tool versions, authenticated test results and retest evidence after fixes	Dynamic tests need a stable test environment that does not hold live production data
Software composition and open-source analysis	Any estate that relies on third-party or open-source libraries in services supporting critical or important functions	CycloneDX SBOMs, vulnerability and license records, and VEX statements showing decisions on each component	Inventories go stale unless they regenerate on each build, and each decision needs a named owner
Test data controls	Any entity that copies production data into development or test environments	Records of anonymisation, pseudonymisation or randomisation methods and any approved, time-limited derogations	Derogations must be reported to the ICT risk management function, so confirm the approval path before copying data
Source code protection	Teams that host code on shared or self-managed platforms	Access logs, branch protection settings, signed commits or release records, and reviews of who can change code	Repository permissions often drift, so review them on a fixed schedule rather than only at audit time

Who owns the controls, who prepares the evidence and who assesses it

The financial entity remains accountable for its ICT risk management framework under DORA, including the secure development rules in Article 16 of Delegated Regulation (EU) 2024/1774. Its own team decides what the rules mean for its systems, approves releases and accepts residual risk. No partner can take those decisions on the entity's behalf.

Policy and scope: Writing the ICT project management and secure development policy, and defining which systems are internet-exposed or support critical or important functions.
Approvals: Signing off testing results and approving systems before first production use and after material maintenance.
Risk acceptance: Deciding whether to accept open findings from code review, dependency analysis or dynamic testing, and recording who accepted them.
Derogations: Requesting and documenting any limited-period derogation that allows production data in a non-production environment, and reporting it to the ICT risk management function.
Third-party and open-source decisions: Deciding whether to deploy third-party or open-source code after analysis.

Before engaging any partner, confirm which of these decisions your governance documents assign to named roles, and check that those approvers are not the same people who build the code.

Questions buyers ask about DORA software security

Can we meet the DORA secure development requirements in-house?

Yes, a financial entity can meet these requirements with its own staff, because DORA places the duty on the entity itself, not on an outside firm. The question is capacity and skills. Your team needs to show that every ICT system is tested and approved before first use and after maintenance, that source code reviews combine static and dynamic testing, and that open-source code is analysed before production. Many teams already run some of this in CI/CD. The gaps are usually documentation, risk-based scoping for systems built by business users, and evidence that a reviewer can follow later. Ask yourself whether your engineers can produce that evidence on request without pulling people off delivery work.

What drives the effort and cost of DORA secure development work?

The main drivers are the number of applications, how many of them support critical or important functions, how much code is in-house versus third-party or open-source, and how many non-production environments hold data copied from production. Cost has one-time parts, such as setting up scanners, pipelines, test data masking and baseline documentation, and recurring parts, such as running scans, triaging findings, retesting after maintenance and keeping the evidence current. Each cost is paid to a different party: internal staff time, tool licences or hosting, and any external testers or implementation partner. When you ask for a quote, request a line-by-line scope listing systems in scope, tools, deliverables and who performs each task. No cost figure applies to every organization, so use the written scope to compare options.

How long does it take to prepare for these requirements?

Preparation time depends on how far your current practice is from the rules, not on a fixed period. An organization with mature pipelines, tested release gates and masked test data will mostly need to document and extend what exists. An organization without automated code review, with production data copied into test systems or with unmanaged open-source dependencies will need more work before evidence is consistent. Sequence matters: inventory systems and their criticality first, then set up scanning and approval gates, then clean test data, then write the policy and evidence trail. Ask any partner for a phased plan with dependencies, and confirm with your competent authority or internal audit what evidence they expect to see.

What does the work need from development and risk teams?

Development teams need to own the testing gates, fix findings within agreed deadlines and keep pipelines running. Risk and compliance teams need to define which systems are critical or important, set the risk basis for user-built systems, approve any derogation that allows production data in non-production environments and review the project management and change records that show testing before production. Security engineers typically configure the tools and triage results. Management body reporting is needed for projects affecting critical or important functions. Agree these responsibilities in writing at the start so that nobody assumes another team is keeping the evidence.

Is open-source software in scope for DORA secure development?

Yes. DORA's technical standard requires entities to analyse third-party and open-source code before it is deployed to production, and to track open-source libraries used by ICT services that support critical or important functions. This applies whether the code is a library you embed, a self-hosted platform you deploy or a component pulled in through a build pipeline. In practice you need a software bill of materials for each system, a licence and vulnerability review, and a record of who approved each component. Tools such as Semgrep Community Edition for code scanning and OWASP Dependency-Track for component tracking can support this work, but you should confirm each tool's language coverage and licence terms against your own environment before relying on it.

Does DeployOpen certify that our software meets DORA?

No. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, and runs security testing that can produce evidence for your assessment. It does not issue audit reports, attestations or certifications. DORA also does not provide a certification scheme. Supervisory authorities assess compliance using their own powers, and the only authority-issued attestation the Regulation provides for concerns threat-led penetration testing. Your competent authority, or an independent assessor where your governance requires one, decides whether your evidence is sufficient. Ask any implementation partner to state its role in writing, and make sure your own governance owns the final conclusions.

How DeployOpen scopes and prepares secure development evidence

DeployOpen works from a fixed scope agreed in writing before any work starts. For secure development under DORA, that scope usually names the repositories and pipelines in play, the systems that support critical or important functions, the test environments that hold data, and the open-source components to be analysed. Deliverables and timelines follow from that brief, and the quote is built from the written scope rather than from a standard price list. Before signing, ask the proposal to list which repositories are in scope, which languages they use, how many pipelines run them, and which environments receive production data copies. Those answers drive the effort more than any headline figure.

Within that scope, DeployOpen implements and hardens self-hosted open-source tooling inside the client's own cloud accounts, data centers or air-gapped networks. In practice this means setting up a static analysis engine such as Semgrep Community Edition in the existing CI/CD pipeline, configuring its rules and triage process, and deploying OWASP Dependency-Track to hold software bill of materials and vulnerability data for third-party and open-source libraries. It also covers the anonymisation or pseudonymisation steps for test data, and the access controls protecting source code. The client keeps ownership of its controls, approves each rule set and decides what risk acceptances are recorded.

DeployOpen then prepares the code review, test data and open-source analysis evidence and documents it so the client's own assessor can test it. That evidence includes pipeline configurations, scan reports, triage records, data masking procedures and approval records for systems before first use. DeployOpen does not issue audit reports, attestations or certificates. Those come only from the independent auditor or assessor the organization appoints, and the organization decides how much of the evidence that assessor will accept. Confirm early which evidence format and retention period your assessor expects, and agree that format in the written scope.

DORA secure development: code review, test data and open-source code