Back to Blog Listing

DORA's Vendor Register Fails at the Corporate Card

DORA's Vendor Register Fails at the Corporate Card
Jakub Pietroszek Jul 25, 2026 4 min read

Written by: Jakub Pietroszek, Partnership Manager, Digital Colliers

DORA has been in force since 17 January 2025. If you work in a mid-market finance firm, your ICT third-party register is a live regulatory artefact now, not a slide in a readiness deck. And yet, if a supervisor asked you today for a complete list of every SaaS tool your teams rely on, most of you couldn't produce it inside a week. The gap isn't the tools you procured through vendor management. It's the ones your people bought on a corporate card at 11pm to finish a deck.

Why the register breaks at the expense line

The DORA register assumes a clean intake path. Vendor gets scoped, contract goes through legal, procurement books a PO, IT provisions SSO, security signs off. That path works for your core banking provider and your KYC vendor. It breaks for the £39 a month transcription tool that a relationship manager expensed last Tuesday.

The pattern I keep seeing:

  • A team lead needs a niche tool this week, not next quarter.
  • They put it on a personal or corporate card and expense it.
  • Finance codes it to "software" or "subscriptions" with a free-text vendor name.
  • Nobody tells IT, security, or the DPO.
  • The vendor now processes client data, and nobody outside that team knows it exists.

Multiply that by every team in the firm. That's your shadow SaaS estate. It's also the part of your ICT supply chain that DORA cares about, because operational risk doesn't check whether procurement approved the vendor.

The cost of leaving it alone

The temptation is to treat this as a housekeeping issue. It isn't. The cost of an incomplete register lands in three places.

First, supervisory. DORA gives national competent authorities the power to request your register and probe the gaps. An incomplete list isn't a filing error, it's evidence your third-party risk process doesn't reflect reality.

Second, incident response. When one of these unknown vendors has a breach, and given that only about 3-5% of publicly disclosed vulnerabilities get patched within 30 days you should assume some of yours will, you find out from a news alert rather than your own register. That's a bad day, made worse by the fact you can't tell the regulator which client data was in scope.

Third, adjacent regimes. Any shadow tool processing personal data is also a GDPR exposure, where fines reach up to €20M or 4% of global turnover. The same unknown vendor sits on two regulators' problem lists at once.

The data joins that make the register defensible

A register you can defend isn't a spreadsheet somebody updates quarterly. It's a view built by joining three systems you already have.

  1. The expense and card system. Every transaction with a software or SaaS MCC, plus recurring card charges under £100 a month that nobody thinks of as "a vendor". This is where shadow SaaS actually lives.
  2. The identity provider (SSO and directory). Every third-party app anyone has logged into with a work identity, including the ones that never went through IT. OAuth grants are especially revealing.
  3. The contract repository and DPA store. What you formally signed, with which entity, under which data processing terms, and when it renews.

Join those three and the picture gets uncomfortable fast. You'll find vendors in the expense feed with no contract. You'll find SSO grants to tools nobody expenses, because someone signed up with a work email on a free tier that quietly started processing data. You'll find contracts for tools nobody uses anymore, still auto-renewing.

The join key is usually the vendor domain, normalised. Names in expense feeds are messy ("NOTION LABS INC", "notion.so", "Notion*Sub"), but the domain resolves cleanly most of the time. The last mile is human review of the residuals.

What the operators getting this right are doing

The firms I see holding a defensible register in 2026 aren't running a bigger procurement team. They're running a monthly reconciliation between those three sources, with clear owners for the exceptions. New card charge to an unknown domain triggers a ticket. New SSO grant to an un-contracted vendor triggers a ticket. Contract with no matching usage triggers a renewal review.

The work isn't glamorous. It's a data pipeline, a small ruleset, and someone whose job it is to chase the exceptions. But it's the difference between a register that answers a regulator's question and one that raises new ones.

Related Posts