The Landing Zone Is Where Lawful Operation Begins

What the landing zone protects

The landing zone is not abstract infrastructure. It is the specific set of controls that make the governance substrate trustworthy. Without it, the Responsibility Ledger is a database, not a governed record. Here is what depends on the foundation being correct.

Responsibility Ledger

Without immutable storage and tamper-evident logging, the chain of custody for every responsibility transfer has no evidentiary standing.

Consent and access artefacts

Without customer-managed encryption and UK residency, GP Connect consent records and access audit trails lack jurisdictional standing.

Evidence Fabric

Without cryptographic integrity and retention controls, evidence cannot be demonstrated to regulators on demand.

BALP audit events

Without CloudTrail, Object Lock, and immutable retention, the audit trail that records every system interaction has gaps.

GP Connect and NRL trust position

Without account separation and identity federation, the trust framework governing NHS record access cannot be maintained.

Clinical safety evidence

Without the landing zone, DCB 0129/0160 compliance artefacts and DUAA complaint response capability are scattered across ungoverned storage.

Foundation first: the deployment sequence

The sequence is non-negotiable. Priority 1 establishes the infrastructure baseline for NHS data. Priority 2 deploys the governance layer on that secure foundation. Priority 3 adds operational intelligence as the network expands. No clinical data enters the environment until Priority 1 controls are in place. No governed boundary goes live until Priority 2 controls are operational.

Landing zone controls: what makes evidence trustworthy

Foundational competence is not optional. Every governance invariant we enforce depends on the infrastructure beneath it being correct, secure, and structurally isolated. We treat landing zone architecture with the same rigour we apply to clinical safety cases. Each customer landing zone is built to a consistent pattern:

Claim authority: STATUTORY Law or mandatory standard ASSURANCE EXPECTATION NHS guidance and procurement IC POLICY Inference Clinical requirement

AWS Organisations and account structure

Separate accounts for governance, clinical workloads, data, and shared services. Organisational boundaries in the clinical domain map to AWS account boundaries in the infrastructure domain. This is account-level isolation, not just VPC boundaries. Each clinical workload operates in its own blast radius. Billing separation is built into the account structure. Per-organisation cost attribution means NHS Trust A never subsidises Trust B's infrastructure. STATUTORY

Consequence: a compromise in one organisation's workload cannot propagate to another's. The Responsibility Ledger's integrity is blast-radius contained.

Network isolation

VPC design that enforces the multi-organisation model. Traffic between organisations traverses governed integration points, never direct paths. Network segmentation supports NIS Regulations requirements for Operators of Essential Services. STATUTORY

Identity federation

AWS IAM integrated with healthcare identity providers. Practitioner authentication, patient identity resolution, and organisation trust relationships are wired into the infrastructure layer. Aligned with NHS Identity and spine integration requirements. ASSURANCE EXPECTATION

Security baseline

GuardDuty for threat detection, CloudTrail for API-level audit, Config Rules for continuous compliance. These are proactive defence, not compliance checkboxes. ASSURANCE EXPECTATION Cyber Essentials Plus controls embedded structurally. STATUTORY ALCOA+ audit trail integrity maintained through immutable logging.

Data breach prevention is structural: encryption at rest (KMS customer-managed keys) and in transit (TLS 1.2+), network segmentation that prevents lateral movement between organisation accounts, VPC flow logs for exfiltration detection, S3 bucket policies enforcing data residency in eu-west-2. Clinical data does not leave the UK because the infrastructure makes it impossible, not because a policy document says it should not.

AWS Organizations Service Control Policies (SCPs) enforce both security policy and clinical governance policy simultaneously. One SCP can prevent data leaving the UK region, block unapproved service deployment, and enforce tagging for clinical data classification in the same policy statement.

Consequence: every governed act is logged, encrypted, immutable, and demonstrable. The Evidence Fabric has evidentiary standing.

Observability

CloudWatch, X-Ray, and custom clinical observability pipelines. Not just infrastructure monitoring - clinical pathway monitoring that surfaces governance failures, not just system failures. ASSURANCE EXPECTATION LFPSE-ready incident detection for cross-boundary safety events.

Guardrails, not gates

The landing zone enforces policy through prevention (SCPs, permission boundaries, network rules) rather than detection-after-the-fact. Clinical data cannot leave the UK region because the infrastructure makes it structurally impossible. Unapproved services cannot be deployed because the account structure prevents it. This is the engineering controls over administrative controls principle applied to cloud infrastructure. IC POLICY

Consequence: compliance is not something you prove at audit. It is something the infrastructure enforces continuously.

For organisations with existing AWS workloads, the landing zone wraps around what exists. Existing workloads are assessed (see the Foundational Technology Review in the Assess phase), and the landing zone is designed to govern them progressively. For on-premises workloads, the governed landing zone becomes the migration target.

Three layers, each depending on the one beneath

UK Region (eu-west-2) DSPT/CAF Aligned DCB 0129/0160 DTAC Ready DUAA Compliant UK GDPR Cyber Essentials Plus ALCOA+ FHIR R4 UK Core Multi-AZ Encrypted at Rest NIS Regulations

The Constitutional Spine

The Architecture Stack shows three layers. The Constitutional Spine is the principle that keeps them separate. No component spans all three. No service can silently grant permission. This is enforced at build time and runtime, not by convention.

For the full Constitutional Spine, including the four anti-patterns and how they are structurally prevented, see the SafeMesh architecture page.

The Six R's: Migration Through a Governance Lens

Standard migration assessments classify workloads by technical complexity and cost. In healthcare, that is not enough. Every workload carries clinical boundary obligations, and choosing the wrong migration strategy creates patient safety risk, not just technical debt.

Move the application as-is to AWS.

Even a lift-and-shift gains boundary governance, DSPT/CAF alignment, and ALCOA+ audit trails the moment it lands on the governed landing zone. For many legacy clinical systems, rehosting onto governed infrastructure is the fastest path to regulatory coverage.

Make targeted optimisations during migration (e.g. move to RDS, Elastic Beanstalk).

Every replatform decision is evaluated against governance requirements, not just cost or performance. The consent model, audit trail, and provenance chain must survive the migration intact. A replatform that breaks consent enforcement is worse than a rehost that preserves it.

Replace with a different product, typically SaaS.

SaaS replacement shifts governance focus to boundary integration. The new product must participate in the consent graph and responsibility transfer protocols. DTAC applies to procured health IT. The boundary audit identifies what obligations transfer to the new vendor.

Re-imagine the application using cloud-native features.

Cloud-native rebuild is where governance-by-design delivers its greatest advantage. Event-driven patterns mean governance checks execute within the clinical pathway, not alongside it. The most expensive R, but for clinical systems crossing organisational boundaries, refactoring produces the strongest safety case.

Decommission applications no longer needed.

Governance mapping identifies clinical dependencies that IT asset registers miss. A system may look unused but still carry active responsibility transfer obligations. You cannot safely retire a system until you understand what clinical boundaries it participates in. Retirement is a governed act.

Keep in place for now.

Retained workloads are governed in place. The landing zone wraps around them. Retention is a conscious, documented decision with a review trigger and clear conditions under which migration becomes the right next step. It is not a deferral by default.

The boundary audit (Assess phase) produces the evidence to classify every workload. You cannot choose an R without understanding the clinical boundaries the workload participates in.

Our deployment stance

Inference Clinical will not deploy SafeMesh into environments that cannot demonstrate the required controls. This is not a commercial preference. It is a vendor responsibility position. A governance platform deployed on infrastructure without immutable logging, without encryption under customer control, without account separation, and without UK data residency creates the illusion of governance while leaving the underlying risk untouched.

We will not advise clients to skip the landing zone. We will not deploy into environments where the Responsibility Ledger's evidentiary value is compromised by the infrastructure beneath it. We will not treat the landing zone as an optional phase that can be revisited later.

This is the same principle the Constitutional Spine enforces at the software layer, applied at the infrastructure layer: governance must be non-bypassable, or it is not governance.

How we work with migration partners

Inference Clinical is not a migration partner. We are the governance layer that makes migration safe, compliant, and regulatorily sound.

From the migration partner

Infrastructure deployment
Workload migration
Re-platforming
Database migration
Cyber Essentials baseline

From Inference Clinical

Seven Flows governance
Clinical safety cases (DCB 0129/0160)
Consent infrastructure (UK GDPR, Caldicott)
Responsibility transfer protocols
DSPT/CAF compliance support
DTAC documentation
LFPSE integration
Boundary audit with statutory traceability

The consumption story: Governance without migration produces limited AWS consumption. Migration without governance produces non-compliant infrastructure. Combined, they produce governed cloud environments with growing workload footprints.

Frequently Asked Questions

How does the landing zone approach work for organisations with existing AWS workloads?

The landing zone wraps around what exists. Existing workloads are assessed against the Well-Architected Framework with a healthcare governance lens and cross-referenced against DSPT/CAF requirements. The landing zone is designed to govern existing workloads progressively, not require rip-and-replace. For on-premises workloads, the governed landing zone becomes the migration target, and every workload that moves onto it is governed from the moment it arrives.

How does the 6 R's migration framework apply in a healthcare governance context?

Each of the 6 R's (Rehost, Replatform, Repurchase, Refactor, Retire, Retain) has governance consequences in healthcare. A rehost onto a governed landing zone gains boundary governance and ALCOA+ audit trails immediately. A replatform must maintain consent enforcement and provenance traceability. A repurchase shifts governance focus to boundary integration and DTAC compliance. You cannot choose an R without understanding the clinical boundaries the workload participates in.

How does the migration partner model work with Inference Clinical?

Migration partners deploy landing zones and move workloads, bringing infrastructure engineering expertise. Inference Clinical deploys the governance middleware on top, bringing healthcare domain expertise, clinical safety framework compliance (DCB 0129/0160), regulatory traceability (DUAA, DSPT/CAF, DTAC, MHRA, CQC, FCA), and statutory obligations. Combined engagements deliver governed cloud environments with growing workload footprints.

What makes governance at the infrastructure level different from bolted-on compliance?

Inference Clinical controls the entire stack from the landing zone foundation upward. Governance invariants such as identity isolation, consent enforcement, provenance immutability, and responsibility transfer confirmation are structural properties of the environment, not configuration choices that can be overridden. A governance platform deployed on weak foundations does not just underperform. It creates the illusion of governance while leaving underlying risk untouched. That is why the landing zone is Phase 1, not a supporting prerequisite.

How does progressive governance work for existing workloads?

The governance platform integrates with existing systems through standard interfaces (FHIR R4 UK Core, HL7v2, SNOMED CT, dm+d, REST APIs). It does not require replacing clinical systems. It governs the boundaries between them. Where existing systems are on-premises, end-of-life, or non-compliant, the governed landing zone provides the migration target, and every workload migrated drives AWS consumption while gaining compliance from day one.

What is the Constitutional Spine and why does it matter for healthcare architecture?

The Constitutional Spine is the architectural principle that separates facts, evaluation, and acceptance into distinct layers - enforced at build time and runtime. No single component can silently grant permission. This structural separation prevents four anti-patterns common in healthcare IT: smart gateways that centralise all decisions, implicit authority based on identity alone, responsibility vacuums where actions proceed without acceptance, and silent evaluation where rules are applied without evidence trails.