Regulated cloud
You can outsource the servers, not the accountability
A DIFC or ADGM firm that moves its email, its client records and its core systems into a public cloud has not moved its regulatory obligations anywhere. The provider runs the infrastructure. The Authorised Person still answers to the regulator for every one of those systems. That single sentence is the foundation of every set of cloud compliance requirements you will meet in this market, and it is the one point firms most often get wrong when they sign.
The practical consequence: the due diligence you do before the contract, and the oversight you keep after it, become part of your regulatory record. If the DFSA or the FSRA arrives and asks how you satisfied yourself that your provider was fit for purpose, "it is Microsoft, so it is fine" is not an answer. What follows is what the regulators actually look for, what a compliant provider looks like, and what to check before you sign anything.
The source material
The rulebooks that set the bar in DIFC and ADGM
Neither centre publishes a single document called "the cloud rules". The expectations sit across four places, and an inspector will expect you to know all four.
- The DFSA Rulebook, which carries the requirements on material outsourcing. Cloud services are not separately regulated in the DIFC, so whether the outsourcing rules bite depends on what you host and how material it is to your regulated activity.
- The FSRA Rulebook in ADGM, where an Authorised Person retains full regulatory responsibility for anything that goes wrong at a third party, including a failure by that third party to meet its own obligations. Certain core systems cannot be outsourced at all.
- The Guidelines for Financial Institutions Adopting Enabling Technologies, issued jointly by the Central Bank of the UAE, the DFSA, the FSRA and the Securities and Commodities Authority. These apply to institutions using cloud computing and are expected to be applied proportionately to the size, complexity and risk of the firm.
- Data protection law, which in the DIFC means Data Protection Law No. 5 of 2020 and its regulations, and in ADGM means the centre's own data protection regime. Both sit alongside, not inside, the financial rulebook.
What regulators expect from a cloud provider
Documented governance
A named owner for the cloud arrangement inside your firm, a board-approved policy, and a risk assessment that classifies which assets sit where and how critical each one is.
Encryption and key control
Data encrypted in transit and at rest, with a clear answer to a harder question: who holds the keys, and can the provider read your data without your permission?
Identity and access control
Role-based permissions, multi-factor authentication, privileged access that is granted deliberately rather than inherited, and audit trails that show who did what.
Independent assurance
Certifications and third-party audit reports you can actually read, refreshed on a cycle. A logo on a website is marketing. A current report is evidence.
Continuity and recovery
A business continuity and disaster recovery plan on the provider side that is compatible with yours, with recovery objectives you have agreed rather than inherited.
Records you can retrieve
Data held on a cloud platform must be retained for the period the rulebook requires, and must be retrievable and producible to the regulator on demand, with immediate effect.
Shared responsibility: who owns what
Every major cloud publishes a shared responsibility model. Read it before you assume anything, because the line falls in a different place for infrastructure, platform and software services, and misconfigurations on the customer side of that line drive most real-world failures.
- Physical data centres, hardware and the hypervisor layer.
- The security and availability of the underlying platform.
- Patching the services it operates for you.
- Its own certifications, audit reports and sub-processor list.
- Notifying you of incidents that affect your environment.
- Every configuration setting in your tenant.
- Identity, access rights and privileged accounts.
- Classifying data and choosing what gets encrypted.
- Retention, logging and the evidence an inspector will ask for.
- Regulatory accountability, in full, for all of the above.
Residency
Data residency and cross-border transfers
This is where most cloud compliance requirements turn from theory into an architecture decision. Under DIFC Data Protection Law No. 5 of 2020, personal data may move to a jurisdiction outside the DIFC only where that jurisdiction offers an adequate level of protection, as determined by the Commissioner of Data Protection. Where adequacy does not apply, you fall back on the safeguards in the law: standard contractual clauses, binding corporate rules, or a narrow derogation.
The trap is that a cloud region is not the whole story. Support access, backups, telemetry and disaster recovery copies all move data, and each one is a transfer. Firms working across both the free zones and the mainland should also read this alongside the data localization and privacy rules that apply across the wider UAE, because a group structure will usually touch both regimes at once.
- Pin the primary region, then ask where backups and DR replicas actually land.
- Get the sub-processor list in writing, and the notice period for changes to it.
- Ask whether support engineers outside the region can access production data.
- Document the adequacy assessment for every transfer path, not just the obvious one.
Certifications and security standards worth asking for
A provider should be able to produce current evidence, not a badge. The Enabling Technologies Guidelines are explicit that firms may take into account external assurance already provided by independent auditors when doing their own due diligence, which makes the report itself the thing to ask for. For a broader view of how these map together, see the security frameworks UAE businesses are most often measured against.
| Standard | What it actually proves | Why a DIFC or ADGM inspector cares |
|---|---|---|
| ISO/IEC 27001 | A certified information security management system, audited on a cycle. | Baseline evidence that security is managed as a system, not improvised. |
| ISO/IEC 27017 | The cloud-specific control set carved out of the 27000 family. | Directly addresses the controls that only exist because it is cloud. |
| ISO/IEC 27018 | Protection of personal data processed in a public cloud. | Supports the data protection side of your file, not just the security side. |
| SOC 2 report | An independent auditor's opinion on controls at a service organisation. | Since you will never audit a hyperscaler's data centre yourself, this is the substitute. |
| CSA STAR / CCM | Assurance mapped to the Cloud Controls Matrix. | Gives you a control-by-control view to map against your own risk register. |
| PCI DSS | Controls for storing, processing or transmitting card data. | Only relevant if you touch card data, but non-negotiable when you do. |
Ask for the report, the scope statement and the date. A certificate that covers a different region or a different service line than the one you are buying is not evidence about the service you are buying.
Resilience
Business continuity, exit planning and the resilience test
The guidance is direct on this point: where a cloud arrangement is outsourced, the outsourcing service provider should have a business continuity and disaster recovery plan of its own. Yours has to interlock with it. That means defined recovery time and recovery point objectives, tested rather than asserted, with the test results written down.
Exit is the half of the conversation that gets skipped. A regulator will ask what happens if the provider fails, is acquired, or exits the region. Firms that cannot describe how they would get their data back, in a usable format, within a defined window, have an open finding waiting to happen. Where recovery objectives are tight, disaster recovery as a service is usually the cleanest way to evidence a tested position rather than a paper one.
- Agreed RTO and RPO, in the contract, not in the sales deck.
- A restore test you have personally witnessed, with a dated report.
- An exit clause covering data return, format, timeline and secure deletion.
- Termination assistance, so the provider is contractually obliged to help you leave.
Incident reporting: the clock starts when you become aware
Incident reporting is where the provider relationship gets tested under pressure. In ADGM, the cyber risk framework requires firms to oblige their ICT service providers to notify them of any cyber incident that has, or is likely to have, a material impact, and firms must in turn notify the FSRA within 24 hours of becoming aware. That obligation is only survivable if the contract forces the provider to tell you quickly. On the data protection side, a DIFC controller must assess a personal data breach and notify the Commissioner as soon as practicable in the circumstances, and inform affected individuals where the risk to them is high.
Provider notifies you
Contractually, within a stated window, with enough detail to assess materiality. Silence is not an option you can accept.
You assess materiality
Against your own classification criteria, decided in advance. Deciding what counts as material during an incident is too late.
You notify the regulator
To the FSRA or the DFSA on the relevant timeline, and to the data protection Commissioner separately where personal data is involved.
You log it either way
Including incidents you decided not to report, with the reasoning. The register is the evidence that the process works.
Before you sign
The questions to ask before you sign
None of the standard cloud-compliance guides publish this list, because most of them are written for a market where the vendor is not also the regulatory exposure. Take it into the meeting.
- Which region will host production, backups and DR?
- Who can access my data, from where, and under what approval?
- Show me the current SOC 2 report and its scope.
- Which sub-processors are in the chain today?
- What notice do I get before a sub-processor changes?
- How fast will you tell me about a security incident?
- Will you give the regulator access and information if asked?
- Will you deal with the regulator openly and cooperatively?
- Can I audit you, and if not, what do I get instead?
- What are your tested RTO and RPO for my workloads?
- How do I get my data back, in what format, in what window?
- Who holds the encryption keys, and can I hold my own?
- Where are the audit logs, and how long do you keep them?
- Does the contract survive your acquisition or exit?
Two of these are not commercial preferences: the DFSA rules require that a material outsourcing contract obliges the provider to give the regulator information and premises access, and to deal with the regulator openly and cooperatively. If a provider will not sign that, the conversation is over.
Failure modes
Common compliance mistakes
- Treating the provider's certification as your compliance. A compliant platform hosting a misconfigured tenant is a non-compliant firm.
- Signing the standard terms. Off-the-shelf cloud terms rarely contain the regulator access and cooperation clauses a material outsourcing needs.
- Classifying nothing. If you have not decided which systems are material, you cannot show why you applied lighter controls to some of them.
- Compliance as a project. Configurations drift, providers change sub-processors, staff leave with access rights intact. This is a monitoring discipline, which is why most firms route it into their managed IT services arrangement rather than leaving it to an annual scramble.
- No exit plan. Easy to enter, impossible to leave, is a resilience finding waiting to be written.
- Assuming shadow SaaS is out of scope. The file-sharing tool a team signed up for on a card is still processing client data.
Audit readiness: the evidence pack
Audit readiness is not a state of mind, it is a folder. If a supervisor asked tomorrow, these are the artefacts that answer the question without a two-week fire drill. Assemble them once, keep them current, and an inspection becomes an administrative exercise rather than an event.
-
Governance
Policy and ownership
Board-approved cloud and outsourcing policy, the risk management programme, and the name of the person accountable for the arrangement.
-
Due diligence
The pre-contract file
Your assessment of the provider, the certifications and audit reports you reviewed, and the date you reviewed them.
-
Contract
The written agreement
The signed outsourcing contract with the regulator access, cooperation, incident notification and exit clauses visible in it.
-
Data
Mapping and transfers
Where each category of data lives, the adequacy or safeguard basis for every cross-border flow, and the sub-processor register.
-
Operations
Logs, access reviews, test results
Access recertification records, audit trails, the last restore test, and the continuity plan with its tested recovery objectives.
-
Incidents
The register
Every incident, the materiality assessment, the notification decision and the reasoning behind it, including the ones you chose not to report.
Help
Frequently asked questions
Do the DFSA or the FSRA approve specific cloud providers?
No. Neither regulator publishes an approved-vendor list, and cloud services are not separately regulated in the DIFC. What both expect is that you have assessed the provider yourself, against the materiality of what you are putting there, and that you can show the assessment. That means the burden of proof sits with the firm, not the vendor, and a well-known brand name does not discharge it.
Can a DIFC or ADGM firm store data outside the UAE?
Often yes, but it depends on the data and the destination. Under DIFC Data Protection Law No. 5 of 2020, personal data can move to a jurisdiction outside the DIFC where that jurisdiction is assessed as having an adequate level of protection, or where one of the defined safeguards applies, such as standard contractual clauses. The important thing is that the basis for each transfer is documented before the data moves, not reconstructed afterwards.
If my cloud provider suffers a breach, who is accountable?
You are, from the regulator's point of view. In ADGM, an Authorised Person retains full regulatory responsibility for issues arising from outsourcing, including a third party's failure to meet its obligations. The DIFC position is consistent with that. You may have contractual recourse against the provider, but that is a commercial matter between you and them, and it does not move your regulatory accountability.
How quickly does a cyber incident have to be reported?
In ADGM, firms must notify the FSRA of a cyber incident with a material impact, or a likely material impact, within 24 hours of becoming aware of it, and must require their ICT providers to notify them of such incidents in the first place. Personal data breaches follow a separate track: a DIFC controller must notify the Commissioner of Data Protection as soon as practicable in the circumstances, and tell affected individuals where the risk to them is high. Assume you are running both clocks at once.
Which certifications should a cloud provider hold?
ISO/IEC 27001 as the baseline, ISO/IEC 27017 for the cloud-specific controls, ISO/IEC 27018 where personal data is processed, and a current SOC 2 report. PCI DSS applies only if card data is in scope. The Enabling Technologies Guidelines allow you to take external assurance from independent auditors into account in your own due diligence, so ask for the report and its scope statement, not just the badge.
Is public cloud acceptable, or is on-premise safer for a regulated firm?
Both are acceptable, and neither is automatically compliant. Public cloud, private hosting and hybrid models are all used in the DIFC and ADGM. The regulator's interest is in the controls, the accountability and the evidence, not the deployment model. Hybrid is common where a firm wants public cloud economics for general workloads while keeping a specific class of records under tighter local control.
Does using Microsoft 365 or AWS make my firm compliant automatically?
No, and this is the single most expensive assumption in the market. The provider secures the platform. You configure the tenant, set the access rights, classify the data, and keep the logs. Misconfiguration on the customer side of the shared responsibility line causes the large majority of real-world failures, and the tenant is your side of that line.
What will an inspection actually ask me to produce?
In practice: your cloud and outsourcing policy, the due diligence file on the provider, the signed contract showing the regulator access and cooperation clauses, your data map and transfer assessments, access review records, the last tested restore, and the incident register. If those exist and are current, the inspection is a conversation. If they do not, it is a finding.
Planning the move, not just the paperwork
If the compliance questions above are surfacing while you are still deciding what to migrate and in what order, the architecture and the evidence pack are best designed together. Our guide to cloud migration services covers how the sequencing works in practice for UAE firms.
