The project is approved, the profiles are identified, the budget is signed off. Then someone asks the question that freezes the room: "and what about GDPR if the data goes to Morocco?"

Nine times out of ten, nobody at the table has the answer. The project doesn't stop, it slows down. It disappears into legal review for six weeks, comes back as a thirty-page document nobody reads, and the nearshore team starts with a grey area behind its back.

That's a shame, because the topic is straightforward to frame. It is in fact easier to frame than a transfer to the United States. You just have to look at both legal systems at once, not only your own.

Morocco is not an "adequate" country, and that is not a problem

Let's start with the fact that triggers the anxiety. Morocco is not on the list of countries recognised by the European Commission as offering an adequate level of protection. That list currently includes Andorra, Argentina, Brazil, Canada, the Faroe Islands, Guernsey, Israel, the Isle of Man, Japan, Jersey, New Zealand, South Korea, Switzerland, the United Kingdom, the United States and Uruguay (European Commission). Morocco is not among them.

Many executives conclude that the transfer is forbidden. It isn't. The absence of adequacy closes nothing: it simply requires you to use another GDPR instrument, in practice the standard contractual clauses adopted by the Commission, backed by a transfer impact assessment (CNIL). This is exactly what thousands of European companies do for India, the Philippines or Serbia.

And Morocco enters this discussion with an argument few offshore destinations can match: it has been a party to the Council of Europe's Convention 108, the only binding international treaty on data protection, since 1 September 2019 (Council of Europe). In other words, the country has committed to the same principles as Europe, with an independent supervisory authority on the other side.

The half of the subject French lawyers forget

Here is the most common mistake, and the one that costs the most in delay: treating the file through the GDPR lens only.

Morocco has its own law, 09-08, and its own authority, the CNDP. Processing carried out by your Moroccan entity falls under it. Outbound transfers from Morocco, in particular data flowing back to your headquarters, go through a dedicated request, form F118, which the CNDP reviews within a maximum of two months, extendable once (CNDP).

Two months. If you discover this formality on the day your team needs access to your environments, you have lost a quarter. If you start it when you incorporate the subsidiary, it is absorbed by the setup schedule and nobody notices it.

What to do, in order

The framing comes down to five points. None of them requires a six-figure law firm.

1. Map what actually moves. Most nearshore teams do not need your customers' personal data. They need code, test environments, tickets. The first question is not legal, it is technical: which data genuinely has to leave? Pseudonymising test datasets or segregating environments removes a large part of the problem before any contract is discussed.

2. Name the roles. Who is the controller, who is the processor? The answer differs radically depending on whether you work through a vendor or through your own subsidiary, and it drives all the downstream documentation.

3. Sign the right contracts. Standard contractual clauses under the correct module, an Article 28 processing agreement, security annexes describing real measures rather than boilerplate. That is a few days of work, not a few months.

4. Run the transfer impact assessment. It documents the destination country's context and the measures that compensate for the absence of adequacy: encryption, access control, logging, audit rights. For Morocco the exercise is considerably shorter than for the United States, because the local framework is aligned with Convention 108.

5. Handle the Moroccan side in parallel. Notification of processing to the CNDP, transfer authorisation where required. Start it when you set up the entity, never afterwards.

The model you choose changes the whole conversation

This is where the subject stops being legal and becomes strategic again. With a third-party vendor, you hand your data to a company you do not control, which may host other clients on the same environments, and whose security measures are imposed on you rather than negotiated with you. You audit from the outside.

With a fully owned subsidiary, the data stays inside your group. You decide the architecture, the access rights, the encryption level, the endpoint policy. The transfer becomes intragroup, compliance becomes an extension of your own rules, and the audit becomes an internal audit. That is the model we built for Ippon Technologies in Morocco in under six months, and for Financia Business School in Rabat in nine.

Compliance is not the reason to choose the subsidiary. But it is a direct consequence of it, and it carries real weight the day your enterprise client sends over its security questionnaire.

The real risk is not the one you fear

It is not the destination country. It is nearshore projects that start without a framework, where production extracts travel by email because "it was faster for debugging". That risk exists as much in Nantes as in Casablanca, and no adequacy decision protects you from it.

Frame the data flows when you build the corridor, not after the first incident. It is one of the points we systematically address when structuring a team in Morocco, alongside the employment contracts and the office. If that is where you stand, write to us.