What a bank’s vendor-risk team will ask you under DORA

The questionnaire often arrives just after the demo went well. A bank, a payment institution or an insurer wants to use your software, and its third-party risk team sends a spreadsheet. Since 17 January 2025 many of its rows trace back to one law: the Digital Operational Resilience Act, Regulation (EU) 2022/2554.

This note is for the engineering or security lead at the supplier. It maps what DORA requires the bank to assess and put in writing to what you can prepare. DORA does not prescribe the questionnaire itself. It is our reading of the regulation, not legal advice, and your customer’s lawyers will bring their own templates.

DORA binds the bank. The contract binds you

DORA names ICT third-party service providers among the entities it covers (Art. 2(1)(u)), but most of what it expects from them arrives indirectly. The financial entity “remains fully responsible” for compliance when it uses your service (Art. 28(1)(a)). To carry that responsibility it must do due diligence before signing (Art. 28(4)), record the arrangement in a register of information (Art. 28(3)) and set out specific clauses in writing (Art. 30).

Direct EU oversight is reserved for providers the European Supervisory Authorities designate as critical. The first published list, from 18 November 2025, names 19 of them, among them Amazon Web Services, Google Cloud, Microsoft and SAP. Every name on it is a large IT, cloud or data provider. For a smaller supplier, the exposure is its customers’ contracts.

The first question: is it a critical or important function?

Before signing, the bank must assess whether the contract “covers the use of ICT services supporting a critical or important function” (Art. 28(4)(a)). The answer decides which additional clauses the contract needs. Every ICT contract must cover the points in Art. 30(2). For critical or important functions, Art. 30(3) adds performance targets, tested contingency plans, audit rights and an exit strategy, and Delegated Regulation (EU) 2024/1773 sets the policy the bank follows for those contracts, from due diligence to exit.

Six things worth having ready

• A service description and a data-location map. Art. 30(2)(a) and (b) want the functions described and “the locations, namely the regions or countries” where they run and data is processed. Include your cloud provider’s regions.
• An incident procedure with times in it. Art. 30(2)(f) requires you to assist in ICT incidents at no additional cost, or at a cost set in advance. The bank’s reporting deadlines are short, as the next section shows.
• Identifiers for you and your subcontractors. The register templates in Implementing Regulation (EU) 2024/2956 identify providers by LEI or EUID. For critical or important functions, the direct provider must make sure that subcontractors effectively underpinning the service have one too (Art. 3(5) and (6)).
• A subcontractor list and a change process. Under Delegated Regulation (EU) 2025/532, the contract names what may be subcontracted and on which conditions. Material changes need notice “well in time”, and you may implement them only once the bank approves or does not object.
• Testing evidence you can share. For critical or important functions, the bank gets “unrestricted rights of access, inspection and audit”, and may agree “alternative assurance levels” where other clients’ rights are affected (Art. 30(3)(e)). A scoped test report with re-test results can support such an arrangement, if the customer agrees it meets its needs.
• An exit plan. Art. 28(8) requires exit strategies for critical or important functions, and Art. 30(3)(f) a mandatory adequate transition period. Know how a customer gets its data back, and for how long you keep the service running.

The incident clock is theirs. It starts with you

When a bank classifies an ICT incident as major, it must notify its authority within four hours of the classification and, as a rule, no later than 24 hours after becoming aware of the incident. An intermediate report follows within 72 hours of the initial notification, and a final report within a month of the latest intermediate one (Delegated Regulation (EU) 2025/301, Art. 5). If your outage is the cause, your notice may be how the bank first learns of it, so it needs enough detail for the bank to classify the incident quickly.

A bank may outsource the reporting to a third-party provider, but stays fully responsible for it (Art. 19(5)). Either way, expect contracts to ask for named contacts and a notification time measured in hours.

Testing: yearly, independent, sometimes threat-led

Financial entities other than microenterprises must test “at least yearly” all ICT systems and applications supporting critical or important functions (Art. 24(6)), with independent testers, internal or external (Art. 24(4)). Art. 25 lists the tests, from vulnerability scans and source code reviews to penetration testing. These duties sit with the bank and cover its own systems; for a supplier they arrive as contract terms and requests for evidence. Entities selected by their authorities also run threat-led penetration testing (TLPT) at least every three years (Art. 26). A contract for a critical or important function must commit you to “participate and fully cooperate” in it (Art. 30(3)(d)), and Art. 26(4) lets a provider contract the tester directly for a pooled test.

This is where the quality of evidence decides how much work a review takes. A report that names the scope, the tested revision, the date and the re-test answers several rows at once. Our note A finding is not a fix describes what such a record should contain.

One thing to do this week

Ask each regulated customer two questions. Do you classify our service as supporting a critical or important function? Which Article 30 clauses are missing from our current contract? The answers show what the next contract review must address. Proportionality applies (Art. 4), and some smaller entities use a simplified framework (Art. 16), so the depth will differ from customer to customer.

Bracemont is in development: security testing for fintechs and their suppliers, with evidence built for reviews like these. Join the waitlist to hear when it opens.