If you sell software to an EU bank, DORA already applies to you. It has since Jan. 17, 2025. The Digital Operational Resilience Act names your company as an ICT third-party service provider, and the vendor register your European customer is building names you inside it. For US fintechs and US SaaS providers, that register stopped being an EU compliance artifact months ago. It is a renewal gate.
By Lihi Lutan, Co-Founder and CEO, Opstream
Co-Founder and CEO of Opstream, previously COO of StokeTalent (acq. Fiverr) and VP Operations at Taboola where she helped scale the company from $8M to $1B in revenue.
In this article
- What is an ICT Vendor Register under DORA?
- Why does DORA reach US companies that never signed up for EU regulation?
- Which types of US companies does DORA already affect?
- What does a DORA ICT Vendor Register actually contain?
- Why do spreadsheets and TPRM tools fail at DORA compliance?
- How do you make the register a byproduct of intake?
- Frequently asked questions
What is an ICT Vendor Register under DORA?
The ICT Vendor Register, formally the Register of Information, is a structured database of every information and communication technology provider a financial entity contracts with. Article 28 of DORA requires regulated entities to keep this register at three levels: per legal entity, sub-consolidated, and consolidated at group. National regulators can ask for it at any time, and the European Supervisory Authorities have drafted implementing technical standards that prescribe its exact fields, currently being finalized after a revision cycle with the European Commission.
Definition
ICT Vendor Register (Register of Information): a DORA-mandated record of every ICT third-party service provider a financial entity uses. Captures legal identity, the service supplied, its criticality to the entity, contract dates, data locations, the full subcontractor chain, incident reporting obligations, and audit and exit rights.
Your EU customers are the ones formally on the hook. But the data in the register is data about you, and they cannot produce it without your cooperation. The bank or insurer does not wait politely for you to volunteer it. They send a questionnaire, a due diligence packet, or a contract amendment, and the answer determines whether the relationship renews.
Why does DORA reach US companies that never signed up for EU regulation?
DORA has extraterritorial reach by design. The regulation applies to 20 categories of financial entity in the EU and to any ICT third-party provider whose services they depend on, regardless of where the provider is headquartered. A California SaaS company selling to a Frankfurt bank is an ICT provider under DORA. So is a New York data analytics platform used by a Dutch insurer. So is a cloud security vendor whose monitoring supports a Paris payment processor.
The EU financial entity carries the compliance burden, but it solves that burden by pushing requirements onto its vendors. If the vendor cannot produce the evidence, the bank is required to find a vendor that can, or accept regulatory risk. (For a deeper look at what that assessment involves, see our vendor risk assessment checklist.) The European Union Agency for Cybersecurity (ENISA) has consistently framed third-party dependency as the weakest link in operational resilience, and DORA codifies that view into contract law.
1%
Max daily periodic penalty for critical ICT providers, as share of worldwide daily turnover
Source: DORA Article 35, EUR-Lex
Jan 2025
DORA enforceable date. Not a future deadline.
That 2% cap is the number the EU bank’s board is looking at. It is also why the bank’s procurement and compliance teams are moving faster than vendors expect. According to Deloitte’s DORA readiness analysis, the most common 2025 enforcement pattern was contract-level: financial entities asking vendors to attest or amend, and treating non-response as a reason to narrow the vendor list.
Which types of US companies does DORA already affect?
Not every US company has the same obligation. The law splits cleanly into two buckets, and which bucket you fall into determines what you need to produce and for whom.
- 1US fintechs and financial services with EU exposureDirect obligation. If you have EU customers, EU employees, or an EU-licensed subsidiary, you carry DORA’s full five-pillar framework yourself. That includes your own ICT Vendor Register for every tool in your stack.
- 2US SaaS and ICT providers selling to EU financial entitiesIndirect obligation, enforced through customer contracts. Your EU bank or insurer customers are embedding DORA clauses in MSAs at renewal: incident reporting commitments, audit rights, data-location disclosure, subcontractor transparency, exit assistance. You must be able to answer them in writing.
The trigger question is simple. Do you have EU banks, insurers, or payment platforms as customers? If yes, DORA is already in your renewal cycle, whether or not anyone on your team has opened the regulation.
What does a DORA ICT Vendor Register actually contain?
The ITS specifies the register’s fields to a level of granularity most US companies are not currently set up to answer. At minimum, for every ICT provider in your stack, the register must contain the following.
- Legal identity of the provider, including the Legal Entity Identifier where available and country of incorporation
- Description of the service provided, including whether it supports a critical or important function
- Contract start date, renewal date, and termination terms
- Data location and access controls, including any processing performed outside the EU
- Full subcontractor chain, with disclosure of material subcontractors
- Incident reporting commitments, including timelines aligned with DORA’s four-hour initial and 72-hour intermediate reporting windows
- Audit and exit rights, including the right of the financial entity and regulator to audit the provider
- Business continuity and disaster recovery commitments
That level of structured detail is not something a shared drive can carry. It has to live in a system that captures the data at the moment of vendor onboarding, updates it when contracts change, and surfaces it on request.
Why do spreadsheets and TPRM tools fail at DORA compliance?
Most US mid-market companies encountering DORA for the first time reach for one of two answers: a spreadsheet, or a dedicated third-party risk platform. Neither is built for the job. Here is how the common approaches compare for a US fintech or SaaS provider with 200 to 2,000 employees and an EU customer base.
| Approach | What it gives you | Where it breaks for DORA |
|---|---|---|
| Shared spreadsheet register | Cheap, quick to start, easy to share | Goes stale within weeks. No audit trail. No link to the contract or the intake decision. When your EU customer asks for evidence, you are assembling a new document from memory. |
| Dedicated TPRM platform | Risk scoring, attestation workflows, security questionnaires | Owned by security, not procurement. Sits outside the buying process. The register becomes a parallel system someone has to maintain in addition to how new vendors actually enter the company. |
| Enterprise EU GRC platform | Comprehensive regulatory coverage | Enterprise price point and a 6 to 12 month implementation. The wrong cost and the wrong timeline for a 500-person fintech answering its first DORA amendment. |
| External counsel or consultant | A point-in-time document | The register is a living record, not a PDF. The answer is stale the moment a new vendor is signed or a contract is renewed. |
| AI-native procurement platform | The register is generated automatically from the intake data every new vendor already provides | Requires treating vendor intake as the single entry point for every ICT relationship, which is a discipline many US mid-market companies have not formalized yet. |
Each of the first four approaches treats the register as a separate artifact someone has to build and maintain. That is the mistake. The register is not a document you produce once a year. It is the by-product of a well-structured intake process running every day.
How do you make the register a byproduct of intake?
A vendor register is just a view into the data you collect when a vendor enters your company. The reason it feels like a separate project is that most companies collect that data inconsistently, across Slack threads, ticket queues, and ad-hoc forms. When DORA asks for a clean view of every ICT provider, there is no clean view to pull from.
The fix is operational, not legal. Fix the intake and the register writes itself.
- 1One intake door.Every new vendor, new tool, and contract renewal enters through the same structured form. No side channels. No exceptions for “small” purchases, because DORA does not have a materiality threshold for critical-function ICT.
- 2DORA-aligned fields at intake.Service description, criticality rating, data location, subcontractor disclosure, incident reporting commitment, audit rights. If you capture them at onboarding, you never have to chase them later.
- 3Conditional routing for critical vendors.Providers supporting critical or important functions get enhanced review, additional questionnaires, and senior approver sign-off. Non-critical vendors move through a lighter path. Both are logged.
- 4Contracts attached at the record.Every executed MSA, DPA, or amendment lives at the vendor record alongside the intake data. Clause-level DORA compliance is verifiable without a contract search.
- 5Renewal triggers a re-review.Annual review is not a calendar exercise. It is automatic when a contract approaches its renewal date, and it uses the same intake schema, keeping the register current by definition.
- 6Register generated on demand.When an EU customer or a regulator asks, you export the view. The data is already there, already structured, already timestamped.
That is how Opstream customers handle DORA’s third-party pillar. Intake captures the fields. Workflows enforce the governance. The ICT Vendor Register is a report, not a project. (For a broader look at how intake-to-pay works end to end, see our complete procurement checklist.)
Key takeaways
● DORA has been enforceable since Jan. 17, 2025. It reaches US companies extraterritorially through the contracts their EU customers hold.
● The ICT Vendor Register is the most visible third-party pillar requirement and the one US companies are being asked about most at renewal.
● Spreadsheets, TPRM tools, and enterprise GRC platforms each fail for different reasons at the US mid-market scale.
● The right operational answer is to make the register fall out of a single, structured vendor intake process, not to run it as a separate compliance project.
● Critical ICT providers face periodic penalties of up to 1% of daily worldwide turnover under Article 35, while financial entity penalties are set by national law. But the real economic risk for US companies is losing EU customers at renewal.
Frequently asked questions
Does DORA apply to a US company with no EU office?
Yes, if that US company provides information and communication technology services to an EU financial entity covered by DORA. The obligation reaches the US company through the EU customer’s contract. No EU subsidiary or establishment is required for the requirements to flow through.
What is the difference between DORA and GDPR for vendor management?
GDPR is a data protection regulation that governs how personal data is processed. DORA is an operational resilience regulation that governs how financial entities manage technology dependency and disruption. The two overlap on data location and subcontractor disclosure, but DORA goes further on incident reporting timeframes, concentration risk, audit rights, and exit planning. A DORA-ready vendor record contains GDPR data, plus resilience, continuity, and criticality data GDPR does not require. For more on EU regulation touching vendor stacks, see our guide on the EU AI Act and vendor compliance.
When can an EU bank customer terminate a US vendor for DORA non-compliance?
Under DORA-compliant contracts drafted to Article 30 standards, the financial entity typically retains the right to terminate if the provider materially breaches DORA obligations, or if regulatory supervision cannot be ensured. In practice, termination is rare. The more common path is non-renewal: the bank lets the contract lapse and selects a compliant vendor at renewal. That is why renewal cycles are the real pressure point for US providers.
Do we need a dedicated TPRM tool to comply with DORA’s third-party pillar?
No. TPRM platforms solve risk scoring and attestation, but not the register itself. What DORA’s third-party pillar requires is a structured record of every ICT provider, produced and kept current as vendors are onboarded and renewed. That is a procurement workflow problem, and it is solvable with a procurement intake system that captures the right fields at the point of onboarding. For guidance on what to look for in that system, see what to prioritize when buying procurement software.
How should a 500-person US fintech approach DORA without a dedicated legal team?
Start with intake. Standardize one form every new vendor and renewal passes through. Capture the DORA-aligned fields at that step, even if you are not sure which vendors are in-scope yet. Once the data exists in one place, the register, the due diligence record, and the contract clause evidence are all views into the same underlying data. Legal review becomes exception-based, not a bottleneck on every request.
DORA-Ready Intake
See what DORA-ready vendor onboarding looks like
One intake, DORA-aligned fields, automatic renewal review, and the register produced on demand.
About the author
Lihi Lutan
Co-Founder and CEO, Opstream
Lihi Lutan is the Co-Founder and CEO of Opstream, changing the way companies buy. Throughout her career, Lihi built and scaled business operations at startups and large corporations. Early in her career, Lihi was with Cyota (acq. RSA Security) as a team leader and project manager before moving to Thomson Reuters and Fundtech to manage global projects.
Later, Lihi joined Taboola (NSDQ: TBLA) as employee 15, as VP Professional Services and Operations, leading the department as the company scaled from $8M to $1B in revenue. Transitioning from Taboola to StokeTalent (acq. Fiverr), Lihi served as the company’s COO. Lihi holds an LLB of Law and BSc of Computer Science from Tel Aviv University.
