Getting ready for DORA when most of your stack is vendors

The EU's Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies from January 17, 2025, a little over three months from now. For a fintech whose infrastructure is mostly other companies' software, we expect the third-party work to take longer than everything else on the plan put together.

DORA covers ICT risk management, incident reporting, resilience testing, ICT third-party risk and information sharing. Within the third-party area sits the register of information on ICT third-party arrangements. A bank that runs its own data centers can treat most of that list as work on its own systems. A payments firm built on a cloud provider, a card processor, a KYC vendor, a core platform delivered as SaaS and two dozen smaller tools will find that nearly every item leads back to a contract with someone else.

Start with the register

The register sounds like paperwork, and it is. It is also, for a lot of firms, the first complete list of what the business actually depends on, which is why building it takes longer than anyone budgets for.

Build it from three sources and compare them. Accounts payable gives you every supplier you pay. The single sign-on catalogue gives you every application people log into. The architecture diagrams give you what engineering thinks is running. Each source misses what the others catch: accounts payable misses free tiers and anything bought on a company card, the sign-on list misses APIs nobody logs into, and the diagrams miss the tool the operations team adopted last spring without telling anyone.

Alongside whatever fields the register format requires, record the operational facts you would want during an incident or an exit:

• which of your services stop or degrade if this vendor is unavailable for a day
• who you call at the vendor during an incident, and whether anyone has ever tested that contact
• where your data sits, and in what format you could get it back
• which suppliers the vendor depends on in turn, at least for your largest arrangements
• when the contract renews, and how much notice a termination needs

That second line deserves attention. When most of your stack is vendors, most of your incidents start as somebody else's incident. Your own reporting clock starts when theirs does. If your processor's notification goes to a shared inbox that nobody reads on a Saturday, you are behind before anyone has opened it. Test the contact in both directions once a year, and put the vendor's incident path into your own incident runbooks so the on-call team is not looking for a phone number at 3am.

Concentration you did not choose

Once the register exists, sort it by what each vendor runs on. You may find that your processor, your KYC provider and your core platform all sit with the same cloud provider, sometimes in the same region. That is concentration nobody decided to take on, and a vendor-by-vendor review will never show it.

The outage in July was the same shape of problem: one software update, installed on a very large number of machines, affecting organizations that had no commercial relationship with each other. Resilience testing that assumes your vendors fail one at a time will miss that case entirely, so include at least one scenario where two of them go down together because of something they share.

You will not remove all of this concentration, and for many firms the sensible answer is to accept it and plan around it. Write the decision down with a note on what you would do if that provider had a bad week, then put a date on when you will look at it again.

Exit plans you could actually carry out

For most SaaS vendors an exit plan comes down to three questions. What would replace them? How long would the move take, in weeks of somebody's time? Can you get your data out in a form the replacement can load?

The third question is where plans fall apart. A vendor that offers "full data export" may mean a set of CSV files with internal identifiers, no schema and no history. Ask for a sample export this quarter and give it to an engineer for an afternoon. What comes back is the honest version of your exit plan, and it is often a surprise to the person who wrote the policy.

An export file that nobody has tried to load into another system tells you very little about whether you could leave.

Contract terms follow from the same work. Where the register shows a gap, such as no incident notification commitment, no right to hear about changes of subcontractor, no audit or access rights, or nothing about help during a transition out, that gap becomes the agenda for the next renewal conversation. Ask each vendor directly whether they have a DORA addendum ready and, if they don't, when they expect one. The answer tells you something about how many of their clients have asked.

If you are on the other side of it

Plenty of firms reading this sell services to EU-regulated clients from outside the EU, which is the position of many providers here in the UAE. DORA reaches you through your contracts. The obligations sit with the regulated financial entity, and they will pass down what they need in order to meet them.

Expect longer due diligence questionnaires, contract amendments covering incident notification and audit rights, questions about your own subcontractors, and requests to take part in your clients' resilience testing. The preparation is the same work in mirror image. Keep a current list of what you depend on. Write an incident notification procedure that can meet the tightest timeline you have agreed with any client, and check that the named people on the client side actually receive the test message.

There is one document most providers do not have and should: a short, honest description of what leaving you would involve, covering export formats, timelines and what your team would do to help. You will be asked for it. Writing it once, before the first client asks, is much easier than improvising it during a renewal.

Discuss your operations