4.5.3. Zero Trust, Cloud, and Technologies Under the Security Manager's Purview
💡 First Principle: A network perimeter once approximated a trust boundary because the users, devices and data were all inside it — once users work from anywhere and data lives in services the organization doesn't own, network location stops telling you anything about trustworthiness, and trust has to be decided per request.
Zero trust is the architecture response to that shift. NIST SP 800-207 defines it as an approach in which no implicit trust is granted to assets or user accounts based solely on their physical or network location. Every access request is authenticated and authorized, per session, using as much context as is available — identity, device health, the sensitivity of the resource, and behavior. Architecturally, a policy decision point (the policy engine and policy administrator) decides whether to allow a request, and a policy enforcement point sits in front of the resource and carries out that decision.
For a manager, three points matter more than the component names:
- Zero trust is a strategy and a migration, not a product. Vendors sell components; no single purchase makes an organization "zero trust." Adoption is typically incremental, starting with the most sensitive resources and the identity foundation it depends on.
- Identity becomes the primary control plane. Strong identity governance (accurate joiner-mover-leaver processes, MFA, privileged access management) is a prerequisite; zero trust built on a poorly governed directory just enforces bad decisions consistently.
- It does not remove segmentation. Microsegmentation is one of the ways zero trust is implemented; the principle changes what trust is based on, not whether boundaries exist.
Cloud shared responsibility is the other architecture fact a security manager must get right. The provider secures the underlying infrastructure, and the customer always remains responsible for its data, its identities and access decisions, and how it configures the services it uses. How much falls to each party shifts with the service model: under IaaS the customer manages operating systems and applications; under SaaS the provider runs almost everything but the customer still owns user access, data classification and configuration. Moving a system to the cloud transfers operation of some controls, never accountability for the data — the same principle as any other outsourcing (4.4.2).
The new outline describes these areas as "the technologies under a security manager's purview." That is a management-level understanding: what each technology is for, what risk it addresses, what it depends on, and how to tell whether it is working.
| Technology | Risk It Addresses | What the Manager Needs to Govern |
|---|---|---|
| Identity and access management (IAM), MFA, PAM | Unauthorized access, privilege misuse | Access review cadence, privileged account inventory, joiner-mover-leaver timeliness |
| Network security (firewalls, segmentation, secure remote access) | Lateral movement, exposure to external networks | Rule review, alignment of zones to classification |
| Endpoint protection (EDR) | Malware, compromised devices | Coverage of the device estate, alert handling |
| Logging and SIEM | Undetected incidents | Log source coverage, retention, detection use cases tied to top risks |
| Encryption and key management | Data disclosure | Key ownership, rotation, separation of key custody from data |
| Data loss prevention | Exfiltration of classified data | Tuning tied to classification (4.1.2), ownership of alerts |
| Cloud security posture management | Misconfiguration in cloud services | Baselines, drift remediation, ownership across accounts |
The pattern behind every row is the same discipline as 4.3: a technology is not a control until it covers the assets in scope, has an owner, and is measured by an outcome.
⚠️ Exam Trap: Cloud migration scenarios often include an option suggesting the provider is now responsible for securing the organization's data, or that the provider's certifications (such as an ISO/IEC 27001 attestation) cover the customer's configuration. Under shared responsibility, the customer remains accountable for its data, identities and configuration; a provider attestation covers the provider's side of the line only.
Reflection Question: Leadership asks you to "buy zero trust" this quarter after reading about it. What would you need to have in place before any zero trust component could deliver its intended value, and how would you explain why it is a multi-year program?
