The question that GCC technology leaders are asking in 2026 has changed. A year ago, it was “should we move to cloud?” Today, it is “where does our data actually live, is that legal, and can we prove it?”
The shift is not rhetorical. It is regulatory. Saudi Arabia’s Personal Data Protection Law has been in active enforcement since September 2024 — SDAIA issued 48 enforcement decisions in 2025 and 2026. The NCA’s Cloud Cybersecurity Controls require data residency to be technically enforced, not merely contractually stated. The UAE launched the world’s first sovereign financial cloud infrastructure on February 25, 2026 — a dedicated environment developed by Core42 and G42 for UAE Central Bank-regulated entities whose data cannot leave UAE jurisdiction by design. Saudi Arabia’s HUMAIN secured SAR 4.5 billion in financing in January 2026 for sovereign AI infrastructure — explicitly to ensure that data processing and intellectual property remain within Saudi borders.
These are not future developments. They are the operating environment of every large enterprise in the GCC and Egypt right now. And the architecture decisions that determine whether an organisation’s ERP, EPM, BI, automation, and HR data is genuinely compliant with these requirements — as opposed to contractually compliant on paper while technically non-compliant in practice — are not made by choosing the right cloud provider. They are made at the level of data classification, integration design, key management, access controls, and audit trail architecture.
Most GCC enterprises have made the right provider choice. Most have not completed the architecture work that makes compliance real.
This guide covers what sovereign cloud and data architecture compliance actually requires for GCC and Egyptian enterprises in 2026 — from the regulatory frameworks that define the obligations, through the specific architecture dimensions that determine whether those obligations are met, to the decisions that CIOs, CFOs, and boards need to make about their ERP, EPM, BI, and automation data environments.
The Regulatory Landscape: What “Data Must Stay in the Kingdom” Actually Means
Saudi Arabia: Three Overlapping Frameworks
Saudi Arabia in 2026 operates three distinct data governance frameworks that affect enterprise data architecture simultaneously. Understanding each — and where they overlap — is the starting point for any architecture design intended to meet Saudi data compliance requirements.
Saudi Personal Data Protection Law (PDPL) Administered by SDAIA (the Saudi Authority for Data and Artificial Intelligence), PDPL has been fully enforceable since September 2024. The law applies to any processing of personal data relating to individuals in the Kingdom — regardless of where the processing organisation is incorporated. For a UAE-headquartered GCC group processing Saudi employee and customer data, PDPL applies.
The data residency requirement under PDPL: personal data may only be transferred outside the Kingdom if the destination country provides an equivalent level of protection, if the transfer is covered by an approved transfer mechanism, or if the data subject’s explicit consent has been obtained. For enterprise systems processing Saudi employee payroll, Saudi customer records, or Saudi operational data, the practical implication is that this data must be hosted in Saudi Arabia unless a specific approved transfer framework is in place.
What PDPL does not specify is the technical architecture that achieves residency — it specifies the outcome (data does not leave the Kingdom without a lawful basis) and the organisation must demonstrate that the architecture reliably produces that outcome. Selecting an Azure or OCI Saudi Arabia region does not, by itself, achieve PDPL compliance — if the application logs, the backup copies, the integration middleware, or the analytical data derived from personal records are routed to a non-Saudi region, the personal data has left the Kingdom.
NCA Essential Cybersecurity Controls (ECC 2-2024) The National Cybersecurity Authority’s Essential Cybersecurity Controls were updated in 2024 and apply to all government entities and critical national infrastructure operators in Saudi Arabia, with significant overlap with the private sector through supply chain obligations. The NCA’s Cloud Cybersecurity Controls, a specific subset of the ECC, require that:
Data hosted in cloud environments is classified according to the NCA’s data classification framework — National, Confidential, Restricted, Public — before cloud deployment decisions are made. Cloud provider selection must be based on NCA cloud service provider authorisation status — not all cloud providers with a Saudi region are NCA-authorised for all data classification levels. Workloads handling Confidential or National-classified data face more restrictive hosting requirements than those handling Restricted or Public data.
The distinction between NCA authorisation and commercial availability is material: a cloud provider with a Saudi Arabia data centre that is not NCA-authorised for Confidential data classification is not a compliant hosting environment for that classification level, regardless of its data residency commitment.
SAMA Cybersecurity Framework The Saudi Central Bank’s cybersecurity framework applies to all SAMA-licensed entities — banks, insurance companies, financing companies, payment service providers. The SAMA framework’s cloud-specific requirements extend beyond general PDPL and NCA obligations with financial sector-specific controls: cloud providers must demonstrate specific cybersecurity certifications, data classification applies additional financial data sensitivity tiers, and audit access to cloud-hosted systems must be contractually guaranteed and practically accessible to SAMA examiners.
The convergence of PDPL, NCA, and SAMA for a SAMA-regulated Saudi financial institution running Oracle EPM, a BI platform, and RPA automation on cloud infrastructure means three overlapping compliance frameworks must be satisfied simultaneously — and the architecture must demonstrably satisfy all three, not just the most permissive one.
UAE: The Sovereign Financial Cloud and Federal Data Protection
UAE Federal Data Protection Law and Sector Frameworks The UAE Federal Decree-Law No. 45 of 2021 on Personal Data Protection applies to personal data processing in the UAE. It operates alongside sector-specific frameworks — the UAE Central Bank’s requirements, DIFC’s data protection framework (Reg 1 of 2007, updated), ADGM’s framework — creating a layered data protection obligation that varies by sector and by free zone.
The UAE Central Bank’s New Law (Federal Decree-Law No. 6 of 2025) came into force in September 2025 with a one-year regularisation deadline for financial institutions — placing UAE financial institution data architecture compliance in active scope for every UAE-licensed bank, insurance company, and payment service provider through September 2026.
The World’s First Sovereign Financial Cloud (February 2026) On February 25, 2026, the UAE Central Bank launched the world’s first sovereign financial cloud infrastructure — developed by Core42 (a G42 company) as a dedicated cloud environment for UAE Central Bank-regulated entities. This infrastructure is explicitly designed so that financial data remains within UAE jurisdiction at the infrastructure layer, not just at the contractual layer. UAE financial institutions considering cloud migration for core banking, financial reporting, and analytics workloads now have a regulatory-endorsed sovereign hosting option that is specifically designed for the CBUAE compliance environment.
For UAE financial institutions, this sovereign cloud is not mandatory — but its existence signals the CBUAE’s direction of travel: regulated financial data belongs in UAE-controlled infrastructure, and the regulatory framework will progressively tighten around this principle.
Egypt: Data Protection Law and ETA Compliance
Egypt’s Data Protection Law No. 151 of 2020 and its executive regulations apply to personal data processing in Egypt. For large Egyptian enterprises, the data residency implications are less prescriptive than Saudi PDPL but the ETA e-invoicing mandate creates a specific data integration requirement: invoice data submitted to the Egyptian Tax Authority must be routed through ETA-approved integration channels with specific security and audit trail requirements.
For GCC groups with Egyptian subsidiaries, the Egyptian data protection obligations add a third data residency consideration alongside Saudi PDPL and UAE data protection — each requiring the Egyptian entity’s personal data to be assessed against the data protection standard applicable to its jurisdiction.
What “Sovereign Cloud Compliance” Requires in Practice
The most important insight from the 2025–2026 Saudi and UAE enforcement actions is this: choosing a cloud provider with a Saudi Arabia or UAE data centre is the starting point for compliance, not the conclusion.
The architecture running on that infrastructure is where compliance is actually achieved or broken. The following dimensions determine whether an enterprise’s cloud deployment genuinely satisfies PDPL, NCA, and SAMA requirements — or satisfies them on paper while failing them in technical practice.
Dimension 1: Data Classification at the Application Layer
Compliance begins with knowing what data you have and what classification it falls under. This is not a cloud provider responsibility — it is an enterprise architecture responsibility.
Most GCC enterprises that have migrated to cloud have made data residency commitments at the infrastructure level (hosting in a Saudi or UAE region) without completing data classification at the application layer. The result: data that is physically in the right country but not classified and protected according to the sensitivity of its content.
A complete data classification exercise for a GCC enterprise with Oracle ERP, Oracle EPM, a BI platform, and payroll automation must classify every data element in each system — identifying which fields contain personal data (employee records, customer records, national IDs, salary data), which contain financial institution data subject to SAMA, and which contain operational data that is not personal but may be subject to sectoral data protection requirements (contracts, pricing, supplier records).
The classification output defines: which data must stay in Saudi Arabia, which must stay in the UAE, which may be processed cross-border under an approved framework, and which has no data residency constraint. This output is the architectural specification for every subsequent cloud and integration design decision.
Dimension 2: Integration Flows and Data Transit
The most consistently missed compliance risk in GCC cloud architectures is not where the primary data is hosted — it is where the data goes when it moves between systems.
Every enterprise application environment involves data movement: ERP actuals feed EPM; EPM outputs feed BI; payroll data feeds HRMS; HRMS feeds Oracle EPM Workforce Planning; AP automation reads ERP invoices and writes to ERP journals; BI reads from the data warehouse and writes to user devices. Each of these data flows is a potential data residency violation if the integration middleware, the API gateway, the data pipeline, or the intermediate storage layer is hosted outside the required jurisdiction.
Common integration architecture risks in GCC enterprise cloud deployments:
Azure Integration Services hosted in a non-GCC region: An enterprise hosts Oracle ERP on OCI Jeddah and Power BI on Azure UAE North — both in compliant regions. The Azure Integration Services pipeline that moves ERP data to the Power BI data model is configured to run in Azure West Europe (the integration service’s default region for the Middle East configuration at the time of setup). Saudi PDPL data transits through Europe at every data refresh cycle. The residency violation is in the integration layer, not in the primary hosting.
Backup and disaster recovery in a different jurisdiction: The primary Oracle ERP database is in OCI Jeddah. The automated backup is configured to replicate to OCI Frankfurt for disaster recovery — the default DR region at the time the backup was configured. Saudi PDPL personal data is in Germany at every backup cycle. The residency violation is in the backup architecture, not in the primary hosting.
Log aggregation outside the jurisdiction: Application logs from Saudi-hosted systems are routed to a global SIEM (Security Information and Event Management) platform with a data centre in the United States. The logs contain IP addresses, user identities, and access timestamps that are personal data under PDPL. The residency violation is in the security monitoring layer.
AI inference in a non-compliant region: An Oracle EPM AI feature (Predictive Planning or Planning Agent) triggers an inference call to an AI model hosted outside Saudi Arabia. The inference request may include EPM data that contains personal financial information. The data transit is not through a PDPL-approved mechanism.
Dimension 3: Key Management and Encryption Architecture
NCA and SAMA both require that encryption keys for sensitive data are not held exclusively by the cloud provider. This is the Customer-Managed Keys (CMK) requirement — the enterprise must hold encryption keys in a Hardware Security Module (HSM) that is within Saudi Arabia or UAE jurisdiction, so that the cloud provider cannot decrypt the enterprise’s data without the enterprise’s explicit involvement.
Most cloud providers offer CMK capability — Azure Key Vault, AWS KMS with custom key stores, OCI Vault with external key management. The requirement is that these key management services are configured to use an HSM instance in the correct jurisdiction, and that the key rotation, access controls, and audit logging for the key management service are documented and accessible to NCA or SAMA examiners.
For enterprises running Oracle EPM or an ERP on cloud infrastructure in Saudi Arabia or UAE, the encryption key management architecture should be reviewed as a specific compliance item — confirming that the data encryption at rest uses customer-managed keys held in the correct jurisdiction, and that the key management audit trail is complete and accessible.
Dimension 4: Access Controls and Privileged Access Management
NCA ECC 2-2024 requires that access to sensitive data is controlled through documented access management processes — including privileged access management (PAM) for administrator-level access to cloud infrastructure. The specific requirements relevant to enterprise application architecture:
Cloud infrastructure administrators who can access systems hosting Saudi personal data or SAMA-regulated financial data must be identified, authorised, and logged. Vendor access — including the cloud provider’s own support and operations teams — must be governed through a documented process that limits access to what is required for the specific support task. For SAMA-regulated entities, vendor access to production financial data systems requires specific contractual controls and the ability to grant and revoke access on demand.
For Oracle EPM users on OCI: Oracle’s support model allows Oracle support staff to access OCI infrastructure for issue resolution. For Saudi Arabia PDPL and SAMA compliance, this vendor access must be governed through Oracle’s Customer-Controlled Access (also known as Break Glass access) mechanism, which requires the customer’s explicit approval before Oracle support can access the customer’s data. This mechanism must be explicitly configured — it is not the default Oracle support model.
Dimension 5: Audit Trail Architecture
PDPL, NCA, and SAMA all require audit trails that record who accessed what data, when, from where, and for what stated purpose. The audit trail must be:
- Complete: Every access to personal or sensitive data is logged — including system-to-system API access, not just human user access
- Immutable: The audit log cannot be modified or deleted by anyone — including administrators
- Retained: The log is retained for the period specified by the applicable framework (PDPL requires retention consistent with the processing purpose; SAMA specifies minimum retention periods)
- Accessible to regulators: SDAIA, NCA, or SAMA examiners can access the audit log on demand, in a format they can review without requiring the enterprise to build a custom report
For enterprise applications running on cloud infrastructure, the audit trail architecture must cover: the application-level access logs (who logged into Oracle EPM, what they accessed, what they changed), the infrastructure-level access logs (who accessed the OCI tenancy, what API calls were made), the integration layer logs (what data moved between systems, when, through which pipeline), and the key management logs (when encryption keys were accessed, by which process).
The Oracle EPM and ERP Data Residency Architecture
For GCC enterprises running Oracle Cloud EPM — Planning (PBCS/EPBCS), FCCS, ARCS, PCMCS, or TRCS — alongside Oracle Fusion ERP or Oracle EBS, the data residency architecture involves specific choices that determine PDPL and NCA compliance.
Oracle Cloud Infrastructure (OCI) Middle East Regions Oracle operates OCI regions in Jeddah (Saudi Arabia) and Abu Dhabi/Dubai (UAE). These regions provide:
- Saudi Arabia: OCI Jeddah — the primary residency option for Saudi PDPL compliance
- UAE: OCI UAE East (Dubai) and OCI UAE West (Abu Dhabi) — for UAE data protection compliance
For Oracle EPM users, deploying on OCI Jeddah (Saudi Arabia) or OCI UAE (UAE) satisfies the primary hosting residency requirement for Saudi and UAE personal data. The additional architecture dimensions described above — integration flows, backup, key management, access controls, audit trail — must be configured explicitly.
OCI Architecture for Saudi PDPL + NCA Compliance A Saudi enterprise running Oracle EPM on OCI must configure: OCI Jeddah as the primary tenancy region; OCI Jeddah as the backup and DR region (not OCI Frankfurt or any non-Saudi region); Oracle Key Management Service with customer-managed keys in OCI Jeddah Vault; Oracle Data Safe for database audit trail and access controls; Oracle Customer-Controlled Access (break glass) for Oracle support access governance; and Oracle Integration Cloud running in OCI Jeddah for all integrations between Oracle EPM, Oracle ERP, and third-party systems.
The Oracle Integration Cloud (OIC) point is frequently missed: organisations that deploy Oracle EPM and Oracle ERP in OCI Jeddah but route their integration middleware through Oracle Integration Cloud in a non-Saudi region are creating a data transit path outside the Kingdom at every integration cycle.
Microsoft Azure Architecture for Power BI and Fabric (Saudi Arabia) Microsoft’s Azure Saudi Arabia East region (Jeddah) is confirmed for availability in Q4 2026. Until that region is live, Saudi Arabia-based Microsoft deployments use Azure Saudi Arabia West (Dammam), which is in active use for Microsoft 365 and is the designated Saudi PDPL data residency region for Microsoft services under the Microsoft Data Boundary for the EU and equivalent mechanism.
For Power BI and Microsoft Fabric deployments serving Saudi users with Saudi personal data, the Azure Saudi region provides the primary data residency. The Microsoft Fabric data integration, backup, and log data must also be configured to remain in the Saudi region — not in the default Azure North Europe or West Europe regions that Fabric uses as global defaults.
The Five Most Costly Data Architecture Compliance Failures in the GCC
1. The Data Was in Saudi Arabia but the Backup Was in Ireland
A Saudi financial institution migrated its Oracle ERP to OCI Jeddah in 2024, completing the primary data residency requirement. The automated backup policy was configured to replicate to OCI Frankfurt — the global default DR region at the time of migration. The SDAIA compliance audit in Q1 2026 identified that nightly backup copies of the ERP database, containing employee records and customer financial data, had been replicating to Germany for eighteen months. The remediation required reconfiguring the backup policy, deleting the Frankfurt copies under a documented process, and producing evidence to SDAIA that the violation had been remediated. The compliance process took eleven weeks.
2. The Integration Pipeline Was in Azure West Europe
A UAE banking group ran Oracle EPM on OCI Dubai and Power BI on Azure UAE North — both in compliant UAE regions. The Azure Data Factory pipeline that moved Oracle EPM data to the Power BI data model had been configured to run in Azure West Europe by the implementation team, which was operating from Europe and used their standard regional configuration. UAE Central Bank-regulated financial data was transiting through Europe at every overnight data refresh. The CBUAE compliance review identified the transit path eight months after go-live. Reconfiguring the Data Factory to run in Azure UAE North required a pipeline rebuild that took six weeks.
3. Oracle Support Had Unrestricted Access to Production Data
A SAMA-regulated Saudi bank ran Oracle Fusion ERP and Oracle FCCS on OCI Jeddah. The Oracle support access model was the standard Oracle model — Oracle support staff could access the customer’s OCI tenancy for issue resolution through Oracle’s internal tooling without the customer’s prior approval for each access instance. The SAMA examination identified this as a violation of the SAMA framework’s vendor access control requirement: access to production financial data by external parties must require explicit customer authorisation for each instance. The remediation — enabling Oracle Customer-Controlled Access and documenting the access governance process — took four weeks.
4. Data Classification Was Never Completed and Everything Was Treated as Public
A Saudi conglomerate migrated its enterprise applications to OCI Jeddah and Azure Saudi Arabia, satisfying the primary data residency requirement. No formal data classification exercise was conducted. All data in all systems was treated as equivalent — the same access controls, the same audit logging, the same integration permissions for all data regardless of its sensitivity. The NCA audit found that employee payroll records (National-classified personal data), customer contract records (Confidential), and general operational records (Restricted and Public) were all subject to the same access controls — which met the Restricted standard but not the Confidential or National standard. The data classification and access control remediation programme took five months.
5. The EPM Planning Data Was Mixed With Oracle Support Telemetry Sent to the US
A GCC enterprise running Oracle Cloud EPM on OCI Jeddah had not reviewed Oracle’s telemetry configuration. Oracle Cloud services generate operational telemetry — performance metrics, error logs, usage statistics — that is routed to Oracle’s global telemetry infrastructure by default. Some of this telemetry may include data derived from the customer’s EPM environment. For Saudi enterprises subject to PDPL, any personal data included in telemetry that routes to non-Saudi infrastructure is a potential PDPL transfer. The resolution — reviewing Oracle’s telemetry documentation, identifying which telemetry streams include customer-derived data, and configuring the applicable data residency controls — required a three-week technical review.
The Cloud Architecture Compliance Assessment: What It Covers
A structured cloud architecture compliance assessment for a GCC enterprise covers:
Data inventory and classification: What data exists in each enterprise system (Oracle EPM, Oracle ERP, Power BI, payroll system, HR system, automation platforms), what classification it carries under PDPL/NCA/SAMA, and which jurisdictional data residency requirement applies to each data category.
Hosting architecture review: Where each application is hosted (cloud provider, region, availability zone), whether the hosting satisfies the data residency requirement for the data classification of the data it processes, and whether the backup and DR configuration maintains the same data residency as the primary.
Integration flow mapping: Every data integration between systems — what data moves, when, through which middleware, in which region, and whether the integration path maintains PDPL/NCA compliance for the data classification of the data in transit.
Key management review: Whether customer-managed keys are in use for sensitive data, where the HSM is located, whether the key rotation and access controls meet NCA and SAMA requirements, and whether the key management audit trail is complete.
Access control review: Whether privileged access to systems hosting sensitive data is governed through a documented PAM process, whether vendor access (including Oracle, Microsoft, or AWS support access) requires customer approval per-instance, and whether the access control audit trail meets NCA requirements.
Audit trail completeness: Whether the audit trail covers application, infrastructure, integration, and key management layers; whether it is immutable and retained for the required period; and whether it is accessible to SDAIA, NCA, or SAMA examiners without custom development.
| Assessment Component | Typical Timeline | Professional Services (USD) |
|---|---|---|
| Data classification exercise (all enterprise systems) | 3–5 weeks | 18,000–45,000 |
| Cloud architecture compliance review (hosting + integration + backup) | 3–5 weeks | 15,000–40,000 |
| Integration flow mapping and residency analysis | 2–4 weeks | 12,000–30,000 |
| Key management architecture review and configuration | 2–3 weeks | 10,000–25,000 |
| Access control and PAM review | 2–3 weeks | 10,000–25,000 |
| Audit trail completeness assessment | 2–3 weeks | 10,000–22,000 |
| Full architecture compliance assessment (all components) | 8–14 weeks | 55,000–150,000 |
| Architecture remediation programme (post-assessment) | 10–24 weeks | 80,000–250,000 |
A Decision Framework for CIOs and CFOs
Step 1: Complete data classification before making any cloud architecture decision. The architecture must be designed around the most sensitive data in each system. An EPM system that holds only general ledger balances has a different data residency profile from one that holds employee salary details in an EPBCS Workforce Planning model. Classification determines architecture requirements; architecture does not determine classification.
Step 2: Map every integration flow explicitly. For each integration between enterprise systems, document: what data moves, when, through which middleware, in which cloud region. Commission a specific integration flow mapping exercise if this has not been done. Integration middleware in the wrong region is the most common compliance gap in GCC enterprise cloud environments.
Step 3: Review backup and DR regions explicitly. Cloud backup is usually configured to a different region from the primary for resilience — but that different region may be outside the required jurisdiction. Review every backup and DR configuration and confirm that the backup region is within the same jurisdiction as the primary.
Step 4: Configure Oracle or Microsoft vendor access governance before go-live. The customer-controlled access mechanism for Oracle support (OCI break-glass) and the equivalent for Azure (Microsoft Lockbox) must be configured before production data is in the environment, not as a post-go-live compliance remediation.
Step 5: Establish the audit trail architecture as a named deliverable. The audit trail covering application, infrastructure, integration, and key management access must be a named deliverable in any cloud implementation scope — not an assumption that the platform provides it automatically. Review the specific audit logging configuration for each system and confirm that the log retention, immutability, and regulator accessibility requirements are met.
Frequently Asked Questions
Q: Does choosing Oracle Cloud Infrastructure (OCI) Saudi Arabia or Azure Saudi Arabia make our data PDPL compliant? Choosing a cloud provider with a Saudi Arabia data centre satisfies the primary data residency requirement for PDPL — your primary data is physically in the Kingdom. It does not, by itself, make your architecture PDPL compliant. PDPL compliance requires that personal data does not leave the Kingdom without a lawful basis — which means the integration middleware that moves data between systems must also run in Saudi Arabia, the backup and DR copies must also be in Saudi Arabia, the audit logs containing personal data must also be in Saudi Arabia, and the encryption keys that protect the data must be held in a Saudi-jurisdiction HSM. Each of these requires explicit configuration. A provider with a Saudi data centre but default integration, backup, log, and key management configurations pointing to non-Saudi regions will produce an architecture that is contractually in Saudi Arabia and technically in multiple jurisdictions simultaneously.
Q: What does NCA Cloud Cybersecurity Controls require from an enterprise cloud architecture specifically? The NCA Cloud Cybersecurity Controls require four architecture-level outcomes. First, data must be classified before cloud deployment — the NCA’s data classification framework (National, Confidential, Restricted, Public) must be applied to determine which data can be hosted in which cloud environment. Second, cloud provider selection must be based on NCA cloud service provider authorisation status for the applicable data classification level — commercial availability in Saudi Arabia is not equivalent to NCA authorisation for all classification levels. Third, encryption keys for Confidential and National-classified data must be customer-managed and held in Saudi-jurisdiction hardware — provider-managed keys do not meet the requirement for this classification level. Fourth, cloud access must be governed through a documented privileged access management process, with vendor access (including the provider’s own support teams) requiring explicit customer approval per instance.
Q: Does our Oracle EPM on OCI satisfy SAMA’s data requirements for a Saudi financial institution? Oracle EPM on OCI Jeddah satisfies the primary data residency requirement for SAMA — the data is in Saudi Arabia. SAMA compliance additionally requires: OCI Jeddah backup and DR (not OCI Frankfurt), Customer-Managed Keys with OCI Vault in the Jeddah region, Customer-Controlled Access (break-glass) configured for Oracle support access governance, Oracle Data Safe enabled for database access audit trail, and OCI Integration Cloud running in the Jeddah region for all integrations between Oracle EPM, Oracle Fusion ERP, and third-party systems. An Oracle EPM implementation that uses OCI Jeddah for the primary tenancy but uses OCI Frankfurt for backup, Oracle-managed keys, standard Oracle support access, and OCI Europe for integration middleware is not SAMA-compliant regardless of the primary data centre location.
Q: What is the UAE sovereign financial cloud and should our financial institution use it? The UAE sovereign financial cloud was launched on February 25, 2026 by the UAE Central Bank in partnership with Core42 (a G42 company). It is a dedicated cloud infrastructure for UAE Central Bank-regulated entities — banks, insurance companies, exchange houses, finance companies, payment service providers — designed specifically so that regulated financial data remains within UAE jurisdiction at the infrastructure layer rather than relying on contractual data residency commitments with a global cloud provider. For UAE-licensed financial institutions with strict data sovereignty requirements or regulatory preferences for UAE-controlled infrastructure, the sovereign financial cloud provides the most direct path to demonstrable UAE data sovereignty. It is not mandatory for all UAE financial institutions, but its existence signals the CBUAE’s direction: regulated financial data belongs in UAE-controlled infrastructure.
Q: How much does a cloud architecture compliance assessment cost for a GCC enterprise? A comprehensive cloud architecture compliance assessment covering data classification, hosting architecture review, integration flow mapping, key management review, access control review, and audit trail completeness for a mid-size GCC enterprise with Oracle EPM, Oracle ERP or SAP, and a BI platform typically costs between USD 55,000 and USD 150,000 in professional services over eight to fourteen weeks. Individual assessment components — data classification alone, or integration flow mapping alone — start from USD 10,000 to USD 18,000 per component. The remediation programme that follows the assessment, addressing the compliance gaps identified, typically costs between USD 80,000 and USD 250,000 depending on the number and complexity of the gaps found. The most common finding that significantly increases remediation cost is integration middleware in non-compliant regions — pipeline rebuilds are more expensive than primary hosting migrations because they require careful design to avoid disrupting live data flows between production systems.
Q: Should we consider a hybrid cloud or on-premises architecture for PDPL and NCA compliance? A hybrid or on-premises architecture is a legitimate path to PDPL and NCA compliance — particularly for data classification levels that require on-premises HSM key management or for data that cannot be technically isolated to a cloud region without significant architectural complexity. For most enterprise application workloads (Oracle EPM, ERP, BI), the public cloud GCC regional options (OCI Jeddah, Azure Saudi Arabia, AWS Bahrain/Riyadh) can satisfy PDPL and NCA requirements with the correct architecture configuration, making on-premises hosting not a compliance requirement but a risk management preference. For National-classified data (the most sensitive NCA classification level), the NCA’s cloud authorisation framework may effectively require an on-premises or sovereign cloud environment rather than a standard public cloud deployment. The architecture decision should be driven by the data classification output — on-premises for National-classified, cloud GCC regions for Confidential and Restricted with appropriate controls, standard public cloud for Public data.
About Loop Wise Solutions
Loop Wise Solutions is an enterprise performance consultancy based in Cairo, serving medium and large enterprises across Egypt, Saudi Arabia, the UAE, Qatar, and the broader Arab world. Our Business and Technical Consultancy practice provides independent cloud architecture and data residency compliance advisory — covering PDPL, NCA Cloud Cybersecurity Controls, SAMA cybersecurity framework, and UAE data protection requirements as they apply to enterprise application architectures running Oracle EPM, Oracle ERP, SAP, Microsoft Fabric, Power BI, and intelligent automation platforms.
Every cloud architecture advisory engagement we deliver begins with a data classification exercise — because the architecture requirements are defined by the most sensitive data in each system, and the classification is the input that makes every subsequent architecture decision auditable. We then assess the hosting, integration, backup, key management, access control, and audit trail dimensions explicitly — because PDPL and NCA compliance is an architecture outcome, not a provider selection outcome.
If you are uncertain whether your current cloud architecture genuinely satisfies PDPL, NCA, or SAMA data residency requirements — or if you are planning a cloud migration for Oracle EPM, ERP, or BI and need to design the architecture for compliance from the start rather than remediate it afterwards — we are happy to have a direct conversation.
Contact: contact@loop-wise.com | Website: www.loop-wise.com
Where performance meets precision.
