DORA Compliance Checklist for Software Suppliers

The Digital Operational Resilience Act (DORA) has applied since January 17, 2025. Formally, it addresses financial entities: banks, payment and e-money institutions, investment firms, insurers and the other entities listed in Article 2. Under Article 28(1), a financial entity that uses ICT third-party services remains FULLY responsible for compliance with the regulation.

But the requirements travel down the supply chain through due diligence questionnaires, contract clauses and audits. On November 18, 2025, the European Supervisory Authorities (EBA, EIOPA and ESMA) designated 19 critical ICT third-party providers for direct oversight. For most software suppliers, the bank is the final instance that checks them, and the national regulator checks the bank.

So, for a software supplier, DORA compliance means passing 3 checks by the bank: 

• a due diligence before the contract 

• DORA clauses in the contract

• testing of the software before production. 

 

Does DORA apply to software suppliers?

Yes, if a financial entity uses the supplier's software. DORA covers banks, insurers, investment firms, payment institutions and other financial entities, and in this article we say "bank" for all of them.

• Under Article 3(21), DORA introduces the term ICT third-party service provider (ICT stands for information and communication technology).
  A supplier falls under it if a bank uses its software and the supplier supports and updates it. This means the bank’s DORA checks apply to this supplier: due diligence, contract clauses and testing of the software.

• Under Article 28(3), the bank keeps a register of all its contracts with ICT third-party service providers and reports it to the regulator every year, so the supplier is already in this register.

• Under Article 3(22), a critical or important function is a function whose disruption would seriously harm the bank's finances or its services, such as core banking, payments or card processing. If the software supports such a function, the bank checks the supplier in more detail before signing and adds audit rights and penetration testing to the contract.

 

What does DORA third-party risk management check before the contract?

Before signing a contract for software that supports a critical or important function, the bank runs a due diligence: it checks the supplier against a list of points. This list is set out in Article 6 of Delegated Regulation (EU) 2024/1773, which details DORA's rules for such contracts. Here are 4 points from it that the supplier has to answer:

 

 

Under Article 6(3), the bank decides which sources it relies on for this check: its own audits, independent audit reports, the supplier's internal audit reports, third-party certifications such as ISO 27001 and other information from the supplier. 

So, to sign a contract with a bank, a supplier needs a FULL set of documents ready before the questionnaire arrives: certifications, audit reports and security testing results for every release. Without them, the bank has nothing to base its assessment on, and the contract waits until the supplier collects them.

 

What are DORA contract requirements for ICT providers?

For software that supports a critical or important function, Article 30(3) adds 2 clauses to the contract that concern the supplier's security team directly. Under 30(3)(d), the supplier takes part in the bank's threat-led penetration testing (TLPT). And under 30(3)(e), the bank, an auditor it appoints and the regulator receive unrestricted rights to audit the supplier at any time during the contract.

[IMPORTANT] An audit may start at any time during the contract. So, the supplier collects evidence continuously, release by release, and has it ready on the day the auditor asks.

 

What tests does DORA require for supplier software?

DORA requires the bank to test the software it puts into production, and software from suppliers is included.

[IMPORTANT] The source code of proprietary software is the supplier's intellectual property, and a license agreement often doesn't include access to it. So, the bank needs other evidence that the code was tested.

[NOTE] DerScanner runs on-premises, so neither the supplier's code nor the bank's binaries leave the internal network during the scan.

 

DORA compliance checklist for software suppliers

We've put the artifacts that an auditor or a bank asks for into one checklist in How to Build an AppSec Evidence Pack Before the Audit.

 

If you're preparing for a DORA due diligence or audit and want to test DerScanner on your own codebase, book a demo or request a PoC. We're always up for a chat.