A Zero Trust strategy governs access to business services and data through explicit, least-privilege decisions that are reassessed as risk and context change. Cloud platforms provide many of the capabilities needed to implement it, including identity and access management, isolation between environments, encryption, policy enforcement and logging. Under the shared responsibility model, the provider secures the platform itself, and the organisation decides how those capabilities are configured and governed. Those decisions follow business priorities, with the strongest controls applied where unauthorised access would cause the greatest harm.
Protecting privileged and workload identities
Administrative identities can change other controls. The people, automation pipelines and service roles that hold those permissions can open network paths, alter logging or grant access across environments, so a compromised administrative identity can reach well beyond its owner's role. Protecting them is a priority alongside access to sensitive data, with the weight given to each depending on the business and the permissions involved.
Privileged access is granted for a defined task and a limited period, and multi-factor authentication applies to human administrators. High-impact changes require independent approval. Dedicated emergency administrator identities provide access if normal administration fails. Their use is monitored and reviewed, and their availability is tested. Workload identities, which allow services to call one another, receive narrowly scoped permissions and short-lived credentials.
Boundaries that limit reach
Separate accounts or subscriptions can limit the spread of an incident when cross-boundary access and shared dependencies are tightly governed. Giving a service its own environment is a design choice, made according to its criticality and dependencies. The mechanisms also differ. An AWS account and an Azure subscription carry different security properties, and the design reflects the platform in use.
Keeping production apart from development and testing reduces the paths into live systems and data, provided access between them is controlled explicitly. Within each environment, network rules deny traffic by default and permit defined paths between named services. Those paths rest on evidence of how each service communicates and what access it needs, which discovery establishes. A permitted network path provides connectivity. Access to the service still requires authentication and authorisation, with permissions reassessed as relevant identity, device or workload context changes.
Central guardrails under continuous testing
Central guardrails enforce common requirements within a defined scope. They can restrict which regions may be used, protect logging configuration and require encryption for data at rest and in transit. Their reach differs by platform, and each platform documents what its guardrails do not cover. Leadership needs evidence of their coverage, approved exceptions and any changes that weaken enforcement.
Written as code and held under version control, guardrails can be reviewed, tested and applied consistently across the platforms an organisation runs, including multi-cloud and sovereign cloud estates, through each platform's own mechanisms.
Keeping the design true over time
A cloud estate can change daily. Each new integration, supplier connection or platform update can widen access that was precisely defined, and the effect accumulates unless each change is checked. Changes to access and network rules are reviewed against the approved target design before they are made, and access is reassessed as services and risks change.
Protected logs, policy test results and records of approved exceptions give leadership evidence of how access is governed and where controls need attention. Monitoring for interrupted logging, policy drift and unauthorised changes helps establish whether the design continues to operate as intended.
What the board should expect to see
Oversight of Zero Trust in the cloud rests on a few questions with evidenced answers.
- Who holds privileged access to the cloud estate, and how is it limited and monitored?
- Which critical services sit in separate environments, and how is access across their boundaries governed?
- What do the central guardrails cover, and which exceptions are approved?
- How are changes to access reviewed?
- What evidence shows that controls limit unauthorised access to critical services?
- Which material gaps require investment or explicit risk acceptance?
Zero Trust starts with discovery and prioritisation covers where to begin. Continuous governance at scale shows centralised guardrails and a controlled network design applied to a media group's cloud estate across three countries. A Cloud Security Governance Review establishes whether your cloud governance operates as designed.
References
- National Institute of Standards and Technology, Special Publication 800-207, Zero Trust Architecture, August 2020.
- Amazon Web Services, Zero Trust on AWS.
- Amazon Web Services, AWS Organizations service control policies.
- Microsoft, Azure Policy overview.
- Amazon Web Services, Shared Responsibility Model.
- Microsoft, Shared responsibility in the cloud.