Hosting outside the EEA: adequacy, SCCs, and the transfer most buyers map last
If your provider keeps its servers outside the EEA, the compliance work is yours rather than theirs. This guide covers what an adequacy decision is, how to run a Transfer Impact Assessment that means something, and how one provider outside the EEA answers the question honestly.
What an adequacy decision actually is
An adequacy decision is the European Commission stating, under Article 45 of the GDPR, that a third country provides a level of protection for personal data that is essentially equivalent to the protection inside the EU. Once a country is on that list, personal data can flow to it with no further authorisation and no additional safeguard.
The list is short: Andorra, Argentina, Canada (commercial organisations only), the Faroe Islands, Guernsey, Israel, the Isle of Man, Japan, Jersey, New Zealand, South Korea, Switzerland, the United Kingdom, Uruguay, and the United States only for organisations certified under the EU-US Data Privacy Framework. Morocco is not on it.
Two consequences follow. The first is that "outside the EEA" is not one legal category: moving data to Canada or Japan is a different exercise from moving it to Morocco. The second is that a country can have a comprehensive data protection law of its own and still have no adequacy decision, because the two things are decided by entirely different processes.
Why Morocco has no adequacy decision, and what that changes for you
Morocco has its own data protection regime: law 09-08 on the protection of individuals with regard to the processing of personal data, supervised by the CNDP, the national data protection commission. It is a real regime, with registration duties and its own rules on transfers abroad. It is also not an EU adequacy finding, and nothing in law 09-08 substitutes for one.
Adequacy is a decision the Commission takes after its own assessment of a country’s law and practice. No provider can apply for it, buy it, or accelerate it, and no partnership or local zone arrangement produces one. A supplier either holds data inside the EEA, or the transfer needs an Article 46 safeguard.
So the obligation lands on you. Without adequacy, transferring personal data to Morocco requires an appropriate safeguard: in practice the EU Standard Contractual Clauses (SCCs) together with a Transfer Impact Assessment (TIA), and for the UK the International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs, plus a transfer risk assessment. You are the data exporter, and the exporter is who a supervisory authority acts against. Your provider owes you nothing under the GDPR, and the fine does not land in Rabat.
Residency, sovereignty and localisation are three different things
These three terms get used interchangeably in vendor marketing, and the confusion is expensive. They answer different questions.
| Term | What it means | What it does not mean |
|---|---|---|
| Data residency | Where the data physically sits: which country holds the disk and the backup. | It does not decide whose law applies to that data. |
| Data sovereignty | Whose law can compel disclosure, and whose courts and authorities can reach the data. | It is not the same as physical location: a provider answerable in the EU remains answerable there even for a disk in New York. |
| Data localisation | A legal requirement to keep certain data inside a given territory, common for public sector, health and financial records. | It is not a synonym for residency. Residency is where you chose to put the data; localisation is where the law makes you put it. |
A provider can truthfully claim residency in one country while the practical sovereignty question — who can access the data, and on whose order — is answered somewhere else. Ask the second question even when the first answer is satisfactory. For a provider outside the EEA the honest framing is narrower still: residency is a technical fact you can verify, sovereignty is a legal fact you have to assess, and localisation is an obligation imposed on your sector rather than a feature anybody can sell you.
Running a proportionate Transfer Impact Assessment
A TIA under the SCCs is not a form to be signed; it is a reasoned record of how you reached your conclusion. The copy-paste version — a template describing a generic third country, filed once and never opened again — is inaccurate and worthless if anyone ever asks you to justify the transfer. A proportionate one has five parts.
1. Map the transfer
Which fields of personal data leave the EEA, about whom, through which systems, and by what route. Include the channels nobody put on the diagram: access logs, backups, error trackers, support tickets.
2. Name the mechanism and the right module
The SCCs are modular. A hosting arrangement is normally controller-to-processor, while remote access by your own staff or a group company is a different module, and an inaccurate module is a common, avoidable defect.
3. Assess the destination’s law on the facts
Does that law reach your data at all, can public authorities obtain it, what redress exists, and how likely and how targeted is access in practice rather than in theory.
4. Choose supplementary measures proportionately
Encryption under your own key management, pseudonymisation, data minimisation and strict access logging are the usual ones. Say which you rely on and why, and say plainly when you rely on none because the risk in your specific case is low.
5. Document, date and review it
Record who signed off and on what facts. Re-open it when the architecture changes, the sub-processor list changes, or the categories of data you hold change.
6. Accept one legitimate short answer
If the workload holds no personal data at all — a CI runner, a build agent, staging on synthetic data — the honest conclusion is that no restricted transfer arises. That is a real conclusion, not a loophole, and it belongs in writing either way.
Support access: the transfer most buyers never map
Buyers map where the disk sits and stop there. The more useful question is who can reach the data, and from where.
If a support engineer connects to your virtual machine to investigate a fault, restores a backup that contains personal data, or reads a hypervisor log showing IP addresses and login attempts, that is access from a third country. It is a restricted transfer in its own right, and it can happen even when every disk sits inside the EEA, because an EEA host can route a ticket to a support centre outside it. That is precisely what an outsourcing-heavy support model does.
The logic runs the other way too, and this is the part that gets missed. Putting the disk in a third country does not tell you whether the access path crosses a border, and moving the disk to a country you consider safer does not remove the access path you already had. A provider whose datacentres are outside the EEA is half of the analysis; its engineers are the other half.
- Who can access production, as named roles rather than "the team".
- From which countries, including any subcontractor or outsourced helpdesk.
- Under what authentication and logging, and whether the logs are available to you.
- On whose instruction, and how a request from your side is authenticated.
- How the answer was verified rather than simply asserted in a sales call.
A supplier that cannot answer is not necessarily hiding something, but you cannot complete a TIA without those facts. If mapping your own data flows is the blocking problem, that is a piece of consulting work rather than a hosting decision, and it is worth doing before you migrate anything.
What a provider can and cannot do for you
What a provider can do
- Sign a data processing agreement that reflects Article 28 of the GDPR.
- Publish a sub-processor list and commit to notifying you before it changes.
- Describe support access honestly, including the countries its engineers work from.
- Supply the technical facts a TIA needs: regions, access paths, logging, encryption options, deletion behaviour.
- Reduce exposure structurally, for example by giving you sole control of the data so it has no reason to read anything at all.
What no provider can do
- Give you an adequacy decision, or make one arrive sooner.
- Offer EU data residency from datacentres that are not in the EU.
- Take your exporter obligation off you. It is not transferable by contract.
- Make a TIA unnecessary, or hand you a TIA that is properly yours.
- Substitute a certification, a seal or an ISO number for the transfer mechanism itself.
For providers based in the United States there is one extra check worth doing. The EU-US Data Privacy Framework confers adequacy only on organisations certified under it, and certification is granted per legal entity: it can lapse, and it does not automatically cover subsidiaries or upstream suppliers. Verify the entity on the official DPF list rather than trusting a group website.
Where OpenVista actually stands
This is where a guide like this normally turns into sales copy. We are going to do the opposite, because the honest version is more useful to you even if you end up buying somewhere else.
- We have no EU datacentre. OpenVista runs two, in Rabat, Morocco and in New York, United States. We have no facility in the EU, the UK, Canada or Australia, and we cannot offer EU data residency at any price.
- Morocco has no EU adequacy decision, for the reasons set out above. Transferring personal data to our Rabat infrastructure therefore requires a safeguard, normally SCCs plus a TIA that you produce and own.
- Our own support is itself a restricted transfer. Our engineers work from Rabat. Whenever they touch customer personal data — answering a ticket, running a restore, reading a log — that access is a transfer from the EEA to Morocco, and it is a transfer even when the workload runs on our New York node. We are not going to bury that in a sub-processor appendix.
- We are a self-managed provider. You hold root, you administer the operating system, and we do not operate your application or read its data. That model has a compliance consequence rather than a marketing one: for a workload with no personal data on it, the most defensible conclusion is often that you have nothing to assess. Where personal data is involved, that conclusion is yours to reach, not ours to sell you.
- What we will give you: a signed data processing agreement, a documented sub-processor list, and a straight written answer about who can access your machine, from where, and under what logging. Ask before you buy, and hold us to the answer.
One recommendation and one disclaimer. If your workload carries regulated or high-risk personal data — health, financial, children’s data, public sector records — an EEA or UK datacentre is almost always the proportionate answer, and we will say so on the call rather than take the order. And nothing on this page is legal advice. Your transfer position depends on your data, your role and your sector, so take advice from your own counsel or data protection adviser before you rely on any of it.
If latency is what brought you here
Both of our locations are outside the EEA, and the choice between them is a latency question rather than a compliance one. Measured round-trip times are typical figures rather than guarantees.
| Datacentre | Typical round trip | Best suited to |
|---|---|---|
| Rabat, Morocco | Madrid 20–35 ms, Paris 30–45 ms, London 40–60 ms | European and North African audiences, with the transfer work described above |
| New York, USA | New York City under 5 ms, Montréal 10–20 ms, Toronto around 14 ms | North and South American audiences, and transatlantic replication |
Latency is a good reason to pick one location over the other. It is not a reason to skip the sections above, and it is not a compliance argument in either direction.
Frequently asked questions
Does hosting with a provider outside the EEA breach the GDPR by itself?
No. A transfer to a third country is lawful when it rests on a valid mechanism: an adequacy decision, or an Article 46 safeguard such as the SCCs supported by a TIA. It becomes unlawful when no mechanism applies. The work sits with you as the exporter, which is why the answer depends on your paperwork rather than on your provider.
Do I really need a Transfer Impact Assessment for a small website?
Proportionately, yes, if personal data is transferred about anyone. A contact form, an analytics tag and server access logs all contain personal data. A short, specific TIA is enough for a low-risk workload, and a long generic one is worth less than nothing because it misdescribes what you actually do.
Can a UK customer simply use the EU SCCs?
Not on their own. The UK has its own mechanism: the International Data Transfer Agreement, or the UK Addendum appended to the EU SCCs, together with a transfer risk assessment. Most UK exporters use the Addendum so that one contract satisfies both regimes, and the destination assessment still has to be done.
Can OpenVista sign the SCCs with me?
The SCCs are a contract between the exporter and the importer, so in principle a provider signs them as importer. Whether we can, in which module, and what we attach to them is a question we will answer in writing before you buy. What we publish as standard is a signed DPA and a documented sub-processor list, and we will not tell you the SCCs are unnecessary.
Is the New York datacentre a way around the problem?
Not automatically. The United States has an adequacy decision only for organisations certified under the EU-US Data Privacy Framework, and the Rabat support access path remains whenever our engineers touch your data. Choosing New York changes the latency and the audience; it does not remove the assessment.
Work out your transfer position before you migrate
We will tell you in writing which datacentre holds your data, which countries our engineers can reach it from, and what we will and will not sign. If the answer is that you need an EU host, we will tell you that as well. Our consulting team also handles cloud migration, technical SEO and Odoo implementation if what you need first is the mapping work.