An Azure landing zone is a pre-configured, enterprise-grade foundation for cloud deployments. It is not a single server or service, but a set of subscriptions, resource groups, policies, networking, security controls, and governance frameworks that are all wired together before a single workload goes live.
For NHS trusts, this is not optional. The NHS operates under strict regulatory requirements: HIPAA equivalence, NHS Data Security and Protection Toolkit (DSPT) compliance, and increasingly stringent Cyber Essentials+ certification. A landing zone ensures that every resource deployed to Azure automatically inherits these controls, rather than forcing teams to bolt security on later (which they rarely do properly).
Without a landing zone, your trust risks:
A well-designed landing zone is the difference between a controlled cloud migration and a firefighting operation.
Your landing zone begins with a decision about how to organise your subscriptions. The NHS model typically looks like this:
Each workload subscription gets its own resource group, tagged with cost centre, data classification (GP data, patient identifiable information), and responsible team. This enables:
The UK NHS tends to prefer this hub-and-spoke networking model because it centralises security monitoring (in the hub) and isolates clinical systems from each other (in the spokes).
Azure Policy is your enforcement engine. A landing zone includes pre-built policies that prevent non-compliant resource creation. Examples that matter to NHS trusts:
If a developer tries to create an unencrypted SQL database or an open-to-the-internet virtual machine, the policy prevents it at creation time. No exceptions, no workarounds. This is not about micromanagement; it is about making compliance automatic.
Most NHS trusts cannot move entirely to Azure in year one. They need to run hybrid workloads: some systems on-premises (epic EHR systems, legacy pharmacy software) and some in Azure (new analytics, modern appointment systems).
A landing zone includes:
The key principle: no clinical data crosses the internet unencrypted. All traffic to on-premises systems uses private circuits.
A landing zone wires in centralised logging on day one:
Every API call to Azure is logged. Every sign-in is recorded. This is not surveillance of staff; it is the audit trail required for DSPT and NHS auditors.
Azure AD (now Entra ID) becomes your central identity provider. A landing zone enforces:
This layer prevents the single biggest cloud breach vector: compromised credentials.
1. Map your current on-premises infrastructure and compliance obligations
2. Define your subscription strategy (how many, how grouped, who owns each)
3. Document your network topology (which systems talk to which)
4. Identify your data classifications (DSPT levels 1, 2, 3)
5. Get stakeholder sign-off from IT, information governance, and clinical leads
1. Create management subscription and assign Azure Policy
2. Create identity subscription, configure Azure AD, enforce MFA
3. Create connectivity subscription, build hub VNet, configure firewall rules
4. Deploy monitoring and logging infrastructure
5. Test connectivity between on-premises and Azure using a non-production link
1. Create workload subscriptions
2. Peer workload VNets to the hub
3. Deploy pilot workload (non-critical system) to test landing zone controls
4. Gather feedback, adjust policies if needed
5. Begin migrating additional workloads
The entire process typically takes 12 to 16 weeks for a medium NHS trust.
Pitfall 1: Over-centralised security. If every change requires approval from a central team, teams slow down and lose trust in the cloud. Instead, design policies that allow safe automation (e.g. "developers can create VMs but only in this subnet with this base image").
Pitfall 2: Undersized logging. Log Analytics ingestion costs money. Some trusts disable logging to save pounds now and regret it during an audit. Budget for logs and keep them for the full retention period (often 2 years for NHS).
Pitfall 3: Inconsistent naming. If resources have cryptic names, no one can find them and mistakes happen. Enforce a naming convention via policy from day one (e.g. `wm-prod-sql-001` for Wolverhampton production SQL server 001).
Pitfall 4: Forgetting hybrid networking. Cloud-only architectures are rare in the NHS. If your landing zone does not account for on-premises connectivity and secure data transfer, you will have a fragmented, insecure hybrid estate.
If you are a nurse, pharmacist, or allied health professional considering a move into cloud infrastructure, this is your moment. Healthcare workers understand NHS compliance requirements better than external cloud architects. You know why DSPT matters, what patient confidentiality actually means in practice, and how to talk to clinicians about security without triggering pushback.
Azure infrastructure roles are growing in the NHS faster than the talent can keep up. A cloud infrastructure engineer with healthcare experience can command a salary between £45,000 and £65,000 in 2026, depending on region and experience.
If you want to move into this space, start with the CompTIA A+ (foundational IT knowledge), then the Azure Administrator Programme. The Azure course specifically covers landing zone design, governance, and compliance.
Book a free 2-hour live session to see the Azure modules in action and talk through your career pathway with an instructor who has built landing zones in NHS trusts.
Yes. A landing zone is the foundation that prevents that one system from becoming a compliance liability. Even a small deployment needs governance, logging, and security controls. A minimal landing zone takes 6 weeks to deploy and costs less than the risk of an audit finding.
Yes, Microsoft publishes the Azure landing zone accelerator (open source, free). It provides a foundation for policy, networking, and governance that you then customise for NHS requirements. Most NHS trusts use it as a baseline and add DSPT-specific policies on top.
A minimal landing zone costs between £800 and £2,000 per month in compute and storage, depending on logging volume and connectivity choice (VPN is cheaper than ExpressRoute). The largest cost is often Azure Firewall and Log Analytics ingestion if you log heavily. Budget for 18 months of operation before ROI appears.
Ownership should be split: IT infrastructure team owns the hub (networking, firewall, centralised logging), each department owns its own workload subscriptions (but cannot modify policies). A governance group meets monthly to review policies and approve exceptions.
Plan for 12 to 16 weeks from project kickoff to first workload in production. This includes planning, infrastructure deployment, testing, security review, and pilot workload validation. Rushing this phase is the most common cause of later compliance failures.
SmoothOps 365 runs live instructor-led training every Saturday and Sunday. 3 months. 50 contact hours. Keep your job while you train.