The Cloud Computing Special Economic Zone is the odd one out among Saudi Arabia's special economic zones, and that is the most important thing to understand about it. The other three are places - a port, an industrial city, a coastline - where the question is whether your operation fits the site. This one is not primarily a site at all: the Economic Cities and Special Zones Authority designates it as a virtual special economic zone, built around cloud computing and data-centre activity rather than around land. That changes what an eligibility review actually examines, what the binding constraints are, and - crucially - which regulators you have to satisfy besides ECZA. This page sets out what the zone is for, what getting inside it involves, and how it compares with the Kingdom's other Special Economic Zones.
The Economic Cities and Special Zones Authority (ECZA) designated the Cloud Computing Special Economic Zone in 2023, alongside King Abdullah Economic City, Jazan and Ras Al-Khair. ECZA places it in Riyadh, and describes it as a zone enabling the Kingdom's digital transformation through advanced cloud computing technologies - positioned to power the Kingdom's cloud infrastructure and act as a catalyst for emerging technologies and digital innovation. Its target sector, in ECZA's own framing, is the demand for cloud computing and data centres created by the Kingdom's accelerating digital transformation, and the activity it names is the provision of cloud computing services.
The label that matters is the one ECZA puts at the top of the zone's own page: a virtual Special Economic Zone. The other three zones are bounded industrial footprints with a master developer, land allocation, quaysides and utilities. This one is designated differently, and an investor who reads it through the mental model of an industrial zone will ask the wrong questions - about land, about site allocation, about utility capacity - and miss the ones that actually decide the case.
We are going to be precise rather than expansive about what "virtual" means operationally, because this is the point where cloud SEZ commentary gets unreliable fast. ECZA designates the zone as virtual and scopes it around cloud and data-centre activity. Exactly what that permits for a specific project - where infrastructure may physically sit, how the designation attaches to an entity rather than a plot, and what the zone's perimeter means for a given deployment model - is a question for ECZA against your actual project, and it is the first thing we establish in any cloud SEZ evaluation. We do not characterise it further here, and you should treat any page that does so confidently without citing ECZA with the scepticism it deserves.
SEZ status in the Cloud Computing SEZ carries a defined incentive package covering both tax and customs treatment and a set of operational facilitations. The exact terms that apply to a given business depend on its licensed activity and how the entity is structured, and ECZA revises the package periodically. The categories below are therefore the framework we confirm against ECZA's current rules during evaluation - not a rate card that applies uniformly to every applicant, and not a set of figures you should take from any article, this one included, without confirming them against your own activity.
Two things sit in this category. The first is preferential corporate income tax treatment for qualifying activities, applied for a defined period set by ECZA rather than indefinitely. For a data-centre or cloud-platform business the modelling discipline this forces is worth stating plainly: the capital outlay is front-loaded and the revenue ramp is not, so the incentive window and the payback period have to be laid against each other rather than assumed to align - the same discipline a heavy-industrial project needs, for the same reason.
The second is customs treatment on goods brought in: relief or deferral on equipment and components, together with specific VAT treatment on transactions that stay inside the zone or move between zones. For a business whose capital expenditure is overwhelmingly imported hardware - servers, storage, networking, power and cooling plant - this is not a secondary benefit. A large data-centre build is, from a customs perspective, a very large import, and how duty and VAT are treated on it materially changes the project's funding requirement. It is also the part most often overlooked when a cloud SEZ is evaluated on its corporate-tax line alone.
Because the qualifying-activity list, the tax treatment and the customs mechanism are all set and updated by ECZA and the Zakat, Tax and Customs Authority, we confirm the current terms against your specific activity code during evaluation rather than quoting fixed numbers here.
The rest of the package is aimed at the practical obstacles to standing up a technology operation: provision for full foreign ownership across eligible activities; no restriction on repatriating capital and profits; relief from the expatriate employee levy for staff working inside the zone; and streamlined, ECZA-coordinated licensing that runs alongside rather than duplicating the standard investment-licence and Commercial Registration sequence.
The expatriate-levy point deserves emphasis here more than on the industrial zones, because of the shape of the workforce. A cloud or data-centre operation runs on a small, expensive, heavily specialised technical headcount - platform and site-reliability engineers, network and security specialists, facilities engineers - of which a substantial share is typically expatriate for the first several years. Levy relief on that population is a running operating-cost item, not a one-off, and it compounds. The specific provisions vary by activity and headcount, and we confirm them against your actual project plan rather than a general description.
ECZA scopes this zone around cloud computing and data-centre activity - in its own terms, the provision of cloud computing services, against a target sector defined by the Kingdom's demand for cloud computing and data centres.
That is a narrower perimeter than "technology", and the distinction is the single most consequential eligibility question on this page. A great deal of what a business calls "cloud" is not cloud-service provision: a SaaS application vendor, a systems integrator, an IT managed-services provider, a fintech or an e-commerce platform all run on cloud infrastructure without providing cloud computing services. Whether a given business model sits inside or outside the zone's eligible-activity list is a real question with a real answer, and it is not one to infer from the zone's name or from what other technology companies in the Kingdom are doing.
So we check your activity against ECZA's current eligible-activity list for the zone directly, before recommending it at all - and where an activity does not qualify, we say so and evaluate the alternatives rather than pushing the application through and hoping. For a technology business that turns out to sit outside the perimeter, the alternative is usually a straightforward mainland entity under the standard investment-licence route, and that is frequently the right answer rather than a consolation one.
Setting up inside the Cloud Computing SEZ carries conditions on top of the standard company-formation requirements that apply everywhere in Saudi Arabia. In broad terms, an applicant needs an activity that sits on ECZA's current eligible-activity list for the zone; a licensed Saudi entity, since most foreign-owned zone tenants still run the standard investment licence and Commercial Registration sequence with SEZ registration layered on top rather than replacing it; and the sector-specific regulatory approvals that would apply outside the zone as well.
That last clause is where this zone differs most from the other three, and it is worth stating bluntly: ECZA's perimeter is not the whole regulatory picture, and for a cloud business the part outside it is larger than the part inside. Three things sit outside ECZA and are unaffected by zone status.
Sector regulation of the activity itself. Communications, IT and cloud-services activity in the Kingdom is regulated by the Communications, Space and Technology Commission, which maintains its own framework for cloud service provision. That is a separate authorisation question from the zone, on a separate timetable, and it is frequently the item that actually sets the schedule.
Data protection and data residency. The Kingdom's Personal Data Protection Law governs how personal data is processed and can constrain where it is hosted and transferred. Zone status does not displace it. For a business whose entire value proposition is holding other organisations' data, this is not a compliance footnote - it is the product.
Your customers' own obligations. A cloud provider serving regulated Saudi customers inherits their constraints by contract. A bank, an insurer, a healthcare provider or a government entity brings residency, audit and sovereignty requirements from its own regulator that the provider must be able to satisfy and evidence, whatever the zone says.
None of this is a reason to avoid the zone. All of it is a reason to run eligibility, activity and regulatory checks before an application goes in, which is exactly the order we work in - and it is why a cloud SEZ evaluation that only talks to ECZA is an incomplete evaluation.
Timelines vary by activity, by the regulatory load outside ECZA, and by the infrastructure model, so we confirm a realistic, project-specific schedule during evaluation rather than quoting one figure that would not hold for every applicant.
The Cloud Computing SEZ is one of four zones we cover, and it is the one least comparable to the others. The table below summarizes where each zone's strength lies, in the same terms we use when we run this comparison for a client.
| Zone | Primary focus | Best fit |
|---|---|---|
| Cloud Computing SEZ | Data-hosting and cloud-services activity, designated by ECZA as a virtual zone rather than a bounded industrial site | Cloud service providers and data-centre operators - a materially different evaluation from the industrial zones below |
| King Abdullah Economic City (KAEC) | Port-anchored manufacturing, automotive and mobility, logistics and mixed-use industrial | Investors who want manufacturing, logistics, and distribution under one roof, with direct port access |
| Jazan SEZ | Food processing and FMCG, metal conversion, and logistics, anchored on a Red Sea port at the Kingdom's southern gateway | Processing, food and logistics investors whose supply chain runs through the Red Sea corridor |
| Ras Al-Khair SEZ | Maritime industries - shipbuilding and repair, rig and platform manufacturing, and MRO - inside an industrial city built around minerals and metals processing and a dedicated industrial port | Capital-intensive maritime and heavy industrial operations that need deep-water access, heavy utilities and an existing industrial supply base |
In practice this zone is not an alternative to the other three; it is a different question. KAEC and Jazan are genuine substitutes for each other for the same class of manufacturing or logistics investor. Ras Al-Khair is the maritime and heavy-industrial answer. This zone is for businesses whose product is compute and storage, and if that is not you, its incentive package is not relevant however attractive it reads. The more useful comparison for a cloud or data business is not against the other three zones at all - it is Cloud Computing SEZ against a standard mainland entity, and that is the comparison we actually run. Our wider Special Economic Zones overview covers all four side by side if the zone choice is not yet settled.
We run a Cloud Computing SEZ setup end to end rather than treating the zone registration as separate from everything around it: confirming activity eligibility against ECZA's current list, mapping the regulatory perimeter outside ECZA before anything is filed, running the investment licence and Commercial Registration sequence in parallel with SEZ registration and the incentive application, and sequencing the sector and operational registrations so the entity is licensed and compliant rather than piecemeal. Where a client is still deciding whether the zone is the right structure at all - and for technology businesses that is the majority of cases - that evaluation runs first, and we document why the alternatives were ruled out rather than simply confirming the structure the client arrived with.
There is a second half to this, and on this zone it is not a bolt-on to the advisory work - it is the reason we are a credible advisor on it at all. Every other zone in the Kingdom asks an advisory firm to understand an industry it does not operate in. This one asks about infrastructure, hosting models, data residency, integration and the architecture of systems that hold other organisations' data. That is our other business line, not an adjacent one.
Concretely, that means we are able to evaluate the things that actually decide a cloud SEZ case rather than only the things that decide the filing. Whether a hosting and deployment model satisfies the residency obligations your Saudi customers will impose on you as their provider - a question that is architectural before it is legal. How a platform serving regulated customers has to be integrated, logged and evidenced to survive those customers' own audits, which is a systems integration problem and one we are asked to solve on its own merits for clients who have nothing to do with this zone. What the data and analytics layer has to look like when residency constrains where processing may happen - the substance of our data, AI and analytics work. And, for a client who is the customer of a cloud provider rather than one themselves, whether a provider inside this zone actually changes their own compliance position or merely appears to.
We take no commission from any platform or infrastructure vendor, which is why "the zone does not improve your position, stay mainland" and "your existing architecture already satisfies this" are answers we are free to give, and regularly do. Clients are free to take the setup work and the systems work separately; the point is that on this zone, the two questions are genuinely one question, and answering only half of it well is how a cloud business ends up correctly licensed and architecturally stuck.
It is one of four special economic zones designated by the Economic Cities and Special Zones Authority (ECZA) in 2023, placed in Riyadh and built around cloud computing and data-centre activity. ECZA designates it as a virtual special economic zone rather than a bounded industrial site, and describes it as enabling the Kingdom's digital transformation through advanced cloud computing technologies.
The other three are places with a footprint, a master developer and land allocation, and a large part of setting up in them is about the site. ECZA designates this one differently and scopes it around an activity rather than a plot. What that means precisely for a given project - how the designation attaches, and what it permits for a specific deployment model - is a question for ECZA against your actual plan, and it is the first thing we establish. We deliberately do not characterise it beyond what ECZA itself publishes, and neither should anyone else.
That is the question, and the answer is less often "yes" than people expect. ECZA scopes the zone around the provision of cloud computing services and around data-centre activity. A SaaS vendor, a systems integrator, a managed-services provider, a fintech or an e-commerce platform all use cloud infrastructure without providing cloud computing services, and whether a given business model sits inside the eligible-activity list is a real question with a real answer. We check your specific activity code against ECZA's current list before recommending the zone, and where the answer is no, a standard mainland entity is usually the right structure rather than a consolation one.
A package covering preferential corporate tax treatment for qualifying activities over a defined period, customs and VAT treatment on goods in and moving between zones, provision for full foreign ownership, profit repatriation, and relief from the expatriate employee levy for staff inside the zone. We do not publish the rates or durations here on purpose. They are set and revised by ECZA, they vary by licensed activity, and an out-of-date figure on an advisory page is worse than no figure. We confirm the current terms against your specific activity with ECZA as part of the evaluation.
No, and this is the most important misconception to clear. The Kingdom's Personal Data Protection Law and the sector rules that apply to your activity sit outside ECZA's perimeter and are unaffected by zone status. So do your customers' own obligations: a bank, insurer, healthcare provider or government entity brings residency, audit and sovereignty requirements from its own regulator, and as their provider you inherit them by contract. Zone status is a tax, customs and licensing regime. Residency is an architectural and regulatory question, and it needs answering on its own terms.
Yes. SEZ status is an incentive layer applied to a licensed Saudi entity, not a replacement for the standard formation sequence - most zone tenants hold an investment licence and Commercial Registration in the ordinary way, with SEZ registration and its terms applied on top.
For a cloud or data-centre business the other three are not real alternatives, and for anyone else this one is not. The comparison actually worth running is this zone against a standard mainland entity - and where the incentive package does not apply cleanly to your activity, or the regulatory load outside ECZA dominates the case, mainland is frequently the better answer. We run that comparison and document why the option we ruled out was ruled out.
It depends on the activity, on the regulatory load outside ECZA - sector authorisation and data-protection obligations in particular - and on the infrastructure model. For a data-centre build it is usually the infrastructure and the sector approvals, not the SEZ licence, that set the real schedule. We confirm a realistic, project-specific timeline during evaluation rather than quoting one figure that would not hold for every applicant.
The heading promises facts and figures, so here is an honest answer rather than a manufactured one: we do not publish a placeholder statistic to fill the space a track-record section is expected to occupy. An unverifiable figure in an advisor's own marketing is exactly the kind of claim a serious technology investor should discount, including when it is ours, so we hold our own copy to that standard. The real record is the set of documented engagements on our Success stories page, updated as new engagements are completed and cleared for publication, rather than a summary figure standing in for it.
The organizations that bring us cloud SEZ work tend to be international cloud and hosting providers evaluating a Saudi presence, data-centre developers and operators assessing the licensing and incentive position, and technology businesses that need a straight answer on whether their model qualifies at all before they build a plan around it. Rather than listing names on this page ahead of their own confirmation to be featured, we maintain the current, permissioned list on our customers page and update it as new relationships are cleared for publication.
Specific engagements - the activity, the eligibility outcome, the licence obtained and the architecture and residency position agreed - are documented individually rather than summarized here, both because each project has its own shape and because publishing project detail requires the client's clearance first. Our projects page carries the engagements cleared for public reference, including cloud and data-centre work as it becomes available to share.
We do not publish a client quote until the client has reviewed and approved the exact wording attributed to them, so this section will carry real, attributed testimonials as those approvals come in, rather than a composite or paraphrased quote standing in for one now. If a specific reference matters to your own decision, raise it during the initial evaluation call and we will connect you with a comparable past client where confidentiality allows.
This work rests on two things. On the advisory side, standing relationships with the legal, data-protection and zone-liaison specialists that ECZA's and the sector regulator's processes actually depend on. On the systems side, a vendor-neutral position across the cloud, infrastructure, integration and data platforms we evaluate - which on this zone in particular is a credential only if we can show we are not being paid to prefer one, since the obvious conflict for an advisor recommending a cloud zone is an arrangement with a cloud vendor. We list our accreditations and professional partnerships, alongside our wider technology partner network, on our partners page, and disclose any partnership specifically relevant to a client's evaluation as part of that engagement rather than as a general credential here.
If the zone itself is not yet settled, our Special Economic Zones overview covers all four zones side by side and is the better starting point than this page. If this zone is settled, two things are worth reading alongside it: the standard Company formation in Saudi Arabia sequence, since every zone entity still runs through it and the zone registration is not the whole process; and the architecture, integration and data questions that decide whether the entity you license can actually serve the customers you intend to serve - starting with systems integration and data, AI and analytics.
If the Cloud Computing SEZ is on your shortlist, Book a decision session and we will tell you plainly whether your activity qualifies, what the incentive package actually covers in your case, which regulators outside ECZA you still have to satisfy, and what your hosting and residency position has to look like to serve the customers you are targeting - including if our honest answer is that a standard mainland entity serves you better than the zone does.