Sovereignty. In the Gulf

Gulf 2026

There is something fascinating happening in the Gulf. The ambition is enormous.

The UAE, Saudi Arabia and other countries in the region are investing heavily in digital infrastructure, cloud computing, cybersecurity, artificial intelligence and digital government. Technology is not treated simply as another IT budget line. It has become part of a much broader economic and national transformation.

And sovereignty has naturally become part of that conversation. It is not difficult to understand why.

The Gulf has spent decades building an economy deeply connected to the outside world. Its digital economy is no different. Global technology companies have brought infrastructure, platforms, expertise and investment into the region, and the availability of local cloud regions has made it possible to run increasingly important workloads close to where the organisations and their customers actually are.

Reality has always a habit of making these discussions rather less theoretical. And the threat landscape is becoming more complicated at precisely the moment when the Gulf is becoming more digitally ambitious.

A report published by Dark Reading this week, citing research from Positive Technologies and Check Point, puts the UAE and Saudi Arabia together at roughly half of all cyberattacks recorded across the Gulf during the first half of 2026. The same reporting points to a shift away from the highly visible attacks we have become used to – DDoS attacks and website defacements – towards more targeted intrusions, persistence and data gathering.

This is important because digital transformation has a slightly inconvenient side effect: it creates more things worth attacking.

In April, Security Affairs reported that the Iran-linked group Handala claimed to have breached three major UAE organisations: Dubai Courts, the Dubai Land Department and the Roads and Transport Authority. The group claimed to have destroyed and stolen very large volumes of data. What matters here is not whether every number in the claim was accurate, but that a major cyberattack was publicly claimed against organisations responsible for important public services in the UAE.

As already mentioned earlier, in September, Amazon Web Services was still unable to restore access to its Bahrain infrastructure and to one of three availability zones in the UAE after damage caused during the US-Iran war.

One incident concerns a claimed cyber intrusion, while the other concerns physical disruption of cloud infrastructure. All are simply a rather powerful real-life example of the problem the Gulf is now trying to solve.

When the real world arrives

The UAE has been building a fairly sophisticated policy framework around cloud security. Its National Cloud Security Policy does not only talk about data location and sovereignty. It also addresses interoperability and portability, cloud resilience, supply-chain security and operational sovereignty.

Saudi Arabia has taken its own route. Its Cloud First Policy makes cloud solutions a priority for government IT investments and positions the National Information Center’s Deem Cloud as a national government cloud platform.

Bahrain has been pursuing cloud adoption for years as well. Its Cloud First Policy made cloud computing part of public-sector IT planning, and back in 2017 the Kingdom engaged AWS as its official cloud infrastructure provider for the public sector. None of this is particularly surprising. The Gulf needs digital infrastructure, and it needs it at scale. What is interesting is what happens when the policy ambition meets an event that nobody put into the original spreadsheet.

There is, of course, another important dimension to this discussion: the potential reach of foreign legislation, including the US CLOUD Act. We leave that question aside for now. It deserves a separate discussion because it takes us from the physical and architectural location of data into the much more complicated territory of jurisdiction, legal access and control.

A cloud region can be physically present in the country and still become unavailable. Suddenly, sovereignty is no longer a policy concept. It is an operational problem. And this is where things become particularly interesting. Because in my daily work, I see sovereignty arriving in a much less glamorous form.

In an Excel spreadsheet.

The sovereignty questionnaire

The place where the sovereignty discussion becomes particularly interesting is the RFI.

In my daily work, my team and I regularly respond to Requests for Information. If you have never seen one of these, imagine an Excel file with several tabs covering technical requirements, compliance, infrastructure, security, disaster recovery, data residency and probably a few other things.

Some of them contain several hundred questions, but there is nothing inherently wrong with that. Complex organisations have complex requirements. Financial institutions, governments and other highly regulated organisations need to understand what they are buying, where the risks are and whether their suppliers can meet their obligations.

There is an interesting trend in these questionnaires.

Sometimes the questionnaire starts becoming a substitute for understanding the actual use case. Instead of starting with what are we trying to achieve, and what could go wrong, they start with what does every applicable regulation, internal policy, security framework and procurement requirement allow us to ask. And then we ask all of it.

The result can be quite spectacular. Data residency gets mixed with sovereignty. Cloud deployments get mixed with on-premise deployments. Technical capabilities get mixed with organisational policies. And, of course, there are certificates. Lots of certificates! Sometimes even certificates for things that, rather surprisingly, do not have certificates.

I’m not complaining. Actually, I find the whole thing fascinating. Because it shows how difficult sovereignty becomes when it moves from a concept into an Excel spreadsheet.

Recently, we were responding to an RFI from a high-profile financial institution. One of the questions looked perfectly straightforward: Does the platform natively support UAE PASS for identity verification?

The answer was simple: Yes. Then came the next question. What about a foreigner who does not have an Emirates ID? And suddenly the answer became: No. There is an important distinction here. A foreigner can register for a UAE PASS account using a passport. But registration is not the same thing as having a fully verified UAE PASS identity that can be used for regulated financial KYC.

For a non-resident who has never entered the UAE and therefore cannot complete the required identity verification, the existence of a UAE PASS account does not turn the person into a verified UAE digital identity holder. And that matters. The financial institution wasn’t asking whether a foreigner could download UAE PASS or create an account. It was asking whether it could use our native UAE PASS integration to perform KYC verification of a foreign customer.

Both answers are correct but the difference is the use case.

Solution across multiple jurisdictions

For this particular use case, our platform has a built-in integration with one of the leading KYC providers. The customer can submit the required identity information and documents, the KYC process takes place through that service, and our platform receives the verification result.

Then came the sovereignty question. Where is the verification data stored? And, more specifically: Why isn’t it stored in the UAE?

At first glance, this sounds like an entirely reasonable sovereignty question. But there is another question hiding behind it. Why does the verification data need to enter the country at all?

This is where architecture matters more than geography.

Our platform is hosted in the UAE, among many other locations, and can also be deployed on-premise or in a private cloud. The KYC engine, however, is hosted in the EU, and that is deliberate. GDPR, eIDAS and the surrounding European regulatory environment are part of the reason for that architecture. The identity documents, photographs, selfies and other sensitive verification data can remain within that environment. What comes back to the UAE is the result of the verification.

The financial institution needs to know whether the person has been successfully verified. It does not necessarily need to receive a copy of every piece of raw identity data used to perform that verification. And it certainly doesn’t have to access it directly in the UAE.

That distinction changes the sovereignty discussion.

We are no longer asking whether we can keep every byte in the country. We are asking which data needs to go where, for what purpose, under whose responsibility, and with what risk.

Those are much better questions.

There is a temptation in sovereignty discussions to assume that local storage is automatically safer. Sometimes it is, and sometimes it isn’t. In this particular case, moving the identity documents between jurisdictions would not make the identity verification more sovereign. The verification still needs to happen somewhere, and the sensitive source data can remain within the external environment where the KYC engine operates.

The architecture therefore separates two things that are often treated as one: the verification process and the verification result.

And that separation can matter a great deal.

The sovereignty trapped in Excel

This is where I think the sovereignty discussion sometimes gets trapped by the questionnaire. We start measuring sovereignty by counting how many requirements we have satisfied rather than by asking whether the architecture actually reduces the relevant risks.

The spreadsheet gets bigger. The number of requested certificates gets bigger. The number of “yes/no” answers gets bigger. And somehow the understanding of the actual system can get smaller.

If the purpose is to verify the identity of a foreign customer, moving all of the underlying identity documents into the UAE simply because the customer is being onboarded by a UAE institution may create additional data movement without creating any additional sovereignty. In fact, it can create another risk – you have moved data that did not need to move.

This is not an argument against questionnaires. Quite the opposite. A good questionnaire forces everyone to think about things that are easy to overlook.

Sovereignty cannot be established by the number of questions answered “yes”. It is not achieved simply because every piece of data is stored locally. And it certainly isn’t achieved by putting the word sovereign next to every component in an architecture diagram.

Sovereignty requires understanding the use case and understanding the data flows. Understanding where the data actually needs to travel. Understanding the legal and operational environment. Understanding the dependencies between the different parties. Understanding what happens when something fails. And understanding what alternatives exist when circumstances change.

In other words, sovereignty is not about making everything local. It is about knowing what you control, what you depend on, why you depend on it, and whether you still have meaningful choices when something changes.

Sometimes the most sovereign architecture may therefore be the one that keeps sensitive data out of a particular country. Which is a slightly uncomfortable conclusion to reach while filling in a 650-question spreadsheet about data residency.

But perhaps that is precisely the point.

The Gulf has a real problem to solve

This is not an argument that the Gulf’s sovereignty ambitions are misguided; quite the opposite. The region has very real reasons to think about resilience, jurisdiction, infrastructure and strategic dependency.

Saudi Arabia’s Cloud First Policy, for example, is explicitly part of the country’s wider digital transformation agenda and requires government entities to consider cloud solutions as a priority for new IT investments. Bahrain has similarly made cloud adoption part of its public-sector technology strategy, while its government describes cloud computing as a way of improving security, productivity and public services. And the UAE’s current cloud security policy is arguably the clearest illustration of how broad the subject has become. Data location and sovereignty sit alongside portability, resilience, supply-chain security and operational sovereignty.

These are all legitimate things to think about. The 2026 incidents simply make the discussion much more tangible.

The Gulf is not discussing sovereignty as an abstract European policy exercise. It is building infrastructure, regulating it, operating it and, increasingly, discovering what happens when that infrastructure is tested by events outside the assumptions of normal operations.

That makes the quality of the decisions being made now particularly important. And this is where my 650-question Excel file comes back into the story.

When sovereignty becomes a checklist

There is a certain irony in trying to prove sovereignty through a questionnaire. The more complicated the concept becomes, the more tempting it is to turn it into a checklist. The problem is that a checklist can tell us whether a particular condition has been met. It cannot tell us whether that condition was relevant in the first place.

The KYC example I brought up is a good illustration. The objective should not be to make every piece of data local simply because locality is easy to measure or it gives you false feeling you control it better when it’s nearby.

The objective should be to understand the use case well enough to decide what actually needs to be local, what can remain elsewhere, what dependencies are acceptable and what risks the organisation is actually trying to address.

That is considerably harder to put into an Excel cell.

Education, education, and (once again) education

I suspect this is one of the biggest challenges for the Gulf as it moves forward. And maybe also relevant for other regions. Regions have the ambition. They have the investment. They have increasingly sophisticated infrastructure and increasingly detailed regulatory frameworks.

What they now need is the ability to distinguish between the appearance of sovereignty and the substance of sovereignty. That requires more than compliance expertise. It requires architectural understanding. It requires understanding the actual business use case. It requires understanding where the real dependencies are.

And perhaps most importantly, it requires asking a slightly uncomfortable question before adding another requirement to the spreadsheet – what problem are we actually trying to solve?

Sometimes the answer will be that the data absolutely must remain in the country. Sometimes it will be that the service needs to be operated by a locally controlled entity. Sometimes the answer will be that a second region is more important than a local one. Sometimes the right solution will involve processing sensitive data somewhere else and bringing only the result back.

And sometimes the answer may simply be that the requirement doesn’t make sense. That last answer is probably the hardest one to put into a procurement document. But it may also be the most valuable.

The Gulf is moving quickly towards a more sovereign digital infrastructure. The question is not whether it should, but how it will define what sovereignty means while it is building it.

Because sovereignty is not made by putting more boxes into an Excel spreadsheet. And it is certainly not made by making every box say “local”.

It is made by understanding the system well enough to know which boxes actually matter.

And perhaps that is the difference between building sovereign technology and simply building technology that looks sovereign on paper.