DORA has applied since 17 January 2025, and it means banks, insurers, and fintechs now have to vet ICT providers far more rigorously. If you sell IT services to the financial sector, prepare an “evidence pack,” incident procedures, and ready-made contract clauses — otherwise you’ll get stuck at the due diligence stage.
What is DORA, and why does it affect ICT companies even if you’re not “a financial firm”?
DORA (Digital Operational Resilience Act) is an EU regulation on the digital operational resilience of the financial sector. It directly regulates the obligations of financial entities, but in practice it also pulls in their ICT providers, because financial firms must be able to prove they control vendor risk, have the right to audit, know the subcontractor chain, and can exit a service without a catastrophe.
From my experience (projects for companies serving banks, payments, and insurance), it always looks the same: for years, ISO certification, “we have backups,” and a general security policy were enough. After DORA, you get a questionnaire running dozens of pages, a request for a subcontractor map, a requirement for BCP/DR testing, and a contract clause giving the client the right to audit. Suddenly marketing stops mattering — evidence is what counts.
Which DORA requirements most often land on the ICT provider?
Three areas will hit you most often:
- Contracts and oversight rights: a financial client will require clauses on audit rights, access to information, support for resilience testing (including TLPT where applicable), and BCP obligations. (Digital Operational Resilience Act)
- Supply chain and subcontractors: the client has to control subcontracting and concentration risk, so you need to be able to show who supports you and on what terms. (EUR-Lex)
- Incidents and operational evidence: financial firms must report incidents under DORA, so they expect providers to deliver clear classification, timelines, communication channels, and logs that let them reconstruct what happened. (European Banking Authority)
Practical tip: don’t start with “does DORA apply to me.” Start with: will my financial clients require DORA-ready vendor management? If yes, you’re going through this process either way.
What does a typical rollout scenario look like — what actually happens on the client’s side?
A real-life story, no fairy tale involved.
Monday, 9:17 a.m. You get an email from a bank’s procurement department: “Please complete the DORA questionnaire and return it within 5 business days.” Attachments: an ICT risk questionnaire, required policies, a list of BCP test evidence, a request for subcontractor data, questions about data location, log retention, RTO/RPO, encryption, and vulnerability management.
If you don’t have a ready “vendor pack,” the firefighting begins: IT scrambles for documents, legal asks about contract clauses, and the board learns the contract now needs to include an audit right and an exit scenario. Suddenly 5 days feels like an ordeal.
You can break this cycle: build the pack once, update it quarterly, and sell it like a product.
How do you build a “DORA Vendor Pack” that shrinks due diligence from weeks to hours?
This is my favorite hack, because it actually works in real business. A “Vendor Pack” is an organized set of evidence you send the client instead of 80 emails.
The minimum pack for an ICT company:
1) Service description and responsibility boundaries
- list of services (SaaS, hosting, SOC, maintenance, integrations)
- what’s a critical function on the client’s side vs. what’s “supporting”
- support model and availability hours
2) Architecture and technical security
- a high-level diagram (no secrets): zones, access control, segmentation
- encryption of data at rest and in transit
- IAM: MFA, roles, privileged accounts, onboarding/offboarding process
3) Incidents and communication
- definitions, severity classes
- response times, a 24/7 channel for financial clients
- what you deliver in a report: timeline, IOCs, logs, RCA (root cause analysis)
4) BCP/DR, RTO/RPO, and testing
- your RTO/RPO targets (realistic, measured)
- results of restore tests and drills (date, scope, findings)
- a contingency plan for a cloud provider outage
5) Subcontractors and vendor risk
- a list of critical subcontractors and their role (hosting, email, monitoring, helpdesk)
- subcontractor assessment rules and security requirements
- a procedure for changing subcontractors and notifying the client
6) Audits and compliance
- what you already have: ISO 27001, SOC 2, tests, reports
- if you’re not certified: describe your controls and show evidence
This approach lines up with the fact that DORA significantly strengthens oversight of the relationship with ICT providers and requires contracts and policies to cover the entire lifecycle of the partnership.
What contract clauses will be required of you, and how do you prepare without a fight with legal?
DORA explicitly states that contracts with ICT providers must include, among other things, security matters, continuity plans, participation in testing, and rights of access, inspection, and audit for the client and for the authorities.
In practice, prepare for:
- an audit right (on-site or remote, sometimes via a third party)
- a requirement to cooperate with supervisory authorities (through the client)
- a BCP/DR and testing requirement plus delivery of the results
- an exit plan: service transfer, data, migration support, timelines
- subcontracting: rules for using subcontractors and notifying about changes
Pro tip from real rollouts: instead of fighting “we won’t allow an audit,” build a layered audit model:
- layer 1: reports, evidence, test results, policies
- layer 2: a remote audit walkthrough
- layer 3: on-site only for critical services and after agreeing the scope
This usually closes the negotiation without wrecking your operational security.
How do you prepare for questions about “critical ICT third-party providers” and ESA oversight?
DORA introduces an EU-wide oversight framework for critical ICT providers (CTPPs). Not every provider will be designated as one, but large players and providers with high concentration risk may be subject to assessment and oversight.
What does this mean for smaller ICT companies?
- Your clients will ask about concentration risk and dependencies, even if you’re not “critical” yourself.
- If you rely on a major cloud provider, the client may want to see how you mitigate vendor lock-in risk.
- There will be pressure for transparency around subcontractors and for an exit plan.
How do you build an incident process that fits DORA and financial-sector expectations?
You don’t need to copy a bank’s processes. You need to deliver something the bank can plug into its own reporting.
Your minimum:
- A 24/7 reporting channel for regulated clients
- Classification criteria: what counts as “major,” what’s a “degradation,” what’s a “security incident”
- Communication SLA: first notice within X minutes, updates every Y hours
- Evidence: logs, metrics, RCA, corrective actions, an IOC list (where applicable)
The EBA and the ESAs publish and organize standards and materials for DORA, including on incident reporting and classification and ICT risk management. In practice, the client will expect alignment with this framework and consistent data.
What “evidence” is most convincing when a client evaluates an ICT provider?
Due diligence isn’t won by whoever has the nicest PDF — it’s won by whoever has measurable evidence.
The top 10 pieces of evidence that actually do the job:
- backup restore test results (with date and findings)
- a report from an incident tabletop exercise
- an access control and MFA inventory (screenshots or export)
- a patching policy plus recent critical update rollouts
- log sources and retention (what you log, for how long, where)
- a vulnerability management and exceptions process
- a list of critical subcontractors plus assessment rules
- RTO/RPO for key service components
- an offboarding and data-deletion procedure
- results of application or infrastructure security testing (even basic ones)
From the financial client’s perspective, these are the puzzle pieces they need to assemble their own compliance.
How do you get ready for your first DORA audit at a financial client in 30 days?
A practical, checkable one-month plan:
Week 1: Pack and ownership
- a DORA vendor management owner on your side
- a versioned Vendor Pack
- a list of regulated clients and their specific requirements
Week 2: Incidents and operational evidence
- a 24/7 channel, report templates, runbooks
- a list of logs and retention periods
- RTO/RPO definitions and how they’re measured
Week 3: Subcontractors and contracts
- a map of subcontractors and dependencies
- standard contract annexes: security, audit, exit plan
- subcontracting rules and change-notification process
Week 4: Testing
- an incident tabletop exercise
- a restore test
- a quick configuration review and hardening of critical systems
Summary: what should an ICT company do to “get through DORA” without pain?
If you supply ICT services to the financial sector, stop treating security as a “feature” and start treating it as a product with evidence. DORA has applied since 17 January 2025, and ESA/EBA standards and materials are turning market expectations into a very concrete set of questions and contract clauses.
Your three priorities to start:
- a DORA Vendor Pack
- an incident process and evidence (logs, tests, RCA)
- contracts and subcontractors (audit, exit, subcontracting)
That’s the difference between “we sell IT” and “we’re a provider financial institutions trust, and whose audits don’t paralyze us.”