Your EU financial-services customer just sent a contract addendum, a register-of-information template and a questionnaire, all citing DORA. You’re a US SaaS or ICT provider, the regulation doesn’t name you, and yet the renewal now depends on clauses about incident notice, audit access, exit support and resilience testing. Readiness shows you which commitments you can already stand behind, closes the ones you can’t, and gives you answers your customer’s vendor-risk team and supervisor can rely on.
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025 to banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and most other regulated EU financial entities. It rests on five pillars: an ICT risk management framework, classification and reporting of ICT-related incidents, digital operational resilience testing, management of ICT third-party risk, and voluntary sharing of cyber threat intelligence. Detailed regulatory and implementing technical standards fill in what each pillar requires.
For a US provider, DORA arrives through the customer. Article 28 makes your customer accountable for the risk you introduce, so it has to keep a register of information on every ICT contract, assess concentration and substitution risk, and hold an exit strategy for services that support critical or important functions. Article 30 then lists the provisions its contract with you must contain: service descriptions, data locations, incident assistance, cooperation with its competent authority, termination rights and, for critical or important functions, precise performance targets, business contingency plans, participation in threat-led penetration testing, unrestricted access and audit rights, and a transition period on exit.
Most teams come to DORA because a customer’s legal or procurement team will not sign without those terms, or because the questionnaire asks for evidence you have never had to assemble in one place. Some come because they expect to be designated a critical ICT third-party provider and overseen directly by an EU Lead Overseer. Either way, you need your security, resilience and contracting practices to match what you are about to promise in writing.
Your platform supports a customer’s payments, lending, claims, trading or customer onboarding, and its contract team now insists on Article 30 terms. You need to know which clauses you can accept as written and what has to change in your operations before you sign.
You run infrastructure or operate systems that an EU financial entity treats as supporting a critical or important function. Its register of information will record you, your locations and your subcontractors, and its exit strategy will depend on how you hand back data and services.
You supply data feeds, identity checks, fraud scoring or core-banking components, and every new EU deal brings the same DORA questionnaire. You want one defensible set of answers instead of rebuilding them for each customer.
Your share of the EU financial market makes designation as a critical ICT third-party provider a real possibility. You want your governance, risk management and EU presence understood before a Lead Overseer starts asking for information directly.
No one — DORA has no certificate; your EU customers answer to their financial supervisors
Compliance is judged by each financial entity’s national competent authority, and critical ICT third-party providers are overseen by a Lead Overseer among the European Supervisory Authorities (EBA, EIOPA or ESMA).
There is nothing to be certified against, so readiness is the work itself: the controls, evidence and contract positions that let your customer show its supervisor that your service is managed properly. Any testing your customer’s regime calls for, including TLPT, is scoped by the customer and its authority.
A finding-by-finding view of where your practices meet, partly meet or miss the obligations your EU customers flow down, mapped to the DORA article or technical standard behind each one.
For each mandatory contractual provision, the commitment you can make, the evidence that backs it and any operational change needed first, so your legal team negotiates from facts.
The service descriptions, locations, subcontractor chain and identifiers customers need for their register, assembled once and kept consistent across every customer who asks.
How you detect, classify and tell an EU financial customer about an incident that could affect its services, with the information fields its own major-incident reporting depends on.
A documented plan for returning data, supporting migration and handing over a service, written so a customer can reference it in its own exit strategy.
The testing program your controls call for, including scenario-based and recovery tests and how you would support a customer’s TLPT, scoped to the services DORA puts in view.
ICT risk, third-party, business continuity, backup and incident policies written or revised to cover what DORA-driven contracts commit you to.
A reviewed answer set with evidence references you can reuse across EU customers instead of starting again on every renewal.
Better found now, by people on your side, than by your assessor.
Contract templates that promise incident notice but no defined process to classify an incident and tell the customer
Business continuity plans that exist on paper but have no recorded test or lessons learned
No written exit plan, so data return and transition support are improvised at termination
An incomplete list of subcontractors and hosting locations behind the service a customer relies on
Audit-rights language that operations cannot honor, with no agreed alternative such as pooled audits
No Legal Entity Identifier or consistent legal-entity data for the customer’s register of information
Backups that are taken but never restored in a test, leaving recovery objectives unproven
No clear owner for DORA commitments, so each customer questionnaire is answered differently
DORA requires significant financial entities to run threat-led penetration testing under the TIBER-EU-based RTS, and you may be asked to take part. A red-team engagement outside that regime is how you learn how your detection and response hold up beforehand.
What the test coversArticle 25 lists penetration testing among the tests a financial entity’s resilience program covers, and customers relying on your platform for an important function will ask to see recent results.
What the test coversEU financial customers usually integrate through your APIs, so authorization, data exposure and abuse of those interfaces are what their vendor-risk teams ask about first.
What the test coversData location, segregation, backup and recovery commitments in a DORA contract depend on how your cloud estate is actually configured.
What the test coversVulnerability assessments and scans are the first item in DORA’s Article 25 list of resilience tests, and customers expect recurring evidence of them.
What the test coversDORA regulates EU financial entities, not their suppliers, unless you are designated a critical ICT third-party provider. In practice it still reaches you: your customer must put the Article 30 provisions into its contract with you, record you in its register of information and assess the risk you bring. If you cannot meet those terms, your customer has a supervisory problem, and that usually becomes your commercial problem.
No. DORA has no certification scheme, and no one can issue a DORA certificate. Your customers demonstrate compliance to their own competent authorities. What you can offer is evidence: policies, test results, independent reports such as SOC 2 or ISO 27001 where you have them, and contract terms you can operate.
It is a function whose disruption would materially impair a financial entity’s performance, its compliance or the soundness of its business. When your service supports one, DORA requires stronger contract terms, including precise performance targets, tested contingency plans, TLPT participation, full audit and access rights and a transition period on exit. Knowing which of your customers classify you this way tells you where the bar is.
Article 30 requires unrestricted access, inspection and audit rights for services supporting critical or important functions, but the technical standards allow customers to use pooled audits with other clients and to rely on independent certifications and audit reports, provided they remain responsible for the outcome. Readiness helps you offer those alternatives in a form a customer’s risk team can accept.
You would be overseen directly by a Lead Overseer from the European Supervisory Authorities, which can request information, run investigations and inspections, and issue recommendations. A provider based outside the EU must establish a subsidiary in the Union after designation. Readiness puts your governance, risk management and records in order before that relationship begins.
For financial entities DORA is the sector-specific rulebook and takes precedence over NIS2 where they overlap. ISO 27001 and SOC 2 are useful evidence of a managed control environment, but neither addresses DORA-specific items such as register data, exit plans, incident classification support or TLPT participation, so readiness maps what you already hold and fills the remainder.
One conversation with someone who does this work. You leave knowing where you likely stand and what readiness would involve for you.
Not sure where to start? One of our testers reviews your internet-facing footprint and sends you a short summary of what an attacker would see — free. Nothing you don’t own is ever touched, and there’s no sales sequence.
Free. No obligation.
