The US SaaS founder closes her first Frankfurt deal on a Wednesday. Deutsche Bank countersigns the MSA on Thursday. On Friday, procurement sends back a forty-page addendum titled “DORA Article 30 Contractual Provisions” and a nineteen-page structured questionnaire that has to be filled out in a specific xBRL-CSV format for something called the Register of Information. Legal has never seen it. Her CTO Slacks her three tabs: DORA text on EUR-Lex (309 pages), a Deloitte survey saying 46% of financial institutions rank this as their hardest DORA requirement, and a $150 tool that claims to auto-generate the vendor pack.
This is the article she wishes had come up at the top of that search. The Digital Operational Resilience Act — Regulation (EU) 2022/2554, applicable since 17 January 2025 — moved from a transition year into active enforcement in 2026. It does not directly bind US-based ICT vendors, and it also does not need to. It binds the ~22,000 EU financial entities they sell to, and those obligations flow through contracts, procurement questionnaires, and vendor risk reviews into every vendor’s day.
Here is what actually applies to a US SaaS company selling into EU financial services in 2026, what the enforcement teeth look like now that the grace period is over, and the vendor information pack that closes procurement in weeks instead of quarters.
What DORA actually is
DORA is EU Regulation 2022/2554. It entered into force in January 2023, became applicable on 17 January 2025, and moved from transition-year supervisory dialogue into active enforcement in 2026. It has one core purpose: bring the entire EU financial sector under a single, prescriptive digital operational resilience regime that covers ICT risk management, third-party risk, incident reporting, resilience testing, and information sharing. Before DORA, each member state and each sector-specific regulator had its own patchwork; DORA replaces the patchwork.
Thirteen binding Regulatory Technical Standards and Implementing Technical Standards were developed jointly by the three European Supervisory Authorities (EBA, ESMA, EIOPA) and published in the Official Journal between June 2024 and April 2025. All are applicable now. The most consequential for vendors are the ITS on the Register of Information (Delegated Regulation 2024/2956) and the RTS on Threat-Led Penetration Testing (Delegated Regulation 2025/1190, effective 8 July 2025).
The regime supervises through National Competent Authorities — BaFin in Germany, ACPR/AMF in France, De Nederlandsche Bank in the Netherlands, CBI in Ireland, CSSF in Luxembourg, and equivalents in every other member state. First-wave 2026 enforcement is targeting entities with no demonstrable compliance effort; formal fines are expected in the second half of 2026.
Does DORA apply to my SaaS?
This is the question every US-based vendor asks the first time DORA comes up in a procurement conversation. The answer has two layers.
Layer one: DORA does not directly bind non-EU vendors. A US SaaS company incorporated in Delaware, hosted in AWS us-east-1, with zero EU employees is not a subject of DORA. There is no direct filing obligation, no direct fine exposure, no requirement to establish an EU entity.
Layer two: your EU customer’s DORA obligations flow through the contract into every operational decision you make. If your customer is one of the 22,000 EU financial entities, DORA obligates them to embed a specific set of Article 30 contractual clauses in every ICT third-party arrangement. It obligates them to record your service, your subcontractors, your data locations, and your incident history in the Register of Information they submit to the NCA annually. It obligates them to notify you within specific timelines of any incident where your service is a suspected cause. And, if your customer is subject to TLPT (currently the largest banks and insurers), it obligates them to require your participation in threat-led penetration testing.
The practical effect is that DORA compliance becomes a vendor-selection criterion the moment your customer’s procurement team reads Article 30. Vendors who cannot produce the required contractual language, the Register-of-Information data pack, and evidence of the required security controls lose deals. Not because the vendor is legally non-compliant — the vendor has no direct legal obligation — but because the customer’s legal obligation makes the vendor’s cooperation the customer’s regulatory risk.
If the European Supervisory Authorities designate your firm as a Critical ICT Third-Party Provider (CTPP) under Article 31, DORA binds you directly. The first list was published in November 2025 — secondary market coverage reports it as nineteen providers dominated by hyperscalers (AWS, Microsoft Azure, Google Cloud), core banking and market-infrastructure vendors (SWIFT, FIS, Fiserv, Worldline, Temenos, Finastra), and others; the ESA press release links to an authoritative PDF rather than publishing the enumeration inline, so cross-check the source list before quoting names. Designated CTPPs face direct EU-level oversight by a Joint Oversight Forum coordinated by the ESAs, mandatory establishment of an EU subsidiary if not already present, and periodic penalty payments of up to 1% of average daily worldwide turnover for each day of breach (Art. 35(6)). Unless you are at hyperscaler or systemic-market-infrastructure scale, this is not you — but every non-CTPP vendor should understand the regime because their customers keep asking about it.
The Register of Information — the operational choke point
Article 28(3) requires every EU financial entity to maintain a Register of Information covering every contractual arrangement with an ICT third-party service provider. The register is structured, not free-form — Delegated Regulation 2024/2956 mandates a specific xBRL-CSV relational schema with LEIs (Legal Entity Identifiers), granular function classifications, subcontractor chains, data locations, and cross-border transfer flags. First annual submission was due 30 April 2025; the second cycle closed 31 March 2026; every 30 April thereafter.
Deloitte’s 2025 DORA survey found that 46% of financial entities named the Register of Information as the single most challenging DORA requirement. The recurring pain points were consistent: inconsistent vendor metadata across the ICT stack, incomplete contract inventories, unclear ownership of sub-contractor relationships, and vendors who could not turn around structured data in a format that fed the xBRL-CSV template. The pattern from the first submission cycle is expected to repeat — procurement teams already flagging vendor cooperation as their pacing constraint for the 2027 cycle.
For a US SaaS company, this is the highest-leverage compliance investment. The vendor who produces a structured, shareable “DORA vendor information pack” on procurement request wins on time-to-close against vendors who require multiple back-and-forth email cycles to hand over the same data. The pack does not need to be elaborate; it needs to be structured and stable.
Fifteen data points cover 90% of what a customer’s Register of Information needs from you. Package them in a stable format (CSV or JSON, versioned, dated) and hand them over on procurement request.
Entity identity: your Legal Entity Identifier (get one from GLEIF if you don’t have one, ~$100/year); registered legal name and jurisdiction; primary place of business; ultimate parent (if any).
Service description: canonical name of the service the customer is buying; functional category (per DORA taxonomy); whether the service supports a “critical or important function” from the customer’s perspective (they classify, you note); production data centers by country; data-at-rest and data-in-transit geography.
Subcontractor chain: named cloud infrastructure provider (AWS/Azure/GCP/etc.) with region; named data-processing subprocessors your service depends on; any critical dependency that would prevent service continuity if unavailable.
Security posture: most recent SOC 2 Type II report (with period of coverage); ISO 27001 certification (with certification body and expiry); DORA-relevant control mappings if you have them; latest penetration test date and scope.
Continuity + exit: your Recovery Time Objective and Recovery Point Objective commitments; data extraction format and timeline for termination scenarios; whether you offer contractual exit assistance.
The Article 30 clauses that will land in your contract
Article 30 splits contractual requirements into two tiers — a baseline that applies to every ICT third-party arrangement, and an enhanced set that applies when the arrangement supports a critical or important function on the customer’s side. Every EU financial-entity customer is going to bring the enhanced set to the table if your service touches anything they consider critical — which for most SaaS-selling-into-finserv patterns means yes.
The practical vendor response is to build an Article 30 addendum as a one-time contractual asset. Every EU financial-entity customer is going to want something like it; producing your own version proactively is faster than negotiating each customer’s markup line by line. Most large customers will negotiate on top of your addendum; that is fine and expected. The alternative — entering each negotiation without your own base language — puts you on the customer’s timeline, which is measured in months.
Incident classification and the 4-hour, 24-hour, 72-hour, 1-month clock
Article 19 and its supporting RTS establish a specific incident-reporting cascade for “major ICT-related incidents.” The classification test is that at least two of seven criteria must be met above thresholds set out in the RTS — criteria include number of clients affected, geographic spread, data losses, criticality of services impacted, duration and downtime, direct and indirect economic impact, and reputational impact. The reporting cascade for a confirmed major incident:
- Initial notification: within 4 hours of classification, and no later than 24 hours from awareness.: A short structured notification to the NCA on the ESA-provided template. The 4-hour clock starts the moment the financial entity classifies the incident as major; the 24-hour ceiling is the absolute deadline from first awareness, regardless of when classification completes. For a vendor whose service is the cause, this means the customer expects a call from you fast enough for them to hit their own clock.
- Intermediate report: within 72 hours.: A more detailed report covering the incident's scope, root cause where known, remediation actions taken and planned. The vendor is expected to provide the technical detail the customer cannot obtain from their side of the interface. Vendors who go dark for 72 hours during a customer's DORA incident put the customer in supervisory jeopardy and lose the relationship even if the underlying issue is resolved.
- Final report: within one month.: The full post-incident report including root cause analysis, remediation completion, lessons learned, and evidence of controls to prevent recurrence. This is where the vendor produces the RCA document and the customer folds it into their submission to the NCA.
The practical vendor obligation is to have a documented, tested incident-notification workflow that can trigger within hours of a service incident, not days. A generic status-page-plus-support-ticket setup is not enough. What EU financial-entity customers increasingly ask for is a named incident-response contact, a documented incident-severity mapping (yours to DORA’s), and a commitment to structured data hand-off inside the 4-hour and 72-hour windows.
What changed in 2026: from transition to active enforcement
2025 was widely characterized by NCAs as a “supervisory dialogue” year — supervisors were assessing frameworks, identifying gaps, and issuing informal guidance rather than administrative sanctions. That posture ended with the 2026 supervisory cycle. Formal DORA supervisory assessments, Register-of-Information cross-checks, and enforcement actions are now the default. The first formal fines are expected in the second half of 2026, and the pattern from parallel EU regulatory launches suggests initial actions will target entities with no demonstrable compliance effort — missing Register submissions, absent incident-reporting workflow, contract inventories that cannot be produced on request.
The penalty regime is substantial, though the specific ceilings vary meaningfully by member state (Article 50 delegates administrative penalty implementation to member states, and DLA Piper’s October 2025 analysis documented material divergence). The commonly-cited ceilings: financial entities face administrative fines up to the greater of €10 million or 2% of total annual worldwide turnover; individual senior managers with responsibility for DORA compliance face personal fines up to €1 million; Critical ICT Third-Party Providers face administrative fines of up to €5 million and Lead-Overseer-imposed periodic penalty payments of up to 1% of average daily worldwide turnover per day of continued breach. Check the specific NCA regime for the member state(s) your customers operate in — the ceilings above are not uniform.
For US SaaS vendors, direct fine exposure remains near-zero unless designated as a CTPP. The exposure that matters is customer-selection exposure. An EU financial entity considering a US SaaS vendor in 2026 is looking at DORA compliance in the same way a US enterprise customer in 2015 was looking at SOC 2 — a threshold that has to be crossed before procurement proceeds.
Where DORA overlaps with what you already have — and where it doesn’t
The good news: if you already carry SOC 2 Type II and ISO 27001, roughly 40–60% of DORA’s control expectations are already evidenced in your existing framework. Multi-framework mapping tools (Vanta, Drata, ISMS.online, BARR Advisory’s coordinated-audit approach) report evidence reuse in that range across ICT risk-management, access-control, encryption, incident-response, and change-management domains. If you have both, your ISO 27001 Annex A controls and your SOC 2 Trust Services Criteria are the substrate on which DORA-specific work sits.
The DORA delta — the requirements SOC 2 and ISO 27001 do not cover — is where the actual new work lives:
DORA and AI — what the regulation actually says
DORA does not name artificial intelligence anywhere in its 64 articles. The text is technology-neutral: AI systems used by financial entities are treated as ICT, subject to the same ICT risk management framework (Articles 5–16), the same third-party risk regime (Articles 28–30), the same incident-classification cascade (Articles 17–23), and the same testing obligations (Articles 24–27) as any other ICT system. There is no separate AI carve-out and no AI-specific control set inside DORA itself.
The AI-specific rule lives in the EU AI Act (Regulation 2024/1689), applicable in phased tranches with the major financial-services-relevant obligations taking effect on 2 August 2026. Where DORA and the AI Act meet for a US SaaS vendor with AI features is the point that matters:
- AI Act Article 9(10) explicitly permits integration.: Financial entities may integrate the AI Act's AI risk management system into their DORA ICT risk management framework rather than running two parallel governance stacks. This is the regulatory design signal: the AI Act does not require a separate AI governance regime for financial-sector deployers; it lets them fold AI risk into the DORA ICT risk framework the customer already operates.
- Your AI features get pulled into the same Article 30 addendum, Register of Information, and incident-classification cascade.: There is no AI-specific vendor contract addendum in DORA. There is one Article 30 addendum, and if your product includes AI features, those features are covered by the same base clauses as any other ICT service the vendor provides. The AI-specific expectations layer on top via the customer's AI Act obligations: model provenance, training data governance, human oversight arrangements, transparency documentation. Bring those to the same vendor pack conversation.
- High-risk AI systems face a compound regime.: The AI Act designates specific use cases as "high-risk" — credit scoring and creditworthiness assessment of natural persons is explicitly high-risk (Annex III), which pulls a large fraction of banking AI directly into the top-tier AI Act obligations. When a high-risk AI system is deployed by a DORA-subject financial entity, the customer's compound obligations flow to the vendor: DORA Article 30 clauses PLUS AI Act Article 9 risk management + Article 10 data governance + Article 12 record-keeping + Article 14 human oversight expectations, all in the same procurement conversation.
- Incident reporting stacks, not replaces.: A serious AI incident at a financial entity may trigger BOTH the DORA Article 19 4h/24h/72h/1mo cascade to the NCA AND (from 2 August 2026) the AI Act Article 73 serious-incident reporting to the AI Act market surveillance authority. Two regulators, two templates, two clocks, one underlying event. Vendors whose systems cause the incident have to feed both cascades.
Practical vendor posture in mid-2026: if your SaaS has any AI features that touch a financial-entity customer's workflow — underwriting decisions, transaction monitoring, KYC screening, customer-facing chat, fraud scoring — add AI-specific metadata to your DORA vendor information pack. Model provenance (which foundation model, which fine-tune, versioned), training data governance summary, human-oversight arrangements in your product, and monitoring/logging that would let the financial entity satisfy AI Act Article 12 record-keeping through your service. This is the incremental delta between a “DORA-ready vendor pack” and a “DORA + AI Act 2 August 2026-ready vendor pack.” The buyers who ask you about DORA today will ask you about both in Q4 2026.
The overlap with GDPR, NIS2, and PCI DSS
DORA does not replace — it stacks on top of — the other EU regulatory regimes that already apply to a US SaaS company operating in Europe. Each of the four has its own primary purpose, its own enforcement authority, its own reporting cascade, and its own penalty regime. Understanding the stack is what keeps a compliance program from becoming four disconnected motions.
What to do RIGHT NOW as a US SaaS vendor
Nine practical steps close the gap between where most US SaaS vendors are today and where they need to be to win an EU financial-entity deal without a three-month procurement delay. Ranked by leverage per hour of work:
- Get a Legal Entity Identifier (LEI).: GLEIF-issued, ~$100/year, non-negotiable for every DORA Register of Information entry your customers submit about you. Without an LEI, your customer has a data-quality finding on their submission that traces back to you.
- Build the vendor information pack (the 15 data points above).: Structured, versioned, dated. CSV or JSON. Publish it on your trust portal or hand it over on request. This single artifact eliminates 70% of the back-and-forth every EU financial-entity procurement conversation currently requires.
- Draft the Article 30 addendum as your standard contractual response.: Cover the baseline requirements at minimum, ideally extend to the critical-function tier for customers who need it. Have your legal counsel review against Regulation 2022/2554 Article 30(2) and 30(3). Expect customer markup; ship it as your opening position, not as the final.
- Document the incident notification workflow explicitly.: Named contact, severity mapping (yours to DORA's), notification timeline (aligned to your customer's 4-hour and 72-hour clocks), structured hand-off format for the data your customer needs for their NCA submission. Test it once per year with a tabletop exercise.
- Confirm your subprocessor chain is inventoried and up to date.: Every subprocessor of consequence (cloud infrastructure, database, monitoring, authentication) with country, data-processing scope, DPA in place. DORA-conscious procurement teams will ask for the chain, not just the immediate first-tier vendor.
- Verify your existing SOC 2 / ISO 27001 evidence maps to the DORA-adjacent controls.: The 40–60% overlap is real; the mapping is what makes it usable. Multi-framework compliance platforms (including vCISO Lite) generate the cross-mapping automatically. Doing it in a spreadsheet costs a week; automated mapping is an hour.
- Assess CTPP designation risk.: If you are at hyperscaler scale, systemic market-infrastructure scale, or have concentrated market share in a critical financial-sector function — do the CTPP-designation-risk assessment now. Everyone else, understand the regime because customers keep asking, but move on.
- For vendors serving customers subject to TLPT (large banks and insurers): commit to TLPT participation in the contract.: You will not be executing the TLPT — TIBER-EU-accredited testers do that — but you will be a participant when the customer’s scope crosses your service. Contractually confirming participation is table stakes for those customers; not confirming loses the deal.
- Watch for the 2027 Register-of-Information submission cycle.: The 30 April 2027 deadline sets the pacing constraint for late 2026 vendor onboarding. Customers pursuing new vendors in Q4 2026 will prioritize vendors whose data pack is submission-ready. This is a competitive window.
The bottom line
DORA does not directly bind US SaaS vendors selling into EU financial services in most cases, and it does not need to. It binds the 22,000 EU financial entities they sell to; those entities’ obligations flow through contracts and procurement questionnaires into every vendor’s day. The vendors who treat DORA as a procurement enabler — ship the vendor information pack, ship the Article 30 addendum, ship the incident-notification workflow — win EU financial-sector deals inside weeks. The vendors who treat DORA as somebody else’s problem lose those deals in the procurement stage. Direct enforcement risk is low unless CTPP-designated; commercial risk from unprepared procurement posture is the real exposure.
DORA-ready posture, without a compliance headcount hire
vCISO Lite ships the vendor-side DORA program — Register-of-Information vendor pack generation, Article 30 addendum templating, cross-framework control mapping against your existing SOC 2 or ISO 27001 evidence, incident-notification workflow with named contacts and severity mapping, subprocessor inventory, and cyber risk quantification — on the same platform-augmented vCISO subscription that runs your other compliance frameworks. Purpose-built for US SaaS companies selling into EU financial-sector customers without a Data Protection Officer or a dedicated compliance FTE.
See vCISO Lite’s published pricing starting at $299/month, or start with the practical resource we ship alongside every DORA engagement: the Article 30 addendum template and the vendor information pack schema in your first walkthrough call.