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.
Cost | Description | Typical scale |
|---|---|---|
Direct penalty | Regulatory fine following a supervisory finding | CBUAE issued AED 370m+ across the UAE sector in 2025; AED 200m in a single action |
Personal liability | Penalty against a named officer in addition to the institution | AED 300,000 against one bank’s head of compliance, June 2026 |
Remediation cycle | Mandated programme consuming senior engineering capacity and suspending discretionary change | 18 to 30 months, frequently exceeding the fine in opportunity cost |
Manual evidence assembly | Analyst effort reconstructing evidence ahead of each examination | Recurring every supervisory cycle, not visible in the compliance budget |
Strategic constraint | AI and product initiatives held at risk review | Unquantified, and often the largest |
The June 2026 CBUAE action illustrates the current supervisory position. The regulator fined a foreign bank
branch AED 20 million for 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.
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 organisations 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
CBUAE’s 2026 supervisory guidance identifies the failure pattern directly: documented policies without
operational implementation. 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.
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. UAE PDPL adds
obligations covering lawful basis, data subject rights and cross-border transfer, none of which can be satisfied
without first establishing where personal data resides
Taken together, these frameworks reduce to four questions with four corresponding evidence artefacts. The
following mapping translates regulatory language into requirements an engineering team can implement.
Regulatory question | Evidence that satisfies it | AWS services involved |
|---|---|---|
Where does regulated data physically reside, including backups ? | Configuration records demonstrating in jurisdiction infrastructure and immutable in-Region backups | Region-deny SCPs in AWS Organizations, AWS Backup with Vault Lock |
Has regulated data left the jurisdiction? | Network evidence of no unauthorised egress | VPC Flow Logs, VPC endpoints, AWS Network Firewall egress control |
Who accessed this dataset, when, and from where? | Immutable access history including geographic metadata | AWS CloudTrail data events, CloudTrail Lake, S3 Object Lock in compliance mode |
What is the origin of this figure in our submission? | Catalogued lineage and enforced permissions | AWS Glue Data Catalog, AWS Lake Formation, Amazon Macie classification |
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:
1. Organisations frequently believe they hold comprehensive access records when they hold control plane
activity only.
2 . Object-level reads on storage and function-level invocations are often not captured, as this logging is disabled
by default and incurs additional cost.
3. Data Governance in GCC Financial Services
Log data is distributed across multiple accounts with inconsistent retention periods and no common identity
for correlation.
4. Access granted for completed projects is not revoked, as revocation requires explicit action.
5. 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
The Scope of AWS 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 compliance question is substantially addressed at the
platform level.
The AWS Shared Responsibility Model establishes why this is not 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 evidences 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 a non-approved 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 December 2026 Saudi Region
AWS has confirmed that its first infrastructure Region in Saudi Arabia will launch in December 2026, supported
by a $5.3 billion investment and delivered in partnership with HUMAIN under Vision 2030.
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.
Data Governance in GCC Financial Services
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 December 2026, 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 by-product of
normal operation.
Structuring the work against the four SAMA Cyber Security Framework domains is effective, as it maps to AWS
services and uses terminology the examiner already applies.
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 organisational level. Service control policies denying non-approved 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 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 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.
Data Governance in GCC Financial Services
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 into AWS CloudTrail Lake within a dedicated log archive account, with retention matched
to the applicable regulatory obligation, makes history queryable in SQL rather than requiring extraction from
object storage.
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 Current 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
Level | Time to produce submittable evidence | Characteristics |
|---|---|---|
Reactive | 4 weeks or more | Evidence assembled manually per request. No current data map. Data event logging disabled. |
Documented | 2 to 4 weeks | Framework and policies established. Classification point-in-time. Logs distributed across accounts. |
Controlled | 3 to 10 days | Residency enforced through guardrails. Centralised immutable audit trail. Classification automated for priority data. |
Evidence-ready | Under 48 hours | Config and Audit Manager producing scheduled packages. Lineage catalogued. Examination response consists of a query and an export. |
Most GCC institutions assess 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
CloudTrail Lake 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 today, and the same pattern is already in production use for
cost management and operations.
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 Plan
Phase | Timeframe | Activity | Evidence produced |
|---|---|---|---|
Baseline | Days 1-15 | Measure response time for the three regulator questions. Inventory the location of regulated data. Map the shared responsibility boundary for the estate. | Measured maturity baseline and current-state data map |
Residency guardrails | Days 15-45 | Region-deny SCPs, VPC endpoints, in-Region KMS key custody with reviewed key policies, Backup Vault Lock on regulated backups | Configuration records demonstrating geographic enforcement and immutable in-jurisdiction backups |
Audit trail | Days 15-45 | CloudTrail data events on regulated storage, consolidation to CloudTrail Lake in a log archive account, S3 Object Lock in compliance mode | Immutable, queryable access history |
Classification and lineage | Days 45-75 | Macie jobs scoped to regulated buckets, Glue Data Catalog and Lake Formation tag-based access control | Current data map and queryable lineage |
Scheduled evidence | Days 75-90 | Config conformance packs mapped to the control set, Audit Manager packages on a defined cadence, Security Hub and Security Lake aggregation | Examination-ready packages produced in advance |
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.
The Organizational Dimension
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.
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 largest 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 December 2026 AWS Saudi Region establishes 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 prerequisite to automating compliance interpretation through agentic AI, and
to 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.
Cloud Engineer