Segregation in virtual computing environments

“Segregation in virtual computing environments” is a requirement about preventing one tenant’s workloads, data, and administrative control from bleeding into another tenant’s environment in a multi-tenant cloud. The practical question a CCO or GRC lead must answer is simple: if two different customers share underlying infrastructure, what stops a misconfiguration, compromised credential, or platform flaw from allowing cross-tenant access?

ISO/IEC 27017 CLD.9.5.1 is short, but examiners interpret it broadly. They will expect you to address isolation across the full stack, including the management plane (where most blast-radius failures happen), not just network segmentation. They will also expect clarity on who owns which control when you are a cloud service customer relying on a cloud service provider, or when you are the provider serving multiple customers.

This page translates the requirement into concrete implementation steps, evidence to retain, common audit hangups, and a practical execution plan. The goal is fast operationalization: you should be able to assign owners, create a control checklist, and start collecting proof without re-litigating cloud architecture debates.

Regulatory text

Requirement (excerpt): “A cloud service customer's virtual environment running on a cloud service shall be protected from other cloud service customers and unauthorized persons.” ¹

Operator interpretation (what you must do)

You must ensure effective isolation so that:

• Other tenants cannot access your tenant’s data or control plane, intentionally or accidentally.
• Unauthorized persons cannot access the virtual environment, including via shared management interfaces, APIs, or administrative tooling.
• Isolation is demonstrable, meaning you can show architecture, configuration, and test results that support your segregation claims.

This is not limited to “put workloads in separate VPCs/VNETs.” Examiners will probe management plane permissions, shared services, logging, encryption boundaries, and how you prevent lateral movement between tenants.

Plain-English interpretation of the requirement

Treat each customer environment as a separate security domain, even if you share physical hardware. Segregation means one tenant’s identities, network traffic, storage objects, secrets, images, snapshots, logs, and administrative actions cannot cross into another tenant unless explicitly authorized and controlled.

If you are a cloud service provider, you need platform-level isolation plus operational safeguards (secure provisioning, hardened multi-tenant services, and strong admin access controls). If you are a cloud service customer, you need tenant design and guardrails that prevent “self-inflicted” cross-environment exposure (for example, an overly permissive IAM policy, a peered network without controls, or a shared CI/CD role that can touch multiple tenants).

Who it applies to

Entity types

• Cloud Service Providers (CSPs): You host multiple customer environments on shared infrastructure and must provide isolation and protections.
• Cloud Service Customers: You run your virtual environment on a cloud service and must configure and operate it safely within the provider’s boundaries. ¹

Operational contexts where this requirement becomes high-stakes

• Multi-tenant SaaS platforms with logically separated customer tenants.
• Managed hosting or PaaS where underlying worker nodes are shared.
• Kubernetes clusters (shared or dedicated) and container multi-tenancy.
• Shared CI/CD, shared identity directories, shared logging/monitoring platforms.
• Environments with third-party administrators, MSPs, or contractors who have privileged access.

What you actually need to do (step-by-step)

Step 1: Define the segregation boundary and threat model

1. Declare what “tenant” means in your environment. Examples: account/subscription, project, namespace, VPC/VNET, or SaaS tenant ID.
2. Document your isolation objectives across these planes:
   • Identity and access (IAM)
   • Management plane and APIs
   • Network
   • Compute/virtualization layer
   • Storage and backups
   • Observability (logs/metrics/traces)
3. Map shared components (bastions, CI runners, central logging, shared KMS, shared databases) and decide whether they are allowed. If allowed, define compensating controls.

Deliverable: “Tenant Segregation Design” document and a diagram set that shows boundaries and trust zones.

Step 2: Implement tenant isolation controls by layer

Use a layered approach. Auditors react well to a table that shows control intent, implementation, and evidence.

A. Identity / IAM

• Separate tenants with separate identity scopes where feasible (separate accounts/subscriptions or clearly separated projects).
• Enforce least privilege with tenant-scoped roles. Avoid wildcard permissions that span tenants.
• Require strong authentication for privileged roles and administrative consoles.
• Implement break-glass access with approvals and logging.

B. Management plane

• Restrict who can call management APIs that can enumerate or modify other tenants.
• Centralize admin access through a controlled entry point (bastion/jump host, privileged access management workflow, or tightly controlled SSO groups).
• Monitor and alert on cross-tenant administrative actions (for example, actions taken by roles intended to be tenant-scoped).

C. Network

• Default to no connectivity between tenants.
• If connectivity is required (shared services), use explicit routing, firewall rules, and service-to-service authentication with narrow scope.
• Segment inbound/outbound egress by tenant where practical to prevent data exfiltration paths from becoming shared.

D. Compute / virtualization

• If you are a provider: maintain hardening and patching of the virtualization layer, and define controls to prevent tenant escape.
• If you are a customer: choose isolation primitives appropriate to sensitivity (dedicated nodes/hosts, separate clusters, or strict namespace/pod security and network policies in Kubernetes). Document the rationale.

E. Storage, backups, and snapshots

• Use tenant-scoped storage containers/buckets and tenant-scoped encryption controls.
• Ensure backups and snapshots do not become a cross-tenant data path (access controls, restore permissions, and key separation).
• Restrict who can copy/export images or snapshots across tenants.

F. Observability

• Prevent logs from one tenant being visible to another tenant (log indexing, RBAC, and redaction).
• Treat tracing/telemetry carefully; it can leak identifiers and payload fragments if not segregated.

Step 3: Add preventive guardrails (policy-as-code and CI/CD checks)

Controls fail at scale without automation. Implement:

• Config rules that detect cross-tenant IAM permissions, shared security groups, open peering, overly broad KMS permissions, and public exposure.
• Deployment pipelines that block infrastructure changes violating isolation rules.

Daydream can help here by turning the requirement into a control checklist, assigning owners, and tracking evidence requests and reviews across third parties and internal teams without losing auditability.

Step 4: Prove segregation through testing

Do not rely on design intent alone.

• Run access tests that validate a tenant identity cannot read/modify another tenant’s resources.
• Conduct negative tests for common misconfigurations (shared roles, permissive resource policies, mis-scoped service accounts).
• Validate backup/restore cannot cross boundaries without explicit elevated approvals.

Tip: Write the tests like an auditor: “From Tenant A, show me you cannot list Tenant B’s storage objects.”

Step 5: Operationalize monitoring, incident response, and change management

• Alert on cross-tenant access attempts, privilege escalations, and unusual management plane actions.
• Add segregation checks to change review for network, IAM, shared services, and logging platform changes.
• Update incident runbooks to include a “cross-tenant exposure” decision tree: containment steps, scoping, customer notification triggers, and evidence preservation.

Required evidence and artifacts to retain

Keep evidence that is specific, time-bound, and reproducible.

Core artifacts

• Tenant segregation architecture diagrams (data plane + management plane).
• Tenant boundary definition and shared responsibility notes (provider vs customer).
• IAM role matrix showing tenant-scoped permissions and admin separation.
• Configuration exports/screenshots for:
  • Network segmentation (routing, firewall rules, peering settings)
  • Storage access policies
  • Logging/observability access controls
• Policy-as-code rules and CI/CD guardrails (rule definitions + deployment logs).
• Test plans and test results for cross-tenant access attempts.
• Monitoring/alert rules and sample alerts (or evidence of periodic review).
• Change management tickets for segregation-impacting changes.

Common exam/audit questions and hangups

• “Show me how Tenant A is prevented from accessing Tenant B’s data.”
• “Where is the management plane controlled, and who has access?”
• “Do you have any shared admin roles across tenants? Why are they necessary?”
• “How do you prevent backups, snapshots, or logs from becoming a cross-tenant leak?”
• “What happens if a privileged credential is compromised? What is the blast radius?”
• “How do you validate segregation after changes?”

Auditors often get stuck on one point: your platform may be logically segregated, but your operational access model is not. If engineers can “just switch tenants” with the same role, you need compensating controls, approvals, and tight logging.

Frequent implementation mistakes (and how to avoid them)

1. Relying on network segmentation only. Fix: treat IAM and management plane as first-class isolation layers.
2. Shared “admin” roles across tenants without controls. Fix: separate roles, approval workflows, and explicit break-glass with session logging.
3. Central logging that is not tenant-aware. Fix: enforce RBAC at the index/workspace level and test it.
4. Backups and snapshots accessible broadly. Fix: restrict restore/export permissions; separate keys or key scopes where feasible.
5. Kubernetes multi-tenancy without hard boundaries. Fix: combine namespace RBAC, network policies, admission controls, and a clear decision on shared vs dedicated clusters.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied source catalog, so you should treat ISO/IEC 27017 CLD.9.5.1 primarily as an audit and assurance expectation rather than a cited enforcement pattern. The risk remains material: segregation failures can become cross-customer data exposure, which triggers incident response obligations, contractual breaches, and loss of trust.

Practical 30/60/90-day execution plan

Time-boxing helps, but your pace depends on environment complexity and ownership clarity. Use these phases as an execution blueprint.

First 30 days (Immediate)

• Inventory tenants, environments, and shared services; define the segregation boundary.
• Identify “highest blast radius” roles and shared admin access paths.
• Produce diagrams for management plane, network, and data stores.
• Create an evidence register: what you will show an auditor and where it lives.

Next 60 days (Near-term)

• Implement or tighten IAM tenant scoping, break-glass procedures, and admin access logging.
• Add baseline guardrails for the most common isolation failures (IAM, peering, public exposure, shared storage policies).
• Run initial segregation tests and record results; fix the top findings.
• Update change management checklists to flag segregation-impacting changes.

Next 90 days (Operationalize)

• Expand testing to cover backups/snapshots, logging access, and shared CI/CD roles.
• Add monitoring and alerting for cross-tenant access attempts and suspicious management actions.
• Establish a recurring review cadence: tenant access reviews, guardrail exceptions, and evidence refresh.
• Centralize control tracking and evidence collection in a system (Daydream can help keep each control mapped to artifacts, owners, and review notes for audit-readiness).

Frequently Asked Questions

Do we need dedicated hosts to meet segregation in virtual computing environments?

Not always. The requirement is to protect each customer’s virtual environment from other customers and unauthorized persons; you can meet it with strong logical segregation if it is well-designed, configured, and tested ¹.

As a cloud service customer, can we rely entirely on our cloud provider’s isolation?

You can rely on the provider for underlying virtualization and platform controls, but you still own configuration inside your tenant (IAM, network rules, storage policies, logging access). Document the shared responsibility boundary and retain provider assurance materials where available ¹.

What evidence is most persuasive to auditors?

Configuration evidence plus test results. Diagrams and policies help, but auditors usually want exports/screenshots of tenant scoping controls and proof that cross-tenant access attempts fail.

How do we handle shared services (central logging, shared CI/CD, shared security tools) without failing segregation?

Treat shared services as a separate zone with strict RBAC, tenant-specific views, and controlled data flows. Then test that a tenant operator cannot access another tenant’s logs, artifacts, or secrets through the shared service.

What’s the fastest way to find segregation gaps?

Start with privilege and connectivity. Review IAM roles for cross-tenant permissions, then review network peering/routing and shared storage policies; these are common sources of accidental cross-tenant reach.

How should we document exceptions where strict segregation is not feasible?

Write an exception with scope, business rationale, compensating controls, and an expiration or review trigger. Link the exception to evidence (approvals, monitoring, and test results) so it stands up in an audit.

Footnotes

1. ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services