A mid-sized European bank is choosing a vendor to build its new mobile banking app. Three proposals have passed technical review, all are within budget, and each contains the same sentence: “We are fully DORA compliant.” The procurement committee picks the cheapest. Six weeks later, during contract negotiation, the compliance team sends over an addendum with the Article 30 clauses. The winning vendor refuses unrestricted audit rights, cannot say where its subcontractor stores backups, and is hearing about threat-led penetration testing for the first time. The project stalls, and the proposal that won on price turns out to be the most expensive, because it costs a quarter.
None of this requires bad faith on either side. All it takes is for regulation to enter the vendor selection process at the end, as a contract addendum, rather than at the start, as a scoring criterion. This article is for CTOs, CIOs and compliance leads at banks, payment and e-money institutions, insurers, investment firms and fintechs that buy financial software development services from outside.
The thesis is this: when you choose a financial software vendor, “we are DORA compliant” means nothing, because DORA binds the financial entity, not the software company. What matters is whether the vendor’s contract, its subcontracting chain and its way of delivering can be entered in your register of information, covered by the Article 30 clauses, and terminated without disrupting your business. For systems supporting critical functions, those criteria should weigh at least as much as technical capability when you score proposals, and more than price. Many buyers will disagree, because they are used to scoring teams and day rates. We will try to show why that habit no longer pays.
We are not covering acceptance testing or the broader digital transformation of financial services here; we wrote about open banking, regulation and technology for FSI leaders separately. This piece is about one thing: how regulation changes the way you select a software development vendor.
Why is a “DORA-compliant vendor” a promise without substance?
Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, known as DORA, has applied since 17 January 2025. It is addressed to the financial entities listed in Article 2: credit institutions, payment and e-money institutions, investment firms, insurers, crypto-asset service providers and around a dozen more categories. Software vendors are not on that list. Article 28(1) makes the consequence explicit: a financial entity that uses ICT third-party service providers remains fully responsible for complying with all its obligations under the regulation and sectoral financial services law.
There is one exception. Providers designated as critical ICT third-party providers (CTPPs) fall under direct oversight by the European Supervisory Authorities. On 18 November 2025 the EBA, EIOPA and ESMA published the first list of 19 such providers, including the European arms of Amazon Web Services, Google Cloud, Microsoft, IBM, Bloomberg and London Stock Exchange Group. A Lead Overseer can impose on a CTPP periodic penalty payments of up to 1% of its average daily worldwide turnover, charged daily for up to six months (Article 35(8)). A software house delivering a project for a single bank is not, and will not become, a CTPP.
So what does “we are DORA compliant” mean in an ordinary vendor’s proposal? At best, shorthand for “we have processes that will help you meet your obligations”. At worst, a marketing line with nothing verifiable behind it. Neither is a scoring criterion. The criterion is whether the vendor will accept specific clauses, provide specific data and take part in specific processes. That can be verified before selection rather than after it.
The second consequence is less obvious. Because accountability stays with the financial entity, the entity must be able to carry it on the basis of evidence from the vendor. An ISO/IEC 27001 certificate or a SOC 2 report is only partial evidence: it describes the vendor’s security management system, not whether the contract lets you audit, exit in an orderly way, or hear about an incident in time to report it to your supervisor. Article 28(5) requires providers to apply appropriate information security standards, but a certificate is the entry ticket to the conversation, not its outcome.
When does a software development company become an ICT third-party provider?
This is the question we hear most, because the answer determines whether the contract goes into the register of information and whether Articles 28–30 apply at all. Article 3(21) of DORA defines ICT services as digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis. The last three words carry the weight.
The typology financial entities use in their registers is set out in Annex III of Commission Implementing Regulation (EU) 2024/2956. It lists nineteen categories. For software development companies, the relevant ones are mainly:
- S02 “ICT development”: business analysis, software design and development, testing,
- S01 “ICT project management”: project management office support,
- S14 “ICT operation management (including maintenance)”: configuration, maintenance, installation, capacity and continuity management, explicitly including managed service providers,
- S15 “ICT consulting”: expert advisory services,
- S19 “Cloud services: SaaS”, where the vendor offers its own product as a service.
The boundary is the ongoing-basis condition. In answer DORA 215-3300, the ESAs said that a reseller supplying only licences, without ongoing ICT services, does not qualify as an ICT third-party service provider. An earlier question (DORA130-3174), in which the industry asked for confirmation that one-off supplies fall outside Articles 28–30, was rejected with a pointer back to that same condition in the definition. The lesson from both answers is that scope follows the ongoing nature of the service, not the title of the contract.
The practical conclusion for buyers: a build engagement combined with maintenance, support, a warranty delivered by the vendor’s team, a standing development team or hosting is an ICT service. In theory you could structure the purchase as a one-off delivery of code with no ongoing services, and thereby keep it out of the register. We advise against it for two reasons. First, software supporting financial activity almost always needs maintenance, and if the vendor does not provide it, someone else does, and that someone goes into the register instead. Second, supervisors look at the substance of a relationship, not its label. An arrangement that formally avoids the register while relying in practice on one vendor’s ongoing services is regulatory risk, not savings.
Staff augmentation, where a vendor provides specialists who work inside your team, is a separate case. Classification depends on whether the vendor provides a service (taking responsibility for an outcome or for team continuity) or simply makes people available under your full direction. The safer assumption is to record such contracts as S02 or S15 and apply the Article 30(2) clauses, because the vendor’s specialists usually work in systems supporting financial activity and have ongoing access to them. Agree that assessment with your compliance team before the request for proposal goes out, not after signing.
What changes when software supports a critical or important function?
DORA does not treat all ICT services the same way. The key dividing line runs between services that support critical or important functions and everything else. A critical or important function is, broadly, one whose disruption would materially impair the entity’s financial performance, the continuity of its business, or its compliance with the conditions of its authorisation and with financial law (Article 3(22)). The scope of contract clauses, the requirement for an exit strategy, notification of planned contracts to the supervisor and the intensity of monitoring all follow from this classification.
This is the first practical lesson for vendor selection: the requirements are set by the function the software supports, not by the size of the vendor or the value of the contract. A small team building a transaction authorisation module supports a critical function. A large firm building an intranet portal for staff announcements does not. Commission Delegated Regulation (EU) 2024/1773 requires the entity’s policy on ICT services supporting critical or important functions to include a methodology for determining which services support them, and to specify when that assessment is carried out and reviewed.
That assessment belongs before the request for proposal, not after vendor selection. Article 28(4) requires the financial entity, before entering a contract, to assess whether it covers ICT services supporting a critical or important function, check supervisory conditions for contracting, identify and assess relevant risks including ICT concentration risk, carry out due diligence on the prospective provider and identify conflicts of interest. If the classification happens after selection, you discover that proposals were scored against criteria that did not match the real requirements.
Classification has a consequence buyers often forget. Where a service supports a critical or important function, the entity must inform its competent authority in good time about planned contractual arrangements (Article 28(3)). A vendor selection timeline that leaves no room for that step is not a realistic timeline.
Concentration risk (Article 29) also matters. If the vendor you are considering already supports other critical functions in your organisation, or relies on the same cloud provider as the rest of your estate, the new contract may deepen dependence on a single provider in a way your supervisor will question. That is not a reason to reject the vendor, but it is a reason to document the assessment before you decide. For an outside view of how to assess risk systematically, see our glossary.
What does Article 30 require in every ICT services contract?
Article 30(1) requires the rights and obligations of both parties to be clearly allocated and set out in writing, with the full contract, including service level agreements, in a single written document available to both parties. That alone can be a problem: framework agreements, statements of work, technical schedules and SLAs scattered across a dozen files with different dates do not meet the requirement without consolidation.
Article 30(2) lists what every ICT services contract must contain, whether or not it supports a critical function:
- a full description of the services, stating whether subcontracting of services supporting critical or important functions is permitted and on what conditions,
- the regions or countries where services are provided and data is processed and stored, with a duty to give advance notice of any planned change,
- provisions on the availability, authenticity, integrity and confidentiality of data, including personal data,
- access to, recovery and return of data in an easily accessible format in the event of the provider’s insolvency, resolution, discontinuation of business or termination of the contract,
- service level descriptions, including updates and revisions,
- an obligation to assist with ICT incidents related to the service, at no extra cost or at a cost determined in advance,
- full cooperation with competent and resolution authorities,
- termination rights and minimum notice periods,
- conditions for the provider’s participation in the entity’s ICT security awareness and digital operational resilience training.
For a software vendor, several of these points need concrete answers, not statements of intent. Point two means the vendor must know every location where client data may end up: code repositories containing test data, issue trackers, test environments, developers’ laptops, backups. Point four means code, documentation and data must be transferable in a format usable without the vendor. Point six fixes in advance what incident assistance costs, so nobody negotiates rates in the middle of an outage.
Article 30(4) encourages the parties to consider standard contractual clauses developed by public authorities for specific services. That is good news for buyers: you do not have to draft these provisions from scratch, and a vendor familiar with such templates will move through negotiation faster.
Which clauses are added when software supports a critical function?
Article 30(3) adds six groups of provisions for services supporting critical or important functions. These are the ones that most often stall negotiations, because they require the vendor to change how it operates, not just to sign.
Full service level descriptions with precise quantitative and qualitative performance targets, so the service can be monitored and corrective action taken when targets are missed. For a development team this means more than response time to a ticket: it also covers time to fix critical defects, environment availability and deadlines for security patches.
Notice periods and reporting obligations for the provider, including notification of any development that might materially affect its ability to deliver. A change of ownership, loss of key people, a new subcontractor, financial difficulty.
Implemented and tested business continuity plans and ICT security measures appropriate to the entity’s regulatory framework. The vendor has to show the plan, not just say it has one, and be able to demonstrate that it has been tested.
Participation in threat-led penetration testing (TLPT) under Articles 26 and 27. Entities identified by their supervisors run these tests at least every three years, and if the scope includes systems built or maintained by the vendor, the vendor must take part.
Ongoing monitoring rights: unrestricted rights of access, inspection and audit for the financial entity, a third party it appoints and the competent authority; the right to take copies of relevant documents on site; agreed alternative assurance levels where an audit could affect the rights of the vendor’s other clients; and a duty to cooperate during inspections.
Exit strategies, in particular a mandatory adequate transition period during which the provider continues to deliver services, so the entity can migrate to another provider or bring the service in-house.
Two provisions usually draw the most resistance: unrestricted audit rights and the transition period on exit, because both cost the vendor real effort and limit its freedom. A vendor that accepts them without discussion probably has not read the contract. A vendor that refuses them outright is not fit for critical systems. The best signal is a vendor that arrives with a concrete proposal: how to run an audit without breaching other clients’ confidentiality, and what its standard handover plan looks like.
How does the register of information change vendor selection?
Article 28(3) requires financial entities to maintain a register of information on all contractual arrangements for ICT services provided by third parties, distinguishing those that support critical or important functions. The templates are set out in Implementing Regulation (EU) 2024/2956. The register is reported to the supervisor at least annually. National authorities set the first submission deadlines in spring 2025; Poland’s KNF, for example, required its first registers by 23 April 2025, with data as at 31 March 2025.
The register is not paperwork for its own sake. The ESAs used register data to assess which providers matter systemically and, on that basis, designated the first CTPPs. In other words, the register is the dataset supervisors use to map the sector’s dependencies.
For vendor selection, the register has three practical effects.
First, the vendor must supply the data that goes into the register: identification data (including a Legal Entity Identifier where it has one), locations of service provision and data processing, the type of service under the Annex III typology and, for services supporting critical functions, information on subcontractors in the supply chain. A vendor that cannot supply this data at proposal stage will not supply it later either.
Second, the register forces you to think about the supply chain at the point of purchase. If the winning vendor uses a subcontractor, which in turn runs on a cloud provider, each of them may appear in the supply-chain templates. The ESAs’ answer to DORA 215-3300 shows the logic: where you have no direct contract with the effective provider, you record the contract with the intermediary and add available information on the effective provider as a subcontractor.
Third, every change of vendor or subcontractor is a change to the register. A vendor that rotates subcontractors between projects creates work for your compliance team. That cost belongs in proposal scoring, even though it does not show up in the day rate.
A simple test at the request-for-proposal stage: ask vendors to fill in a simplified version of the register templates for the proposed service. It takes an hour for a vendor whose contracts are in order and a week for one whose contracts are not. The difference in response time will tell you more than any statement in the proposal.
Where do PSD2, the EBA guidelines and national outsourcing rules fit in?
DORA does not operate in isolation. A buyer of financial software development services needs to keep at least three other layers in view, all of which overlap with vendor selection.
PSD2. The Payment Services Directive (EU) 2015/2366 touches vendor selection in two places. The first is outsourcing: Article 19(6) requires a payment institution that intends to outsource operational functions of payment services to inform its home competent authority, and outsourcing important operational functions must not materially impair the quality of internal control or the supervisor’s ability to monitor compliance. The second is product requirements: strong customer authentication and interfaces for third-party providers under Delegated Regulation (EU) 2018/389. A payments software vendor must know these requirements from delivery experience, not from slides. One change has simplified things: Directive (EU) 2022/2556, which accompanies DORA, means entities within DORA’s scope report payment-related operational and security incidents under a single harmonised DORA regime.
PSD3 and the Payment Services Regulation (PSR) are on the horizon. The European Parliament and the Council reached a provisional political agreement on 27 November 2025, and the Committee of Permanent Representatives endorsed the compromise texts in April 2026. According to law-firm analyses, most PSR provisions are expected to apply around 21 months after publication. For vendor selection today, that means one thing: if you are building a payments system that will still be running in 2028, ask the vendor how it plans to adapt to the PSR, particularly in fraud prevention and open banking.
EBA guidelines on outsourcing. The EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02), applicable since 30 September 2019, were for years the main reference for outsourcing contracts at banks and payment institutions. Since DORA, ICT services are governed by the regulation, and from 8 July to 8 October 2025 the EBA consulted on new guidelines on the management of third-party risk for non-ICT services, intended to replace the 2019 guidelines. The takeaway for a software vendor is that its service will be assessed under DORA, but if it also includes elements that are not ICT services, such as running a business process, part of the relationship may fall under the EBA guidelines.
National rules and non-EU regimes. Member states keep their own outsourcing provisions in banking law, and supervisors publish their own expectations. In Poland, for example, Articles 6a–6d of the Banking Law govern a bank’s outsourcing of activities to other businesses, and the supervisor announced in December 2024 that it would withdraw its 2020 cloud communication because its subject matter overlaps with DORA. If your group also operates in the United States, the June 2023 Interagency Guidance on Third-Party Relationships issued by the Federal Reserve, FDIC and OCC sets out a lifecycle approach to third-party risk with heightened oversight for relationships supporting critical activities. The vocabulary differs, but the logic of classification, due diligence, contract terms, monitoring and termination is close to DORA’s.
The conclusion of this section is simple: a request for proposal for financial software should be written jointly by IT, compliance and legal, because none of them sees every layer alone. For a wider view of regulatory compliance in IT, see our glossary, and for a broader look at what compliance means for software teams, our guide to software compliance for IT leaders.
How do you check the vendor’s subcontractors and supply chain?
Subcontracting is where the rules have moved most in recent months. Commission Delegated Regulation (EU) 2025/532, specifying the elements a financial entity must determine and assess when subcontracting ICT services supporting critical or important functions, was published in the Official Journal on 2 July 2025 and entered into force on 22 July 2025. Its history is instructive: in January 2025 the Commission rejected the ESAs’ first draft, and the final version dropped the contested provision on monitoring the entire subcontracting chain.
From that regulation and Article 30(2)(a) follow several questions to ask before signing.
Who will actually write the code? Many software vendors staff part of a team with subcontractors, freelancers or employees of partner firms. For a critical function you need to know whether the vendor uses subcontractors, to what extent and on what terms, and you need the right to object to a change of material subcontractor.
What does the project infrastructure run on? Code repositories, CI/CD, test environments, task management tools. Each is a service the vendor uses, and each may hold client data. Their locations go into the contract under Article 30(2)(b).
Do your contract terms flow down the chain? Audit rights, incident notification duties and data protection rules are worth little if they stop at the first link. The contract should require the vendor to pass material obligations on to its subcontractors.
What happens if a subcontractor disappears? The vendor should have a plan for replacing a key subcontractor and, for teams, for replacing key people. That is business continuity, which DORA treats as an obligation rather than good practice.
One more point: if a vendor claims not to use any subcontractors, ask about the tools its team works with. Almost every team relies on cloud services, and those are part of the ICT supply chain even if nobody thinks of them as subcontractors.
What must a vendor be able to do when a major incident happens?
DORA introduced harmonised deadlines for reporting major ICT-related incidents. Under Delegated Regulation (EU) 2025/301, the initial notification must reach the supervisor within four hours of classifying the incident as major, and no later than 24 hours after the entity became aware of it. The intermediate report is due within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report.
Those deadlines run on the financial entity’s side, but meeting them depends on the vendor. If an incident starts in a system the vendor builds or maintains, the vendor will often know first. If the contract only requires notification “without undue delay”, in practice that can mean the next business day, by which time your four hours to classify and report are long gone.
When choosing a vendor, check four things.
Notification time in the contract. A specific number of hours from detection, with a contact channel available outside business hours. For critical systems this is measured in hours, not days.
Content of the notification. The information you need to classify the incident under the criteria in Delegated Regulation (EU) 2024/1772: number of affected clients, duration, data affected, geographical spread. A vendor that only says “we have an outage” will not help you classify anything.
Incident assistance and its cost. Article 30(2)(f) requires incident assistance at no extra cost or at a cost determined in advance. Agree the rate before signing.
Readiness for testing. If your institution runs TLPT and the scope includes the vendor’s system, the vendor must take part. Ask whether it has done so before and what its role was.
A useful exercise before selection is a joint incident simulation: two hours, a scenario of client data leaking from the vendor’s test environment, and an observation of who speaks up, when, and with what information. It tells you more about a vendor than ten pages of process descriptions.
How do you design the exit strategy before signing the contract?
Article 28(8) requires financial entities to have exit strategies for ICT services supporting critical or important functions, covering provider failure, deterioration of service quality, business disruption and termination. Exit must be possible without disrupting business activities, without limiting compliance with regulatory requirements and without harming the continuity and quality of services to clients. Exit plans must be comprehensive, documented, sufficiently tested and periodically reviewed.
Article 28(7) lists the situations in which the contract must be terminable: a significant breach of law or contract terms, circumstances identified through monitoring that could alter the performance of the service, evidenced weaknesses in the provider’s ICT risk management, and situations where the supervisor can no longer effectively supervise the entity because of the arrangement.
For custom software, an exit strategy has three layers, and each has to be written into the contract before vendor selection, not after it.
Rights. Who owns the code, documentation, test data, infrastructure scripts and configuration? If the vendor keeps rights to components it brings into the project, on what terms can you use them after the contract ends? This connects to the problem we described in our piece on avoiding vendor lock-in: dependence on a vendor arises more often from how the contract is built than from the technology.
Knowledge. Code without architecture documentation, design decisions and deployment procedures can be taken over, but at high cost. The contract should define which documentation is maintained throughout the engagement, not produced only at exit, when the vendor has no incentive left.
Time. Article 30(3)(f) requires a transition period during which the provider continues to deliver services. Its length depends on system complexity. The notice period in the contract should be consistent with the realistic time it would take another vendor or an internal team to take the system over.
How do you check whether the exit strategy is workable? The best test is an independent review of the code and documentation by a third party during the engagement, not at exit. If an outside team cannot understand the system in reasonable time, the exit plan exists only on paper. We describe what such a review covers in our technical due diligence checklist.
How should you set proposal scoring so regulation carries the weight it should?
Back to the thesis. In a typical software development RFP, the scoring criteria look roughly like this: technical capability and team experience, methodology, price, sometimes references. Regulatory requirements appear as a formal condition (“the bidder declares that it meets DORA requirements”) or as a contract addendum after selection. That structure rewards vendors who declare compliance and penalises those who honestly price the cost of meeting the requirements.
We propose a different structure for systems supporting critical or important functions. The weights are our recommendation, derived from the logic of risk, not a regulatory requirement. Every organisation should adjust them to the policy it maintains under Regulation 2024/1773.
| Criterion | Weight (critical function) | Weight (non-critical function) | How to verify before selection |
|---|---|---|---|
| Technical and domain capability of the team | 35% | 45% | Technical interviews, a sample task, delivery experience with PSD2/SCA and payment systems |
| Acceptance of Article 30(2) and 30(3) clauses | 15% | 10% | Vendor comments on the draft contract attached to the RFP |
| Subcontracting chain and data locations | 10% | 5% | Completed simplified register templates, list of subcontractors and cloud services |
| Incident and testing readiness | 10% | 5% | Notification time in the contract, incident simulation, TLPT experience |
| Exit feasibility | 10% | 5% | Handover plan, documentation standard, rights to code and components |
| Price and commercial model | 20% | 30% | Total cost including compliance effort and register changes |
Here, regulatory criteria together weigh 45% for a critical function: more than technical capability and more than twice as much as price. For a non-critical function they drop to 25%, but they do not disappear, because Article 30(2) applies to every ICT services contract.
The most important change, though, is not the weights but the timing. The draft contract with the Article 30 clauses should be part of the RFP. Vendors comment on it in their proposals, and those comments are scored. The price in the proposal then includes the cost of meeting the requirements, rather than being a price that will rise after negotiation. For a structured way to compare vendors, see our IT outsourcing vendor evaluation scorecard.
A competent reader might object: a strong engineering team is the best protection against incidents, and a contract builds nothing. That is true of code quality. But DORA does not ask whether the system is good; it asks whether the institution controls the risk associated with the vendor and can demonstrate that to its supervisor. A vendor with the best team that will not accept audit rights is, for a critical function, a vendor you are not allowed to sign with. No amount of capability points can make up for that.
What mistakes do financial institutions make when choosing a software vendor?
Most typical mistakes do not come from a lack of knowledge about DORA but from the order in which things happen. The patterns below follow directly from how the rules are built: each appears when regulatory requirements enter the process too late or replace substantive assessment.
Classifying the function after choosing the vendor. The project team picks a vendor, and compliance only then assesses whether the service supports a critical function. If it does, it turns out that proposals were scored without the criteria that should have decided the outcome.
Treating the DORA addendum as a formality. The Article 30 clauses go into an addendum the vendor signs unchanged, because it has already won. A year later, at the first audit, it turns out the vendor cannot deliver what it signed, because it changed none of its processes.
Equating a certificate with compliance. ISO/IEC 27001 is a valuable signal of vendor maturity, but it does not replace contract clauses, audit rights or an exit plan. The certificate covers the vendor’s management system; DORA covers your relationship with the vendor.
Overlooking augmented staff. Specialists provided under staff augmentation work in your systems, often with broad access, yet the contract with their vendor is sometimes treated as a staffing agreement rather than an ICT services contract. That is a gap supervisors will spot easily in the register.
Underestimating register churn. Every change of subcontractor, data location or service scope is a register update. A vendor with an unstable supply chain creates a standing administrative cost that the day rate does not show.
Ignoring domain capability. The opposite mistake: so much focus on the contract that a vendor with no financial systems experience wins because it accepted every clause. A vendor that does not know what strong customer authentication involves will build a system that meets the contract and fails the product requirements. That is why technical capability remains the largest single criterion in our table.
How to avoid these mistakes: a sequence before the RFP
If you have a financial software vendor selection ahead of you, here is a sequence you can run in a few weeks before sending the RFP.
Week one: classification. Determine, using the methodology in your policy, whether the software will support a critical or important function. Record the reasoning. Check whether the new contract increases concentration risk.
Week two: regulatory layers. With legal, establish whether the contract will also be outsourcing under national banking law or PSD2, whether it needs supervisory notification, and whether it includes non-ICT elements.
Week three: draft contract. Prepare a draft with the Article 30(2) clauses and, for a critical function, the Article 30(3) clauses. Fix concrete numbers: incident notification time, transition period length, audit scope.
Week four: the RFP. Attach the draft contract, the simplified register templates to complete and the weighted scoring criteria. Build time for supervisory notification into the schedule if the function is critical.
After selection: verify during the engagement. Schedule the first vendor audit, the first business continuity test and the first independent review of code and documentation to check exit feasibility. Article 28(6) requires the frequency and areas of audits to be set in advance on a risk basis.
This sequence adds a few weeks to RFP preparation. In exchange it shortens negotiation, eliminates vendors who cannot meet the requirements before you invest time in them, and makes the price in the proposal the final price.
What are the key takeaways before choosing a financial software development vendor?
DORA has not changed what a good financial system needs: a capable team that understands the domain. It has changed what you must check before choosing that team, and when you must check it. Compliance with the regulation is the financial entity’s obligation, not a vendor attribute, so “we are DORA compliant” is not an argument when you score proposals.
Remember six things. First, classify the function the software supports before writing the RFP, because it sets the scope of requirements. Second, treat a development engagement combined with maintenance or a standing team as an ICT service that goes into the register. Third, attach a draft contract with the Article 30 clauses to the RFP and score vendors’ comments on it. Fourth, ask for register data and a subcontractor list at proposal stage. Fifth, write a specific incident notification time into the contract, consistent with the deadlines in Regulation 2025/301. Sixth, design the exit before signing and test its feasibility during the engagement.
If you are preparing a vendor selection for a financial system and want to discuss how a delivery partner can fit your requirements, see how we work in custom software development and in fintech IT staffing, or book a call. We are happy to comment on your draft contract before the RFP goes out.