What this control covers

Securely separates cloud customer data on shared resources per OIS-07 risk analysis, using documented approaches to ensure confidentiality and integrity. Prevents unauthorized access or data leakage in multi-tenant environments.

Why it matters

A well-architected cloud landing zone bakes most of these controls in at the platform layer — done well, individual workloads inherit security for free.

How to implement

AWS

Segment workloads into separate VPCs/accounts per environment. Use security groups as stateful allow-lists (least-port, source by SG ID not 0.0.0.0/0) and VPC Flow Logs to CloudWatch/S3. Front public services with AWS WAF + Shield Advanced and use PrivateLink/VPC Endpoints to keep service traffic off the internet.

Azure

Use Network Security Groups and Application Security Groups for east-west, and an Azure Firewall or NVA in a hub VNet for north-south. Enforce Private Endpoints for PaaS and turn on Defender for Cloud — Network for adaptive hardening recommendations.

GCP

Use VPC Service Controls to draw a perimeter around sensitive APIs and a hierarchical Firewall policy at the org/folder level so projects inherit a deny-by-default posture. Front HTTP workloads with the global Cloud Load Balancer + Cloud Armor.

Evidence to collect

  • infra_scan — See the iCompaas Evidence library for the canonical source for this evidence type.

Infrastructure posture tooling (AWS Config, Azure Policy, Nessus) verifies platform hardening. Focus: Separation of Datasets in the Cloud Infrastructure.

Quick checklist

  • Risk — - Configuration / Cloud Customer Data
  • Security — - Configuration / Cloud Customer Data
  • Confidentiality — - Configuration / Cloud Customer Data
  • Data — - Configuration / Cloud Customer Data
  • Separation — - Configuration / Cloud Customer Data
  • Access — - Configuration / Cloud Customer Data

Related articles on this site