Data governance is a business capability rather than a compliance document. When an organisation cannot answer a regulator’s question about its own data, the consequences appear in places leadership can measure: penalty notices, remediation programmes that suspend the technology roadmap, artificial intelligence initiatives held at risk review, and analyst time spent reconstructing evidence manually.
For banks and financial institutions in the GCC, strong data governance means being able to show a regulator, on request, where regulated data sits, who accessed it, and where reported figures came from, using records the platform produces automatically.
Across banks and financial institutions in the UAE and Saudi Arabia, the inability to demonstrate compliance is among the more consistently underestimated business problems in technology. This blog examines the cost of weak data governance in GCC financial services, what regulators currently accept as proof, what an evidence-ready data platform on AWS requires, how to assess current maturity, and how agentic AI is likely to change the economics of this work. It is written for the practitioners who own this work: cloud architects, platform engineers, heads of infrastructure, and the compliance leads responsible for signing off on what is built.
What Weak Data Governance Costs
Compliance discussions typically begin with a governance framework presentation: control domains, ownership, board sign-off date. The intended message is that the area is addressed.
A more specific question tends to establish the actual position. If a regulator submitted a request identifying every system holding customer personal data, the physical location of each copy, and a record of who accessed the transaction tables in the preceding quarter, how long would the organisation require to respond, and would the response be suitable for submission?
In many institutions, the honest answer is measured in weeks rather than days. The controls are generally present. What is absent is the ability to demonstrate that they operate, and that gap carries cost in five areas.
In June 2026, the CBUAE fined a foreign bank branch AED 20 million for significant, repeated failures in its anti-money laundering, counter terrorist financing and sanctions framework, and imposed a separate AED 300,000 penalty on the branch’s Head of Compliance and Money Laundering Reporting Officer.
The second penalty is significant beyond its value. Regulatory exposure in the region now extends to named individuals, and it attaches to whether a control demonstrably operates rather than whether it is documented.
The fourth category is the one organisation rarely forecast. The person-days spent assembling evidence before each examination, extracting reports, reconciling inconsistent exports and obtaining confirmations from system owners, recur every supervisory cycle and produce no durable capability, because the underlying platform is unchanged.
The fifth category has the longest-term effect. Where an organisation cannot establish the location of regulated data or the history of access to it, generative AI initiatives remain at risk review, new products require individual data assessments, and migration progresses at the pace of legal clearance. Weak data governance creates regulatory exposure and also constrains the rate at which the institution can change.
What GCC Regulators Require as Proof
Supervisory examination has shifted over the past five years from assessing whether appropriate frameworks exist to assessing whether those frameworks produce evidence.
The CBUAE’s updated AML/CFT/CPF guidance, issued in April 2026, places greater weight on ongoing monitoring, robust record-keeping, and timely remediation of control gaps. The institutions subject to findings generally hold frameworks. What they cannot do is evidence them.
Kingdom of Saudi Arabia
The Saudi Central Bank (SAMA) Cloud Computing Regulatory Framework requires customer data, transaction records, and business continuity backups to remain on infrastructure within the Kingdom. Backups are specified explicitly, which affects institutions whose primary workload is compliant and whose disaster recovery copy is not.
The National Cybersecurity Authority (NCA) requires data classification, data flow mapping, and technical enforcement of geographic boundaries. The National Data Management Office (NDMO), operating under the Saudi Data and Artificial Intelligence Authority (SDAIA), adds national data governance controls covering classification, data quality, metadata, and retention. SDAIA also oversees the Personal Data Protection Law, and SAMA has directed the institutions it supervises to align their data governance policies with it.
United Arab Emirates
CBUAE’s anti-money laundering and counter terrorist financing expectations centre on demonstrated operational effectiveness: transaction monitoring that functions rather than transaction monitoring that exists, consistent application of customer due diligence, and governance oversight supported by a traceable record.
Personal data obligations depend on where an institution is licensed. CBUAE regulation applies onshore, the UAE PDPL covers personal data outside the categories it excludes, and the DIFC and ADGM free zones apply their own data protection laws. Each regime assumes the institution already knows where personal data resides.
Taken together, these frameworks reduce to four questions with four corresponding evidence artefacts. The mapping below translates regulatory language into requirements an engineering team can implement.
None of these requirements are satisfied by attestation. The expectation is also long established: the Basel Committee published BCBS 239 in 2013, requiring accurate and timely risk data aggregation, and continues to report incomplete implementation across large institutions thirteen years later. A requirement that remains unmet across that period indicates a structural problem rather than insufficient effort.
Why Institutions With Established Frameworks Still Fall Short
The cause is generally accumulation rather than negligence.
Customer data becomes distributed across a core banking platform, several CRM systems inherited through acquisition, a data warehouse, analytical extracts without formal ownership, and software as a service applications procured directly by business units. No single function retains a complete view, so no authoritative map exists.
Logging coverage is commonly weaker than assumed:
• Organisations frequently believe they hold comprehensive access records when they hold control plane activity only.
• Object-level reads on storage and function-level invocations are often not captured, as this logging is disabled by default and incurs additional cost.
• Log data is distributed across multiple accounts with inconsistent retention periods and no common identity for correlation.
• Access granted for completed projects is not revoked, as revocation requires explicit action.
• Classification was conducted as a point-in-time exercise, so the resulting map describes an estate that has since changed.
Consequently, when an examiner requests a record of who accessed a given dataset, the position is that no record exists. The records were not deleted; they were never generated. This is not recoverable retrospectively, which is the reason audit logging warrants priority over other remediation activity.
How the AWS Shared Responsibility Model Strengthens Your Compliance
This point warrants separate treatment, as it is the most common misunderstanding in regulated cloud estates and is specific to hyperscale platforms.
AWS maintains an extensive compliance programme, with attestations available through AWS Artifact covering SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017, ISO 27018, PCI DSS and a range of regional frameworks. Institutions reviewing that portfolio may conclude that the platform substantially addresses the compliance question.
The AWS Shared Responsibility Model explains why this isn't the case. AWS is responsible for security of the cloud: physical data centres, hardware, the hypervisor, and managed service infrastructure. The customer is responsible for security in the cloud: data classification, identity and access management, encryption configuration, network controls, logging, and the evidence that these operate as intended.
Applied to SAMA, NCA, NDMO, and CBUAE requirements, the boundary is clear. AWS Artifact provides evidence of the Region’s physical and operational controls, which addresses part of a cloud outsourcing assessment. It does not address whether an S3 bucket policy permits cross-account access, whether object-level reads are logged, whether a backup vault resides in the correct jurisdiction, or whether deployment to an unapproved Region is technically possible.
Those are the areas in which findings are raised, and each falls on the customer side of the boundary. Establishing where that boundary sits, and maintaining evidence on the customer side of it, accounts for much of the difference between a clean examination and a remediation programme.
Data Residency and the AWS Saudi Arabia Region
AWS has confirmed that its first infrastructure Region in Saudi Arabia is on track to launch in December 2026, representing more than $5.3 billion in planned investment. Separately, AWS and HUMAIN plan to make up to 50MW of AI capacity available in the Kingdom’s first AI Zone by 2028.
For regulated institutions in the Kingdom, this removes the principal structural obstacle to cloud adoption. In-country residency for customer data, transaction records and continuity backups becomes achievable within a hyperscale environment rather than solely through local hosting arrangements. Institutions should still confirm which AWS services are available in the Region at launch before finalising their architecture.
Two consequences follow.
For institutions migrating in 2027, data governance sits on the critical path. Migration exposes governance gaps immediately. Data cannot be classified if it has not been mapped, residency cannot be enforced across flows that have not been traced, and account and network boundaries cannot be designed around undocumented access patterns. Organisations that complete this work during the planning window migrate into a controlled environment. Those that defer it transfer the existing position into new infrastructure and encounter it again at the first post-migration examination.
For institutions with obligations arising before the Region opens, interim options exist. The AWS Well-Architected Data Residency and Hybrid Cloud Lens addresses this scenario, recommending AWS Outposts or AWS Local Zones where data must reside in a country without a local Region, with AWS Dedicated Local Zones available for stricter sovereign requirements. These are supported architectures rather than workarounds. The governance layer can be established now, and the workload relocated subsequently, as the evidence model does not change when the Region becomes available.
The Evidence Ready Data Platform on AWS: Five Layers
Where the objective is framed as evidence on demand rather than improved documentation, the architecture follows directly. The requirement is a platform in which compliance evidence is generated as a byproduct of normal operation.
Each layer below maps to controls in the SAMA Cyber Security Framework, which helps when presenting the design to an examiner in terminology they already use.
Layer 1: Residency as a Technical Control
A governed landing zone on AWS Control Tower and AWS Organizations establishes account structure, guardrails, and Region restrictions at the organizational level. Service control policies denying unapproved Regions convert data residency from a written commitment into a technical constraint that individual teams cannot bypass, including unintentionally.
Service traffic should remain off the public internet through VPC endpoints, and encryption key custody should remain in Region under AWS KMS with key policies subject to formal review. Sovereignty concerns include who can compel access to encryption keys as well as where data is stored, and this distinction is generally the one legal functions prioritise.
Layer 2: Classification Through Discovery
Amazon Macie provides continuous discovery and classification of sensitive data across Amazon S3, replacing periodic questionnaires with a map reflecting the current state. Scoping through sampling and targeted jobs is advisable rather than applying it across the full estate initially, as cost scales with volume scanned.
A map that updates weekly and contains some inaccuracy is more useful than a complete map that was accurate eighteen months previously.
Layer 3: Audit Trails Suitable for Examination
AWS CloudTrail data events should be enabled for storage holding regulated data, in addition to management events. Consolidating CloudTrail data into a dedicated log archive account, with retention matched to the applicable regulatory obligation, makes access history queryable rather than requiring manual extraction from object storage. AWS closed CloudTrail Lake to new customers in May 2026 and directs new users to Amazon CloudWatch for equivalent query capability; institutions already using CloudTrail Lake can continue to do so.
Amazon S3 Object Lock should be applied to the archive in compliance mode rather than governance mode. Governance mode permits a sufficiently privileged principal to override retention, which is the specific objection examiners raise. Compliance mode cannot be overridden by any principal, including the account root. The same distinction applies to AWS Backup Vault Lock, which addresses the SAMA backup residency and immutability requirements through a single control.
Layer 4: Lineage and Enforced Permissions
AWS Glue Data Catalog and AWS Lake Formation centralise definitions and enforce tag-based access control, making access rights and data origin queryable rather than subject to investigation.
This layer delivers value beyond compliance, as it provides the same foundation required by analytics and generative AI workloads. Organisations that position data governance as an enabler of AI capability rather than solely as a compliance cost generally secure approval more readily.
Layer 5: Continuous Evidence Generation
AWS Config with conformance packs evaluates configuration state against the defined control set continuously. AWS Security Hub, Amazon GuardDuty and Amazon Security Lake normalise findings across a multi-account estate into a single queryable layer. AWS Audit Manager assembles collected evidence into structured report packages on a defined schedule.
One qualification applies: Audit Manager provides collection and structure, not the control mapping. Personnel who understand both the regulatory framework and the estate are still required to map SAMA, NCA, NDMO or CBUAE requirements onto technical evidence. This step is consistently underestimated and is where programme schedules most often extend.
Combined with continuous monitoring, configuration drift is identified within hours rather than appearing as an examination finding.
Assessing Data Governance Maturity
Before selecting tooling, organisations should establish a baseline. Identify the three data questions the regulator is most likely to ask, then measure the time required to answer them with evidence suitable for submission. That measurement provides a more accurate indication of maturity than a framework assessment, and generally supports the business case more effectively.
Institutions that run this test honestly often place themselves between Reactive and Documented. Controlled is achievable within a quarter for a defined scope. Evidence ready represents a programme, but one with a measurable completion point.
Agentic AI and the Next Phase of Compliance Evidence
The direction of development here is worth noting, as it alters the economics of compliance operations.
The principal cost in compliance is not the generation of evidence but its interpretation: reviewing a regulatory control, identifying the technical artefacts that demonstrate it, assembling those into a form an examiner will accept, and repeating the process each cycle. This work requires judgement, is repetitive, and is currently performed by senior personnel under time constraints.
This class of problem is well suited to agentic systems. With a governed data platform in place, an agent can query the audit log archive for access history, retrieve Config state for a given control, obtain the relevant Audit Manager evidence, and prepare the mapping for human review. Amazon Bedrock with retrieval over an organisation’s own control documentation and evidence store supports this pattern today.
The prerequisite is the significant point. An agent cannot query evidence that was never captured. Organisations establishing the governance layer now will be positioned to automate the interpretation layer subsequently. Those that do not will continue to perform it manually.
A 90 Day Data Governance Plan on AWS
Common Implementation Errors
Treating AWS Artifact as complete compliance coverage. It addresses the infrastructure layer. Requirements above that layer remain the customer’s responsibility to evidence, and that is where findings are raised.
Treating management-level logs as access logs. Without CloudTrail data events on regulated storage, read activity cannot be established, and remediation does not recover history that was never captured.
Applying Object Lock or Vault Lock in governance mode. The control appears equivalent in architectural documentation but does not satisfy examination scrutiny.
Addressing the primary workload without the backup. SAMA specifies business continuity backups explicitly. A disaster recovery copy in a non-approved jurisdiction constitutes a finding irrespective of the primary configuration.
Treating classification as a time-bounded project. An exercise completed eighteen months previously describes an estate that has since changed.
Attempting estate-wide remediation simultaneously. Enterprise-wide governance programmes reliably produce documentation while leaving the original questions unanswered. A defined scope delivering verifiable evidence, subsequently extended, is more effective.
Managing cost optimisation and governance as separate programmes. Region selection, tagging schema and disaster recovery topology are simultaneously cost and compliance decisions.
Who Should Own Compliance Evidence and How SUDO Helps
The technical requirements described above are well understood. Programme outcomes are more commonly determined by organisational factors: compliance and engineering functions report to different executives, apply different terminology, and hold no shared definition of completion.
The effective change is to treat evidence as a platform deliverable rather than a compliance deliverable. Where the engineering function owns production of evidence, and the compliance function owns validation, examination preparation becomes a reporting activity rather than an event. That change in ownership has greater effect on examination outcomes than any individual service described here.
SUDO Consultants, an AWS Premier Tier Partner with offices in Dubai and Riyadh, helps financial institutions in the UAE and KSA build AWS environments that produce compliance evidence as part of normal operation. An engagement can cover:
• Baseline assessment against the three regulator questions and the shared responsibility boundary
• Governed landing zone with Region guardrails, VPC endpoints and in-region key custody
• Immutable audit trails using CloudTrail data events, S3 Object Lock and AWS Backup Vault Lock
• Data classification and lineage using Amazon Macie, AWS Glue Data Catalog and AWS Lake Formation
• Continuous evidence generation with AWS Config, Security Hub, Security Lake and Audit Manager
• Agentic AI on Amazon Bedrock to prepare control mappings for compliance review
Key Takeaways
• GCC supervision has moved from framework review to evidence review, and enforcement now extends to named individuals in addition to institutions.
• The penalty is rarely the highest cost. Remediation cycles, recurring manual evidence assembly, and constrained strategic initiatives generally exceed it.
• The AWS Shared Responsibility Model establishes where AWS Artifact coverage ends, and customer obligation begins. Most examination findings fall on the customer side.
• The AWS Saudi Arabia Region creates a dated planning requirement for institutions in the Kingdom. Outposts, Local Zones, and Dedicated Local Zones are supported interim patterns.
• Residency enforcement, immutable backups, and audit logging offer the highest return as initial measures. They escalate most rapidly with regulators and are least expensive to address early.
• A governed data platform is also the prerequisite for automating compliance interpretation through agentic AI, and for generative AI use cases currently held at risk review.
Frequently Asked Questions
Does the AWS Saudi Arabia Region satisfy the SAMA data residency requirement independently?
It removes the infrastructure constraint but not the governance obligation. SAMA requires evidence that regulated data, including business continuity backups, remains within the Kingdom. This requires Region-deny guardrails, data flow mapping, in-Region key custody, immutable backup vaults, and audit trails demonstrating no unauthorized egress. The Region makes compliant architecture achievable rather than automatic.
Can AWS compliance certifications be relied upon for SAMA and NCA requirements?
For the portion within AWS control. AWS Artifact provides attestations covering the Region’s physical and operational controls, addressing part of a cloud outsourcing assessment. Configuration, identity and access management, encryption posture, logging, and residency enforcement remain the customer’s responsibility to evidence under the Shared Responsibility Model.
What is the difference between S3 Object Lock governance mode and compliance mode?
Governance mode allows a sufficiently privileged principal to override retention settings. Compliance mode cannot be overridden by any principal, including the account root, which is why examiners expect regulated audit archives and backups to use compliance mode.
Is an existing AWS landing zone sufficient for examination?
Generally not on its own. Most landing zones are designed for operational separation rather than evidence production. The most frequently identified gaps are CloudTrail data events disabled, log retention shorter than the regulatory obligation, mutable log storage, backup vaults without Vault Lock, and absence of mapping between technical controls and framework requirements.
What is a realistic timeline to achieve evidence on demand for one data domain?
For a single regulated domain on an existing AWS footprint, 90 days is realistic for residency enforcement, audit trail, and scheduled evidence generation. Full classification and lineage across a large estate requires longer and should follow rather than precede that work.
What are the ongoing costs?
The material recurring costs are CloudTrail data events, log archive storage and query, and Macie scanning, each scaling with volume and warranting deliberate scoping rather than estate-wide enablement initially. In most estates, these costs fall below the person-days currently allocated to manual evidence assembly each cycle.
Prove It Before You Are Asked.
Data governance in GCC financial services is now judged on evidence, not intent. Book a free consultation with SUDO to measure how quickly your institution can answer the three regulator questions today, and what it takes to become evidence-ready on AWS.
► Assess Your Data Governance Evidence Readiness with SUDO
Explore SUDO’s SAMA compliance solutions built on AWS.
Top comments (0)