Does DORA Apply to US Companies?

Almost certainly not directly, and almost certainly yes in practice. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, binds the categories of EU financial entity listed in its Article 2, plus any ICT third-party service provider the European Supervisory Authorities designate as critical. A US software company is normally neither. What reaches you is Articles 28 to 30, which stop your European bank, insurer, or payment institution from using your service unless the contract carries specific terms, so DORA shows up as a procurement addendum rather than a regulator's letter. The company that treats that addendum as boilerplate and signs it unchanged has just promised unrestricted audit rights, subcontracting disclosure, and a documented exit plan it may have no way to deliver.

That distinction, regulated versus reached, decides everything else: what you have to build, what you can negotiate, and what you should refuse. The rest of this is the reasoning and the four questions the addendum is actually asking.

Key takeaways

• DORA binds the EU financial entities listed in Article 2, plus the ICT providers the European Supervisory Authorities designate as critical. A US software company is normally neither.
• It reaches you anyway through Articles 28 to 30, which govern what your customer is allowed to agree to. That makes it a procurement addendum rather than a regulator's letter.
• The phrase that changes your obligations is "critical or important function". That determination belongs to your customer, and it decides whether the baseline Article 30(2) terms apply or the heavier Article 30(3) set on top of them.
• Ask for the determination in writing at the start of the deal. In our experience it is often made by a procurement template rather than by the risk function, and it changes when someone asks.
• The Article 30(3) audit right is not negotiable in the way vendors hope, but its exercise is: notice, frequency, scope, pooled audits and reliance on independent assessments are all normal accommodations.

Who DORA actually regulates

DORA has applied since January 17, 2025 under Article 64. Article 2 lists the entities it binds, and the list is long rather than vague: credit institutions, payment institutions, account information service providers, electronic money institutions, investment firms, crypto-asset service providers and issuers of asset-referenced tokens, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, management companies, data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitisation repositories, and ICT third-party service providers.

Two things follow from reading the list rather than a summary of it. First, this is a financial-sector regulation with a wide definition of the sector, so a company that thinks of itself as a technology business but holds an e-money or payment institution authorization in an EU member state is squarely in scope in its own right. Second, the entity type is what matters, not where the customers are. A payment institution licensed in Ireland is in scope whether it serves Dublin or Denver.

Article 2(3) carves out a set of smaller and exempted entities, and Article 16 gives a genuinely simplified ICT risk management framework to categories including small and non-interconnected investment firms, certain exempted payment institutions and electronic money institutions, and small occupational retirement provision bodies. The simplified framework is not a pass. It still requires a documented ICT risk management framework, continuous monitoring, prompt incident response, identification of critical third-party dependencies, business continuity and backup restoration, periodic testing, and the feedback of lessons learned into staff training.

The designation route, and why it probably is not you

There is one way a technology provider comes under DORA directly: designation as a critical ICT third-party service provider, which places it under the direct oversight of a lead overseer rather than under indirect supervision through its financial customers.

The European Supervisory Authorities published the first list of designated critical providers on November 18, 2025, and the site's regulatory radar entry covers what changed. The designation criteria turn on systemic importance, the role the provider plays in supporting critical or important functions across financial entities, and how substitutable the service is. In practice the first cohort was hyperscale cloud and platform infrastructure.

If you are reading this to work out whether your Series B SaaS product is about to be designated, it is not. That is the honest answer, and it matters, because designation anxiety causes companies to over-build against obligations they will never carry while under-building against the contract terms they will sign next quarter.

How DORA reaches you anyway: Articles 28 to 30

Chapter V is where a non-EU vendor's real exposure sits. It does not regulate you. It regulates what your customer is allowed to agree to.

Article 28(3) requires every financial entity to maintain a register of information covering all contractual arrangements on the use of ICT services, at entity level and at consolidated level, distinguishing arrangements that support critical or important functions from those that do not. Entities report at least yearly to their competent authorities on the number of new arrangements, the categories of provider, the types of contract, and the services and functions involved, and an authority can ask for the full register at any time.

This is why you get questionnaires that look like an accounting exercise. Your customer is not being difficult. They owe a supervisor a structured record of what you do for them, where it is done, and who else touches it, and they cannot produce that record from a signed order form.

Article 30(2) then lists the contract terms every ICT arrangement must carry, whatever the service does: a clear and complete description of the functions and ICT services, the regions or countries where they are provided, provisions on availability, authenticity, integrity, and confidentiality of data, data access and return in an accessible format on insolvency or termination, service level descriptions, assistance at no additional cost during an ICT incident, cooperation with competent and resolution authorities, termination rights with notice periods, and participation in the entity's security awareness and resilience training.

The phrase that changes your obligations: critical or important function

Article 30(3) adds a second, heavier layer whenever the ICT services support what DORA calls a critical or important function. That layer is where deals stall:

• Full service level descriptions with precise quantitative and qualitative performance targets
• Notice obligations when developments could materially affect the provider's ability to deliver
• Business contingency plans and ICT security measures at a standard the entity's own framework can defend
• Participation in the entity's threat-led penetration testing
• Unrestricted rights of access, inspection, and audit
• Exit strategies with a transition period long enough to migrate

Whether your service supports a critical or important function is your customer's determination, not yours, and it is the single highest-leverage conversation available to you. A support-ticket tool used by a bank's retail operations team may or may not be inside the boundary. The same tool wired into an outage escalation path plainly is. Ask the question explicitly at the start of the deal, in writing, because the answer decides which of the two contract sets you are negotiating and how much evidence you need behind it.

The four questions a DORA addendum is really asking

Strip the legal drafting away and every addendum we have reviewed is asking the same four things. The clause-by-clause read works through each term; these are the questions underneath them.

Can we audit you, and can our regulator?

Article 30(3) says unrestricted rights of access, inspection, and audit. The right itself is not negotiable in the way vendors hope. Its exercise usually is: notice periods, pooled audits where several financial customers share one exercise, and use of independent third-party assessments are all normal accommodations.

Who else touches this service?

Subcontracting disclosure is not a courtesy. Your customer needs the chain for its register of information, and a subcontractor you disclose after signature is worse than one you disclose during diligence.

What happens when we leave?

An exit strategy under Article 28(8) means data out in a usable format, a transition period, and a documented plan the customer can execute without your goodwill. Most vendors discover here that their export tooling was built for support cases rather than for migration.

What happens when something breaks?

Article 30(2)(f) requires assistance at no additional cost when an ICT incident affects the contracted service. Your customer is working to a four-hour classification clock of their own, covered in DORA incident reporting, so read your incident-response commitments and your support tiering against that sentence before you sign it, not after.

When you are genuinely out of scope, and how to say so

Here is the part that costs us work. Plenty of vendors receive a DORA addendum they should push back on.

If your product is a marketing analytics tool, a design system, or a recruiting platform, and it touches no data and no process supporting a critical or important function, the correct response is not to sign the enhanced Article 30(3) set and start building an audit program you will never use. It is to ask your customer for their function determination in writing, explain why you believe the baseline Article 30(2) terms are the applicable set, and let their risk team make the call. In our experience the determination is often made by a procurement template rather than by the risk function, and it changes when someone asks.

Equally, if you have already been through a serious SOC 2 Type II or an ISO 27001 certification, a good deal of the evidence an addendum asks for exists. You may need a mapping exercise and two or three genuinely new artifacts rather than a program. If a consultancy tells you a DORA addendum requires a full compliance engagement before they have read the addendum, get a second opinion.

Where Top Floor fits

We work both sides of the line. For entities in scope we build the framework, the incident workflow, the register, and the testing program under our DORA practice. For vendors on the receiving end of an addendum, we do the narrower and usually cheaper thing: read the addendum, map it to what your existing ISO 27001 or SOC 2 program already evidences, and tell you what is genuinely missing.

Where the exposure is broader than DORA, because you sell into several regulated markets at once, that is international compliance work rather than a single-regulation project, and it should be scoped that way.

How to decide this week

Three steps, in order.

First, establish whether any EU-licensed entity sits inside your own corporate group. If one does, you are in scope directly and the addendum question is secondary.

Second, list your EU financial customers and, for each, get their critical-or-important-function determination in writing. Two questions in an email, and it determines which contractual set applies.

Third, take the Article 30(3) list above and mark each item green, amber, or red against evidence you could produce this month. Amber and red are your actual project. Everything else is reading.

Frequently asked questions

Does DORA apply to a US company with no EU entity?

Not directly. DORA binds the EU financial entities listed in Article 2 and the ICT providers the European Supervisory Authorities designate as critical. A US vendor with no EU authorization and no designation is regulated by neither. The obligation reaches you through your customers' contracts under Articles 28 to 30, which is a commercial exposure rather than a regulatory one, and it is enforced by your customer's procurement team rather than by a supervisor.

What is a critical or important function under DORA?

It is a function whose disruption would materially impair the financial entity's regulatory compliance, its financial performance, or the soundness and continuity of its services and activities. The determination belongs to the financial entity, not to the vendor, and it decides whether the baseline Article 30(2) contract terms apply or the enhanced Article 30(3) set on top of them.

Does a SOC 2 report satisfy DORA?

No, and no report does on its own. A SOC 2 Type II covers a great deal of the underlying control evidence a DORA addendum asks about, particularly access control, change management, logging, and vendor management, so it shortens the work considerably. It does not produce the register of information entries, the documented exit and transition plan, or the threat-led penetration testing participation that Chapter V requires, and those are the items that usually hold up signature.

What happens if we refuse the audit clause?

Commercially, the deal usually stops. Your customer cannot contract for ICT services supporting a critical or important function without the Article 30(3) terms, so refusing the audit right asks them to breach a regulation on your behalf. What is negotiable is how the right is exercised: notice, frequency, scope, pooled audits shared across several financial customers, and reliance on independent assessment reports are all normal. Negotiate the exercise, not the existence.