Cloud Architecture for Regulated Saudi Organisations: Residency, Encryption, Logging, and Identity

Cloud adoption in regulated Saudi sectors moved past the question of whether to proceed some time ago. The open questions now are architectural. Where does the data physically reside, who can decrypt it, what record exists of access to it, and how does the organisation prove that only authorised identities reached it.

Four decisions answer those questions. Organisations make all four whether or not they make them deliberately, because default configurations decide for the teams that do not. The difference between a deliberate decision and an inherited default usually becomes visible during assessment, when the organisation must explain a configuration it never chose.

This article works through the four in the order they should be taken, since each constrains the ones that follow.

The responsibility split that frames all four

Cloud providers secure the infrastructure they operate. Customers secure what they build on it. That division sounds obvious and produces persistent confusion in practice, because the boundary moves depending on the service model.

Infrastructure services leave the customer responsible for the operating system, the application, the network configuration, identity, and the data. Platform services absorb the operating system layer. Software services absorb almost everything except identity, access configuration, and the data itself.

The consequence for regulated organisations is direct: the provider's certifications cover the provider's layer only. An organisation cannot inherit compliance from its cloud provider. It can inherit a compliant foundation, and it remains fully accountable for the configuration it applies above that foundation. Assessors examine the customer layer, and that is where findings concentrate.

Decision one: residency and region selection

Region selection is the first decision because it constrains every subsequent one, and reversing it after deployment is expensive.

The decision requires the organisation to know its own data before it knows its architecture. Which datasets contain personal data. Which contain data subject to sector-specific handling requirements. Which contain nothing sensitive at all. Organisations that classify after deployment invariably find sensitive data distributed across regions they would not have chosen for it.

Region selection covers more than primary storage. Backup destinations, disaster recovery targets, log aggregation endpoints, and the management plane through which the environment is administered all have locations. A workload running in-Kingdom that replicates backups elsewhere has moved the data, and the backup copy carries the same obligations as the original.

Supporting services introduce the same question less visibly. Authentication services, monitoring platforms, ticketing integrations, and analytics tools each process data somewhere. The architecture diagram should show where, because the assessment will ask.

Latency and service availability influence the decision alongside residency. Not every capability reaches every region simultaneously, and organisations occasionally discover that a required service is unavailable in the region their data classification demands. Discovering that during design costs far less than discovering it during migration.

Decision two: encryption and key control

Encryption in transit is settled practice and rarely the point of contention. Encryption at rest is where the meaningful decision sits, and the decision concerns keys rather than algorithms.

Provider-managed keys deliver encryption with minimal operational burden. The provider generates, stores, rotates, and uses the keys. Data is protected against physical media compromise. The organisation, however, cannot independently prevent access by the provider's own systems, and it cannot render the data unreadable through its own action.

Customer-managed keys, held in a managed key service, shift control meaningfully. The organisation governs the key lifecycle, defines which services and identities may use each key, and can revoke access. Operational responsibility rises accordingly, because a lost or improperly deleted key destroys the data it protects.

Externally held keys move control further still, with a corresponding increase in complexity, availability risk, and integration effort.

The right position on that spectrum follows from data classification rather than from a general preference for maximum control. Applying the most stringent model across an entire estate imposes operational cost on data that never required it, and organisations that do so frequently relax the controls later, uniformly, including on the data that needed them.

Key separation deserves explicit attention. Distinct keys for distinct data classifications, environments, and workloads mean that a single key compromise does not expose everything. Shared keys across an estate reproduce the shared-credential problem in a different layer.

Decision three: logging, retention, and integrity

Logging determines whether an organisation can answer questions after an event. Default cloud logging configurations rarely answer the questions regulators and investigators actually ask.

Three log categories need deliberate configuration. Management plane activity records who created, modified, or deleted resources, and it is the record that reconstructs how an environment reached its current state. Data plane activity records access to the data itself, and it is frequently disabled by default because of its volume. Network flow records show what communicated with what.

Retention periods should follow the investigative requirement rather than the default. Intrusions are frequently discovered long after they begin, and logs that expired before discovery cannot support the investigation. The organisation should decide the period against a documented rationale and configure retention accordingly.

Log integrity matters as much as log existence. Logs stored where an administrator can alter or delete them provide weak evidence. Write-once storage, separate accounts or subscriptions for log aggregation, and restricted access to the log store all strengthen the record. An attacker with administrative access will attempt to clear traces, and the logging design should assume that.

Centralisation converts logs into a monitoring capability. Records scattered across accounts, subscriptions, and services support neither correlation nor alerting. Aggregation into a single analysis platform is what makes detection possible.

Decision four: identity and access governance

Identity is the control plane of a cloud environment. An attacker holding valid credentials with sufficient privilege does not need to breach a network perimeter, because the perimeter is the authentication boundary.

Federation with the enterprise directory should be the default for human access. Local accounts created within cloud platforms sit outside the joiner, mover, and leaver process, escape access reviews, and persist after departure. Every such account is a governance exception requiring justification.

Privilege should be granted narrowly and elevated temporarily. Standing administrative access across an environment concentrates risk in whichever account is compromised first. Just-in-time elevation, requiring justification and expiring automatically, limits both the window and the scope of any compromise.

Non-human identities need governance equal to human ones, and they usually receive far less. Service principals, application registrations, automation accounts, and integration credentials accumulate over time, frequently hold broad permissions granted for convenience, and rarely appear in access reviews. In mature environments they outnumber human accounts substantially.

Access reviews must actually remove access to serve any purpose. Reviews that confirm existing permissions without ever revoking them produce documentation rather than control, and assessors have become adept at distinguishing the two.

Strong authentication applies without exception, including to administrative and break-glass accounts. Break-glass credentials in particular require documented storage, monitored use, and periodic validation, since they exist precisely for the circumstances in which normal controls have failed.

What assessment examines

Assessors evaluating a cloud environment concentrate on a consistent set of artefacts, and organisations that prepare them during design rather than before audit fare considerably better.

A data classification record shows which data exists, its sensitivity, and where it resides. An architecture diagram shows the data flows including supporting services and management paths. Configuration evidence demonstrates that the controls described are the controls deployed. Access records show who holds privilege, how it was granted, and when it was last reviewed. Log samples demonstrate that the required records exist, remain intact, and cover the retention period claimed.

The recurring finding in cloud assessments is not an absent control. It is a control that exists in one environment and not another, or one that was configured correctly at deployment and drifted afterwards. Consistency and evidence of consistency carry more weight than the sophistication of any individual control.

Frequently asked questions

Does using a compliant cloud provider make an organisation compliant? No. Provider certifications cover the provider's layer. The customer remains accountable for configuration, identity, data handling, and the evidence supporting all three.

Should every workload move to the same region? Not necessarily. Data classification should drive placement. Workloads handling no sensitive data face fewer constraints, and applying the strictest placement rule universally raises cost without raising protection.

Are customer-managed keys always preferable? They provide greater control and carry greater operational responsibility. The choice should follow data classification. Applying the most demanding key model estate-wide often leads organisations to relax it later across everything, including the data that genuinely required it.

What is the most common gap in cloud environments? Non-human identity governance. Service accounts and integration credentials accumulate with broad permissions, escape access reviews, and outlive the projects that created them.

How ITBuilders supports cloud architecture

ITBuilders designs and delivers cloud foundations for organisations operating under regulatory obligation, covering region and residency architecture, encryption and key management design, logging and monitoring integration, and identity and access governance. Engagements begin with data classification and requirement definition, so the architecture reflects the obligation rather than being retrofitted to it afterwards.

To discuss cloud architecture, contact ITBuilders at 920-020-750 or itbuilders.com.sa

Related services

Cloud Foundation · Cybersecurity Services · Strategic IT Consulting