DORA is an EU regulation. It reaches UAE companies through their contracts.
If you supply ICT services to an EU financial entity, Article 30 sets out clauses your contract must now contain, including unrestricted audit rights and a mandatory transition period on exit. Most UAE suppliers meet DORA through a customer, not a regulator.
- 17 Jan 2025The date the Regulation applies from
- 21 entity typesListed in Article 2, including ICT providers
- Every 3 yearsThreat-led penetration testing cadence
- UnrestrictedAudit rights required for critical functions
Two routes, and most companies arrive by the first one.
DORA is not a UAE regulation and no UAE authority enforces it. That does not stop it landing on a UAE business.
- You supply ICT services to an EU financial entity. Software, hosting, managed services, payment processing, data analytics, support desks. The customer is required to obtain the Article 30 provisions from you, so they arrive as a contract amendment rather than as a regulatory notice.
- You are part of a group whose EU entities are in scope. A UAE subsidiary, branch or shared service centre supporting an EU financial entity inherits the requirements through group policy, and usually inherits them with a deadline attached.
- The practical trigger is almost always a document. A revised master services agreement, a due diligence questionnaire that is longer than the last one, or a request for audit rights and an exit transition period that your standard terms do not currently offer.
- The reason this catches people is that the request arrives from a commercial contact rather than a regulator, and it looks negotiable. Article 30 makes several of those provisions mandatory for the customer, which means they are not.
Eight things a UAE organisation needs to know.
ICT providers are named in the scope article
Article 2 lists twenty one categories the Regulation applies to, from credit institutions and payment institutions through insurers, trading venues and crypto-asset service providers, and the list ends with ICT third-party service providers. That last entry is where most UAE companies sit.
Article 30 rewrites your contract
All ICT service contracts must carry a clear and complete description of the services, the regions or countries where they are provided, data protection provisions, data return guarantees, service level descriptions, incident assistance terms and cooperation with competent authorities.
Unrestricted audit rights for critical functions
Where the service supports a critical or important function, the contract must give unrestricted rights of access, inspection and audit to the financial entity, an appointed third party, and the competent authority, including copies of relevant documentation on site.
Exit is a contractual obligation, not a courtesy
Financial entities must put in place exit strategies for ICT services supporting critical or important functions, and contracts must include a mandatory adequate transition period during which the provider continues to deliver the service while the customer migrates.
A register of every ICT arrangement
Financial entities maintain a register of information covering all contractual arrangements at entity, sub-consolidated and consolidated levels, and report at least yearly to competent authorities on new arrangements, provider categories, contract types and the services involved.
Major incidents are reported in three stages
An initial notification, an intermediate report submitted as soon as the status of the original incident has changed significantly, and a final report once root cause analysis is complete. Significant cyber threats may also be notified voluntarily.
Threat-led testing every three years
Financial entities other than those under the simplified framework carry out advanced testing by means of TLPT at least every three years, performed on live production systems. Suppliers can be required to participate and fully cooperate in that testing.
Responsibility does not transfer
The Regulation states that financial entities using ICT services remain fully responsible for compliance at all times. That is why the obligations flow down to suppliers as contract terms rather than stopping at the financial entity boundary.
What every contract needs, and what critical functions add.
| Provision | All ICT contracts | Critical or important functions | |
|---|---|---|---|
| Description of functions and services | Clear and complete | Plus subcontracting conditions | |
| Locations of provision | Regions or countries stated | Advance notice of changes | |
| Service levels | Descriptions with updates | Precise quantitative and qualitative targets | |
| Data protection | Availability, authenticity, integrity, confidentiality | Same, applied to critical data | |
| Data return on exit or insolvency | Access, recovery and return in an accessible format | Same | |
| Incident assistance | At no additional cost or a cost fixed in advance | Same | |
| Audit and inspection | Cooperation with authorities | Unrestricted access, inspection and audit rights | |
| Business contingency | Not specified at this level | Implement and test contingency plans | |
| Resilience testing | Not specified at this level | Participate and fully cooperate in TLPT | |
| Exit | Termination rights | Mandatory adequate transition period |
Four things that keep a DORA response proportionate.
We tell you when you are not in scope
DORA binds EU financial entities and reaches suppliers through contract. If none of your customers appear in the Article 2 list and you are not inside an EU financial group, the correct advice is that this does not currently apply to you.
We work from the clauses, not the whole Regulation
For a supplier, Article 30 is the operative text and Article 28 explains why the customer is asking. Reading those two properly produces a shorter and more accurate response than treating all sixty four articles as a compliance checklist.
We separate commitments from capabilities
Signing a clause about tested contingency plans creates an obligation to have tested contingency plans. We identify which commitments you can already evidence and which need work first, so the contract does not get ahead of the operation.
We build the evidence pack once
Financial entities report annually to competent authorities on their ICT arrangements and carry out their own due diligence. A reusable pack turns each of those requests from a project into a response, which is where the ongoing saving is.
Four phases across roughly eight to twelve weeks.
- 01Weeks 1 to 2
Establish exposure
Which customers are financial entities within the Article 2 list, which services support a critical or important function in their operations, and which contracts have already been amended. That map determines the whole scope of the work.
- Customer base assessed against the Article 2 entity list
- Services classified by criticality to the customer
- Existing contract terms assessed against Article 30
- Group entity exposure documented where relevant
- 02Weeks 3 to 5
Close the contractual gaps
The provisions you can meet today, the ones that need operational change first, and the ones that need a commercial decision. Unrestricted audit rights and a mandatory transition period are the two that most often need both.
- Clause by clause gap analysis against Article 30(2) and 30(3)
- Positions agreed on audit rights and transition periods
- Standard terms updated for future contracts
- Negotiation support for amendments already received
- 03Weeks 6 to 9
Build the operational evidence
Contract clauses commit you to capabilities. Incident assistance, contingency plans that are tested rather than written, service levels with quantitative targets, and the ability to support a customer TLPT all need to exist before somebody asks to see them.
- Incident notification and assistance process documented
- Contingency plans tested with evidence retained
- Service level measurement and reporting in place
- Data return and portability process proven
- 04Weeks 10 to 12
Prepare for scrutiny
Financial entities report annually to their competent authorities on their ICT arrangements, and they audit their providers to support that. The deliverable here is being able to answer a due diligence pack without assembling it from scratch each time.
- Due diligence response pack assembled
- Audit readiness rehearsed with an internal walkthrough
- Subcontractor position documented and controlled
- Ongoing evidence maintenance assigned to an owner
Six situations we are asked about.
A Dubai software vendor with European bank clients
The renewal arrives with fifteen new pages. Unrestricted audit rights, precise service level targets, a transition period on exit and an obligation to cooperate in threat-led penetration testing. Several of those are mandatory for the customer to obtain.
A UAE shared service centre inside an EU group
The EU entity is directly in scope and the UAE operation supports it, so group policy applies the requirements internally. The register of information the group maintains has to describe what the UAE centre does and where.
A hosting provider asked where the data actually sits
Contracts must state the regions or countries where the contracted or subcontracted services are provided, with advance notification of any change. Providers who move workloads between regions operationally need that reflected in the agreement.
A managed service provider asked for an exit plan
For critical or important functions the contract must include a mandatory adequate transition period during which the provider continues the service while the customer migrates. That is a commercial and operational commitment, not a clause to accept lightly.
A supplier during a customer incident
The financial entity has three reports to file and a clock running. Contracts require the provider to assist during ICT incidents at no additional cost or at a cost determined in advance, which means the assistance model needs defining before the incident.
A provider pulled into threat-led testing
Financial entities carry out TLPT at least every three years on live production systems, and contracts for critical functions require providers to participate and fully cooperate. That participation needs planning rather than improvising during the test window.
How UAE suppliers are responding to DORA clauses.
| Feature | Prepared and evidenced | Sign now, work it out later | Push back and hope |
|---|---|---|---|
Contract terms met | Yes, deliberately | Signed, not delivered | Under dispute |
Audit rights honourable | Yes, rehearsed | Untested | Refused |
Exit transition deliverable | Yes, documented | Unclear | Not offered |
Evidence pack available | Reusable | Built each time | None |
Sales cycle impact | Shortens due diligence | Delays at audit stage | Loses the deal |
Risk of breach claim | Low | Real | Not applicable |
Position with EU group customers | Preferred supplier | Tolerated | Replaced |
Cost profile | Front loaded, then low | Unpredictable | None until lost revenue |
Suits a business with EU financial clients | Yes | Temporarily | No |
Suits a business with none | Not needed yet | Not needed | Not needed |
Four capabilities that turn a signed clause into something you can actually deliver.
Every provision in Article 30 commits you to a capability. These four are the ones that need building rather than drafting, and they are the ones an audit tests.
- A defined incident assistance model. The contract requires assistance during ICT incidents at no additional cost or at a cost determined in advance, so somebody has to decide what assistance means, who provides it, at what hours, and how it is invoked before an incident makes those questions urgent.
- Contingency plans that have been tested. For critical or important functions the contract requires implementing and testing business contingency plans, which is a materially higher bar than having written them. Testing produces evidence with a date on it, and that date is what an auditor asks about.
- Service levels with precise quantitative and qualitative performance targets. Availability expressed as a percentage over a defined window, with a measurement method both sides agree on, is a very different artefact from a general commitment to high availability in a marketing document.
- A proven data return path. Access, recovery and return in an easily accessible format has to be demonstrable, including on insolvency. Exporting a representative data set once and confirming it can be loaded elsewhere converts a clause into a capability you can evidence.
Five steps, and the first can end it.
- 1
Establish whether you are in scope at all
Your customers checked against the Article 2 list of financial entities, and your position within any EU group. DORA has applied since 17 January 2025, so the question is present tense rather than a future planning exercise.
- 2
Classify your services by their criticality to the customer
Article 30 sets a baseline for all ICT contracts and adds substantially more where the service supports a critical or important function. That classification is the customer decision, but you need to know it because it changes what you must offer.
- 3
Gap the contracts clause by clause
Service description, locations, data protection, data return, service levels, incident assistance, authority cooperation, termination. Then for critical functions, quantitative targets, tested contingency plans, TLPT cooperation, unrestricted audit and a transition period.
- 4
Build the capabilities the clauses commit you to
Tested contingency plans, measurable service levels, a defined incident assistance model, a proven data return path and an audit process you can host without disruption. This is where the real work is, and where most of the value is too.
- 5
Assemble a reusable evidence pack and assign an owner
Due diligence requests recur, because financial entities report annually on their arrangements and reassess their providers. A maintained pack answers them quickly, and an owner keeps it from going stale between requests.
What UAE organisations ask about DORA.
Fifteen questions that establish where you stand.
Are you in scope
- Do you serve any EU financial entity?Article 2 lists 21 categories.
- Do you supply ICT services to them?Broadly defined.
- Are you part of an EU financial group?Group policy flows down.
- Have you received a contract amendment?The usual first sign.
- Do you subcontract any of it?Subcontracting is addressed directly.
Contract readiness
- Do your terms allow unrestricted audit?Required for critical functions.
- Do they state where services are provided?Regions or countries.
- Do you commit to a transition period on exit?Mandatory and adequate.
- Are service levels quantitative?Precise targets are required.
- Is incident assistance costed in advance?Or provided at no cost.
Operational readiness
- Can you return data in an accessible format?Including on insolvency.
- Are contingency plans tested?Implement and test, not just write.
- Could you support a customer TLPT?Cooperation may be required.
- Is there an incident notification path?Their reporting depends on yours.
- Who owns this after the project?Evidence goes stale quickly.
Check whether any contract you signed recently mentions audit rights or a transition period.
Those two clauses are the clearest sign that DORA has reached you through a customer. If they are in there, the commitments behind them need to be real.
Related Services
Explore more solutions that work great with this service
NIS2 compliance
What EU essential and important entities need from suppliers.
Cloud exit and portability
Whether leaving your cloud provider is actually possible.
Third Party Risk Audit
Who can actually reach your systems, and what to do about it
ISO 27001 Certification UAE
The 2022 edition, and whether you should certify at all
Incident Response Plan
Written, exercised, and findable when the network is not
Business Continuity Planning
BCP, RPO/RTO design, and DR runbook authoring
IT Risk Assessment
A short register with an owner against every risk
Compliance as a Service
Keeping the position true between assessments