In a lot of markets, you design the architecture and check compliance at the end. Here, that order gets you in trouble.
Data residency isn’t a box you tick once the design is done. In the GCC it’s the constraint you design around from the first whiteboard. Where the data physically lives decides which regions you can use, which providers are even on the table, and which deployment model is allowed. All of that before you’ve drawn a single box.
Take Saudi. Its PDPL, enforced by SDAIA and now genuinely enforced rather than sitting on the books, doesn’t slam the door on moving personal data out. It makes you earn it: approved safeguards, plus an adequacy list of “safe” destinations that still hasn’t appeared. For sensitive and government workloads the simpler rule applies. It stays in-Kingdom. The hyperscalers read the room, which is a large part of why local cloud regions keep opening here. The market moved because the rules made it.
And it differs by country. The UAE has had a federal data law in force for years, yet some of the rules that put it into practice still aren’t published, and the financial free zones run their own regimes on top. Same region, three rulebooks, none of them quite agreeing. What’s settled for one workload in one place isn’t automatically settled next door.
The EU went through a version of this a decade ago. The GCC is doing it now, faster, and across several rulebooks rather than one.
The mistake I see: treating residency as a compliance afterthought, then discovering halfway through that the architecture you’d fallen for was never an option.
Ask it first. Where does this data have to live, and what does that rule out before we start.