Landing Zones for Regulated Workloads on OCI

Most cloud problems that surface in year three were created in week one. A tenancy that started as a proof of concept, grew a production workload, and then grew a compliance obligation carries its original sins forever: admin rights granted broadly because it was just a pilot, a flat network because nobody planned for segmentation, logs scattered or absent because nobody asked who would read them. For regulated organizations the cost of that drift is not just technical debt, it is audit findings, supervisory attention, and in the worst cases workloads that cannot be certified at all. This article is part of our complete guide to OCI compliance and sovereignty, and it covers the single most leveraged artifact in that whole domain: the landing zone.

A landing zone is the pre built, pre governed foundation of a tenancy: the compartment hierarchy, identity model, network topology, encryption posture, logging pipeline, and policy set into which workloads later arrive. Done well, every workload that lands inherits the controls by default. Done badly, every workload team relitigates security from scratch, and the auditor finds a different answer in every corner of the estate.

Why the landing zone is the compliance foundation

Regulated workloads do not become compliant one virtual machine at a time. The economics of assurance only work when controls are inherited rather than reimplemented. If encryption with customer managed keys, denied public egress, mandatory logging, and least privilege access are properties of the compartment a workload lands in, then the workload team gets them for free and the compliance team attests to them once. If those controls live in each project's hands, you get as many security postures as you have teams, and the audit becomes an archaeology project.

There is a second, quieter reason the landing zone matters: it is the artifact regulators can actually read. A supervisor cannot inspect ten thousand resources, but they can read a documented standard, a Terraform repository, a compartment diagram, and a policy set, and then sample the estate to confirm reality matches the document. The landing zone is where your written standard and your running infrastructure are supposed to be the same thing. When they are, audits get shorter. When they are not, audits get longer and trust gets spent.

What regulators and auditors expect to see

The specific clauses differ between financial supervisors, health regulators, and public sector security frameworks, but the expectations converge on six themes, and a landing zone should be designed against all of them from the first commit.

Segregation. Production separated from nonprod, sensitive data separated from general workloads, and duties separated so that no single person can both change a system and approve the change. In OCI this maps directly to compartments, identity domains, and policy.

Least privilege. Access granted to groups, scoped to compartments, reviewed on a schedule, with standing admin access minimized and break glass procedures documented and rehearsed.

Logging and traceability. Every administrative action, every authentication, every network flow that matters, captured centrally, retained per policy, and protected from tampering by the very administrators it records.

Encryption. At rest and in transit everywhere, with the sensitive tiers under keys the customer controls, rotates, and can revoke.

Change control. Infrastructure changes proposed, reviewed, approved, and applied through a pipeline that leaves a trail, not through a console session that leaves a mystery.

Documented standards. A written description of all of the above that matches what is actually deployed. Auditors forgive imperfect controls more readily than they forgive undocumented ones.

The building blocks of a regulated landing zone on OCI

OCI gives you primitives that map unusually cleanly onto regulatory expectations, largely because compartments and policy were designed as governance constructs rather than billing conveniences. Here is how the pieces assemble.

Compartments as the control boundary

The compartment hierarchy is the skeleton of the whole design, because policies, budgets, Security Zones, and quotas all attach to it. A regulated baseline typically separates a security compartment holding keys, logs, and Cloud Guard configuration, a shared services compartment for DNS, bastions, and connectivity, a network compartment owning the hub, and then workload branches split between prod and nonprod. Where multiple regimes apply, per regulation compartments earn their keep: a PCI branch, a HIPAA branch, a general branch, each with its own policy set and its own Security Zone recipe, so the strictest controls apply only where the strictest data lives. The hierarchy should be deep enough to express your control boundaries and no deeper, since every level adds policy complexity that someone has to maintain.

Identity domains, federation, and policy design

IAM identity domains separate workforce identities from workload identities and let you apply different authentication rules to each. Federate the workforce domain to your existing identity provider so joiners, movers, and leavers flow through one lifecycle, enforce multifactor authentication and conditional access at the domain, and keep local accounts to a minimum with a documented justification for each. Policy design then does the heavy lifting for least privilege: grants to groups, never to individuals, scoped to the narrowest compartment that works, with the tenancy root kept almost empty. Dynamic groups and resource principals remove credentials from code entirely, which removes a whole audit conversation. Write the policy set as a reviewed document first and as Terraform second, so the auditor can read the intent and verify the implementation.

Hub and spoke networking with no default egress

The reference network for regulated estates is hub and spoke built on the Dynamic Routing Gateway. A hub VCN carries inspection, egress control, and connectivity to on premises over FastConnect or Site to Site VPN, and each workload environment gets its own spoke VCN attached to the DRG, with route tables forcing inter spoke and outbound traffic through the hub. The non negotiable default for regulated workloads is no default internet egress: spokes have no internet gateway, platform services are reached through service gateways and private endpoints, and anything that genuinely needs the internet goes through an inspected, logged egress path in the hub that someone explicitly approved. Private connectivity to on premises keeps data flows off the public internet entirely and gives the audit team a clean answer to the question of how data moves. This network posture is also the natural enforcement layer for a broader zero trust architecture on OCI, where network security groups and identity, not IP ranges and implied trust, decide who talks to whom.

Security Zones, Cloud Guard, and the detective layer

Security Zones turn policy intent into hard enforcement: attach a recipe to a sensitive compartment and OCI will refuse to create a public bucket, an unencrypted volume, or an internet facing resource inside it, no matter who asks. That shift from detect and correct to prevent outright is exactly the assurance language regulators respond to. Cloud Guard belongs on from day one, tuned over time but never off, watching the whole tenancy for risky configurations and anomalous activity and feeding its problems into a queue someone actually owns. Both should be checked against an external yardstick: the CIS Benchmark for OCI gives you an independent, versioned baseline to measure the tenancy against, and running it before the first workload lands is far cheaper than running it before the first audit.

Logging, audit retention, keys, and tags

Centralize OCI Audit, service logs, and flow logs into the security compartment, ship them to Object Storage with retention rules that match your records policy, and protect the archive with retention locks so administrators cannot quietly rewrite history. Encryption follows the same principle of customer control: customer managed keys in OCI Vault for the sensitive tiers, with rotation schedules, key usage logging, and a documented answer to what happens if a key must be revoked. For the highest assurance tiers, private Vaults with dedicated HSM partitions exist where the regulator or the risk appetite demands them. Finally, tagging is the unglamorous block that makes everything else operable: mandatory tag defaults for data classification, owner, environment, and cost center mean every resource declares what it is, who answers for it, and how sensitive its contents are. Classification tags are what let reports, access reviews, and cost allocation run from queries instead of interviews.

Everything as code, or it did not happen

A landing zone built by clicking through the console is a landing zone that exists only in the memory of whoever clicked. It cannot be reviewed before it changes, cannot be reproduced in a second region, cannot be diffed against the documented standard, and cannot prove to an auditor that what was approved is what was deployed. Terraform fixes all four problems at once: the repository is the standard, the pull request is the change control record, the pipeline is the segregation of duties, and the state file is the basis for drift detection. Oracle publishes open source landing zone reference implementations, including CIS aligned Terraform modules, and they are the right starting point for most organizations: hundreds of decisions already made defensibly, ready to be adapted rather than invented. The adaptation is the real work, which is where an experienced OCI implementation partner earns its fee: mapping your regulatory obligations, operating model, and existing identity and network estate onto the reference, and deleting what you do not need before it becomes permanent.

The practical difference between the three ways tenancies get built shows up on every dimension an auditor cares about.

Mapping the landing zone to specific regimes

The same foundation serves multiple regimes because most regimes ask for the same structural things in different vocabulary. For European financial entities, DORA compliance on OCI leans on the landing zone for operational resilience: documented ICT architecture, logging that supports incident reporting timelines, tested recovery paths across availability and region boundaries, and a register of where critical functions run. For healthcare workloads, HIPAA on OCI maps the technical safeguards almost one to one onto landing zone controls: access management onto identity domains and policy, audit controls onto centralized logging, transmission security onto private connectivity and TLS, and encryption onto Vault backed keys, all scoped to the compartments where protected health information lives. PCI DSS is the clearest case of all, because its core demand is segmentation: a per regulation compartment branch with its own Security Zone, its own spoke, no default egress, and tightly scoped policy is precisely the reduced cardholder data environment that keeps the assessment small. One foundation, three vocabularies, one set of evidence.

Operating the landing zone after go live

A landing zone is not a project deliverable, it is a product with a lifecycle, and regulators increasingly audit the operation rather than the design. Four disciplines keep it audit ready. Drift detection compares the running tenancy against the Terraform state and the written standard on a schedule, because drift is how click built creep returns through the side door. Exception management accepts that real estates need deviations, and insists every one is requested, risk assessed, approved, time boxed, and reviewed at expiry, so the exception register is a managed document rather than a folder of forgotten approvals. Evidence generation turns the architecture into audit artifacts on demand: policy exports, access review reports, key rotation logs, Cloud Guard posture summaries, and control mappings produced from the estate itself, not reconstructed in the week before the auditor arrives. And monitoring has to match the obligations the workloads carry: regulated estates run incident reporting clocks measured in hours, which makes 24/7/365 monitoring of the security and logging pipeline part of the compliance posture, not an operational nicety. Across 500+ OCI engagements, the estates that pass audits calmly are the ones where these four disciplines were staffed and scheduled before the first workload landed, not bolted on after the first finding.

An eight step build sequence

Sequence matters, because each step constrains the next. This is the order we run regulated landing zone builds in, and the order matters more than the speed.

None of this is exotic, and that is the point. A regulated landing zone is mostly discipline applied early: a hierarchy that means something, identity that flows from one source of truth, a network that denies by default, keys and logs the customer controls, and a codebase that makes all of it reviewable. Teams with 20+ years of combined Oracle experience have watched the same pattern repeat across financial services, healthcare, and government: the organizations that invest the first six weeks in the foundation spend the next six years landing workloads quickly, while the organizations that skipped it spend those years explaining the gap between their documents and their tenancy. Build the boring part first, build it as code, and let every workload that follows inherit the answer.