Your Landing Zone Is Your Governance Model — Design It Wrong and Everything Breaks

TLDR

A cloud landing zone is not infrastructure plumbing. It is your governance model, compiled into architecture — and it will outlive every strategy document, operating model review, and reorganisation that follows it. Three design decisions carry almost all of the weight: account hierarchy (which defines the blast radius of every mistake), identity (which defines who and what holds authority), and policy inheritance (which determines whether controls are enforced or merely documented). Banks that treat these as separable technical choices accumulate identity debt and structural exceptions that surface years later, under audit or under incident. Banks that design them as one risk model get the outcome regulators and engineers both want: teams that move fast inside boundaries that hold under stress.

This is post five of a series on cloud engineering and leadership in financial institutions. Post one covered why cloud in a bank is nothing like cloud anywhere else: the operating model shift that prudential obligations demand. Post three showed how to read APRA's prudential standards as design constraints rather than compliance paperwork. Post four mapped the five layers of cloud maturity inside a bank — and ended with a promise: the next post would tackle the one decision that determines whether every layer above it can succeed. This is that post.

The policy that could not be deployed

Here is a scene that plays out, in some variation, inside most banks a few years into their cloud journey.

A security architect drafts a control that everyone agrees with: critical payment workloads must sit behind deny-by-default network rules, with change windows enforced at the platform level. The policy is written, tested, and ready. Then someone asks where to apply it.

And there is no answer.

The payments workloads share accounts with a marketing analytics platform and two retired proof-of-concepts. The account hierarchy mirrors a divisional structure from a reorganisation two years earlier. Applying the policy at any level either breaks workloads it was never meant to touch, or exempts the very systems it was written to protect. The control is sound. The structure cannot express it.

So the team does what teams always do: they scope the policy to a hand-maintained list of resource tags, add four exceptions, and move on. The control now exists on paper and in fragments. Under an audit, it will be very hard to demonstrate it operates. Under an incident, it will be very hard to prove what was actually protected.

Nobody made a bad decision in that room. The bad decision was made years earlier, when the landing zone was treated as plumbing — something to iterate on later, once the "real work" of migration was done.

That is the myth this post exists to kill. Your landing zone is not plumbing. It is your governance model, compiled. Every control you will ever want to enforce, every audit question you will ever need to answer, and every incident you will ever need to contain happens inside the structure you lay down at the start. Design it as a risk model and everything above it inherits safety. Design it as a filing system and everything above it inherits the gaps.

The failure pattern: structure follows org chart, identity follows convenience

In almost every landing zone review I have been part of, the failures follow the same pattern — and they rarely look like failure at the time. Two quiet decisions do most of the damage.

Decision one: the hierarchy mirrors the org chart

It feels natural. Each division gets a branch. Each team gets an account. The structure matches the operating model, the cost reporting falls out neatly, and everyone knows where their things live.

The problem is that org charts encode reporting lines, not risk. A single division runs an internet-facing customer app, a core ledger batch process, and a developer sandbox. In an org-chart hierarchy, those three workloads — with utterly different criticality, data sensitivity, and tolerance for disruption — end up inside the same boundary, inheriting the same controls.

Now every policy decision becomes a compromise. Tighten the boundary and the sandbox team drowns in friction they do not need. Loosen it and the ledger runs with sandbox-grade controls. The result is almost always a middle setting — wrong for everything, patched with exceptions, and drifting further from defensible with every quarter.

There is a second cost: org charts change. Divisions merge, teams move, products get re-homed. A hierarchy that mirrors the org chart inherits the churn of the org chart — except that moving a workload between cloud accounts is not an HR update. It is a migration, with data gravity, network re-addressing, and identity rewiring. So the structure stops tracking the organisation within a couple of years anyway, and you are left with the worst of both: a hierarchy that encodes neither risk nor reality.

Figure 1: The same bank, two structures. In the org-chart version, criticality is scattered and every policy is a compromise. In the risk-based version, controls tighten by tier and the structure can express every control you will ever need to apply.

The implication is uncomfortable but worth stating directly: if your account hierarchy maps to a current or historical org chart, the error is already in the structure. The question is not whether it will surface — it is when, and under what pressure.

Decision two: identity is treated as a separate workstream

The second failure is quieter. While the account structure is being debated, identity gets handled "pragmatically": a shared deployment credential here, an over-scoped service principal there, an admin group that grew because removing people felt risky. None of these is an incident. Each one is a sensible shortcut under delivery pressure.

This is identity debt, and it compounds exactly like financial debt: invisibly, and then suddenly. Service principals with organisation-wide write access that nobody can confidently decommission. Pipelines that deploy to production using credentials three people know by heart. Human and machine access tangled together so thoroughly that answering "what can this identity actually change?" becomes a research project — and under a CPS 234 audit, "we're not sure" is not an answer, it is a finding.

The uncomfortable truth is that account structure and identity are not two workstreams. They are two views of the same question: where does authority live, and what bounds it? A beautifully segmented account hierarchy means nothing if a single over-privileged identity can reach across every segment. Scoped, well-governed identities mean little if the accounts they operate in mix critical and trivial workloads. Banks that separate these decisions get scrutiny-proof answers to neither.

And scrutiny arrives. Not on your schedule — on an auditor's, or an attacker's, or a regulator's after an incident. Identity debt accumulates in silence precisely because nothing tests it until the day everything tests it at once.

The reframe: three sentences that should drive the whole design

Strip away the vendor reference architectures and the hundred-page design documents, and a bank-grade landing zone reduces to three claims. If your design makes these three sentences true, most of what follows is detail. If it makes them false, no amount of tooling above will compensate.

1. Account hierarchy defines blast radius

Every account boundary is a promise: a mistake in here stays in here. A leaked credential, a misconfigured security group, a runaway deployment script — the account is the container the damage lives in. That makes the hierarchy a risk-segmentation instrument, not a filing system.

Designed this way, the top-level split is not "Division A / Division B / Division C." It is criticality: critical operations with the tightest guardrails and tested tolerances, standard workloads with inherited baselines and bounded autonomy, sandboxes that are isolated, time-boxed, and structurally unable to accumulate production data. Under CPS 230, you are required to identify critical operations and keep them within tolerance through disruption. That obligation is radically easier to meet when critical operations live inside boundaries built for them — and close to impossible to evidence when they are scattered across boundaries built for reporting lines.

The test is simple. Pick your most critical workload. Can you state, structurally, what contains a compromise of its account? If the answer involves the words "well, it depends which resources," the hierarchy is not doing its job.

2. Identity defines authority

Accounts bound the damage; identity decides who can cause it. In a regulated bank, every identity — human or machine — should answer three questions on demand: who owns it (a named person, not a team alias), what can it change (an explicit scope, reviewed on a schedule), and what did it do (evidence produced continuously, not reconstructed after the fact).

The single most consequential move is separating the human and non-human planes. People get time-bound, role-scoped access: read by default, write through pipelines, elevation just-in-time and logged. Machines get single-purpose identities: a deployment identity that deploys one workload and nothing else, workload identities with short-lived credentials instead of shared secrets, platform automation that is powerful and therefore the most constrained thing in the estate. (In Azure terms: Managed Identity per workload, workload identity federation over client secrets. In AWS: IAM Roles for Service Accounts, no long-lived access keys in pipelines.)

Figure 2: Two identity planes, never sharing credentials, both mapped to the same authority record. Every identity has a named owner, an explicit scope, and a continuous evidence trail.

CPS 234 asks whether you maintain control over your information assets commensurate with the threats to them. Reread that with identity in mind: the regulator is not asking whether you have an identity product. They are asking whether you can demonstrate, today, that every credential capable of touching a critical system is owned, scoped, and observed. That is an architecture property, and it is set in the landing zone.

3. Inheritance enforces control

A control that depends on every team remembering to apply it is not a control. It is a hope with documentation. The mechanism that converts policy into reality is inheritance: controls attached high in the hierarchy, flowing down automatically, impossible to silently switch off below.

The root carries the non-negotiables — encryption at rest and in transit, immutable centralised audit logging, data residency boundaries, the identity baseline. Risk tiers add guardrails that tighten with criticality and never loosen. Workload accounts inherit the full stack, which is precisely what gives teams their speed: they deploy fast because the controls arrive pre-applied rather than being negotiated per project.

Figure 3: Controls flow down; they are never weakened below. The exception path is the design detail that decides whether the model survives contact with reality — visible, time-boxed, owned, and reported upward.

Exceptions deserve their own sentence, because exceptions are where governance models go to die. There will always be a workload that genuinely cannot comply yet. The difference between a governed estate and an ungoverned one is not the absence of exceptions — it is that every exception is visible, time-boxed, attached to a named owner, and reported upward until it either expires or becomes policy. The moment exceptions become quiet and permanent, your real governance model is no longer the one in the design document. It is the sum of the exceptions.

The pattern: four principles that survive contact with a bank

The three claims above translate into a small set of design principles. Not a reference architecture — your cloud provider has several, and they are good starting points — but the principles that determine whether any reference architecture actually holds up inside a regulated institution.

Design accounts as risk segmentation — and treat an org-chart hierarchy as a warning sign. Let criticality, data classification, and tolerance drive the structure. Cost reporting and team mapping are solvable with tags and metadata; blast radius is only solvable with structure. When the two conflict, structure follows risk, always.

Separate human and non-human identity from day one. Different planes, different lifecycles, different controls, never a shared credential between them. This is dramatically cheaper to build at the start than to untangle later — unwinding a shared production credential after three years of accumulated dependencies is a project; preventing it is a design line.

Require named owners for everything. Every account, every policy, every exception, every non-human identity maps to a person. Not a distribution list. Ownership is the difference between a control environment you can attest to and one you can only describe. When an auditor asks "who decided this and when do they review it," a name with a date is a one-line answer; anything else is a finding in progress.

Design to be boring under stress. This is the test that matters most and gets applied least. A landing zone proves its worth not during the demo but during the incident: at 3am, mid-breach, mid-audit, under a regulator's 24-hour notification clock for a critical operation outside tolerance. In that moment, can the structure answer what was affected, what contained it, who had access, and what the evidence shows — mechanically, from the architecture, without heroics? Boring under stress means no surprises in the hierarchy, no mystery identities, no controls whose actual state differs from their documented state. Excitement in infrastructure is just risk that has not introduced itself yet.

Why you cannot refactor this later

In every organisation I have seen deprioritise landing zone design, someone said the same thing early on: "we'll restructure once we've proven value." It sounds reasonable. It almost never happens, and the reason is structural rather than a matter of discipline.

Application code refactors because it has seams: interfaces, tests, deployment boundaries that let you change one piece while holding the rest still. A landing zone has no such seams. Accounts accumulate data, and data has gravity. Workloads accumulate network dependencies, and re-addressing them touches every peer. Identities accumulate implicit grants, and nobody can say with confidence what breaks when one is narrowed. Moving a single production workload to a new account in a bank — with change governance, evidence requirements, and tolerance obligations — is a project measured in months. Restructuring a hierarchy is that project multiplied across the estate. In practice: the plan gets scoped down, deferred, and quietly rebranded as "the target state" while the original structure keeps compiling its gaps into everything built on top.

I have seen a bank spend eleven months restructuring three accounts following a regulatory finding — six weeks of architectural work, the rest compliance evidence, change governance, data migration, and identity rewiring. The original design decision that made the restructure necessary took about two hours.

This is the asymmetry that should change how much design attention the landing zone gets: the decisions take weeks to make and years to unmake. In the maturity model from post four, foundations are the layer everything else stands on. This is why. Security, automation, operations, and value delivery can all be improved incrementally. Foundations are the one layer where the cost of being wrong compounds instead of amortising.

None of this means a bad landing zone is a life sentence. Remediation is possible and sometimes necessary. It means remediation is expensive enough that getting the three load-bearing decisions right the first time is one of the highest-return engineering investments a bank can make.

Diagnostic: six questions that reveal whether your landing zone governs anything

As with the maturity diagnostic in post four, these are pass/fail, and they are designed to be asked on a Monday morning.

• Can you apply a control to all critical operations — and only critical operations — at a single point in the hierarchy? If a new policy for critical workloads requires tag lists or per-account rollout, your structure cannot express your risk model.
• Does every account have a named owner who can state its criticality tier and data classification without looking it up? Unowned accounts are unowned risk.
• Can any human credential deploy directly to production? If yes, your change control has a bypass lane, and under scrutiny the existence of the lane matters more than how rarely it is used.
• For your most privileged non-human identity: who owns it, what exactly can it change, and when was its scope last reviewed? If answering takes more than a day, identity debt is already material.
• Can a workload team weaken an inherited control without anyone above them knowing? If drift is possible and silent, your controls are documentation.
• List your current policy exceptions: does each one have an owner, an expiry date, and a report line upward? If you cannot produce the list, the exceptions are your real governance model.

Two or more failures is not a tooling gap. It is a structural gap, and it belongs on a risk register — because structure is the one thing the next tool you buy will not fix.

The outcome: speed and defensibility are the same property

It is worth being precise about what a well-designed landing zone buys, because the payoff is routinely undersold as "compliance."

Teams onboard faster, not slower. When controls arrive by inheritance, a new workload lands inside a pre-governed envelope: no bespoke security review to schedule, no control negotiation per project, no waiting on a central team to hand-craft guardrails. The platform's answer to "can we start?" becomes yes by default, because the structure already enforced everything that previously required a meeting.

And decisions become defensible under audit. When an auditor or supervisor asks why a workload runs where it runs, with the controls it has, the answer reads straight out of the architecture: this is a tier-one critical operation, so it lives in the critical operations boundary, inheriting these controls, with this evidence trail and this named owner. No archaeology, no reconstruction, no depending on whoever remembers the 2023 decisions.

Those two outcomes are not a trade-off carefully balanced. They are the same property — structure doing the governing — observed from two directions. Get the structure right, and the engineers ship faster while the auditors find nothing. That is the whole argument.

Next in the series: your foundations will be tested by change

Earlier in this series, we covered why banking cloud is a different discipline, how prudential standards translate into design constraints, and where maturity gaps hide across the five layers. This post locked in the foundation layer: hierarchy as blast radius, identity as authority, inheritance as enforcement.

But foundations only define where risk is bounded. They do not decide how risk re-enters — and it re-enters the same way every time: through change. Every deployment, every pipeline run, every "small config update" is a fresh opportunity to put something inside your carefully designed boundaries that should not be there. Blog 6 covers the two engineering practices that make change itself a control surface: infrastructure-as-code that produces evidence as a by-product, and change governance that is attributable, reviewable, and reversible without killing velocity. Foundations define the boundaries. Change will test them.

Look at your own landing zone through today's lens: if you had to apply one new control to every critical operation tomorrow morning, could your hierarchy express it — or would you be reaching for tag lists and exceptions?