Cloud network segmentation for audits
In the cloud, the strongest segmentation boundary is the account, subscription or project. Network rules inside it matter, but an auditor asking whether development can reach production wants to hear that they are in different accounts.
Cloud segmentation that satisfies an auditor separates production from non-production at the account or subscription level, keeps databases and internal services in private subnets with no public addresses, restricts inbound traffic to the load balancer, reaches provider services through private endpoints, and documents all of it in a current network diagram. Security group and firewall rules then control traffic inside that structure.
The layers of cloud segmentation
| Layer | AWS | Azure | Google Cloud | Separates |
|---|---|---|---|---|
| Account boundary | Accounts under Organizations | Subscriptions under management groups | Projects under folders | Environments, teams, blast radius |
| Network | VPC | Virtual network | VPC network | Workloads within an environment |
| Subnet tier | Public and private subnets | Subnets with NSGs | Subnets | Internet-facing from internal |
| Instance rules | Security groups | Network security groups, ASGs | Firewall rules and policies | Service to service |
| Service perimeter | VPC endpoints and endpoint policies | Private endpoints | Private Service Connect, VPC Service Controls | Access to managed services and data exfiltration |
Rules auditors look at
- No 0.0.0.0/0 on admin ports. SSH and RDP open to the internet is the most frequent cloud network finding. Use Session Manager, Azure Bastion or Identity-Aware Proxy instead.
- Databases with no public endpoint. Private subnets only, reachable from the application tier.
- Default rules removed. The default VPC or network in each region, and permissive default rules, should be deleted or locked down.
- Egress considered. Unrestricted outbound traffic is common. For sensitive workloads, restricting egress limits data exfiltration and is increasingly asked about.
When segmentation reduces scope
Under PCI DSS v4.0.1, segmentation can take systems out of scope, and the segmentation itself must then be tested: annually for merchants and every six months for service providers. In SOC 2 and ISO 27001 segmentation does not shrink scope in the same formal way, but it shrinks the number of systems an auditor needs to care about. PCI DSS in the cloud covers the testing requirement.
The network diagram
Auditors ask for a network diagram and compare it with what they see. Keep it generated or updated with the infrastructure code, showing accounts, VPCs, subnets, internet entry points, data stores and connections to third parties. A diagram from two years ago that shows a server you retired is worse than a simple current one.
Is a separate VPC enough to separate production from staging?
It separates the network, but anyone with account-level permissions can reach both. Separate accounts or subscriptions separate the access too, which is what auditors are really asking about. Use separate accounts for production and a separate VPC for each workload inside them.
Do we need a firewall appliance in the cloud for SOC 2?
No. Security groups, network security groups and firewall rules are accepted as boundary protection. A managed firewall service is worth it for egress filtering or inspection at larger scale, not as an audit requirement.
How do engineers reach private instances without SSH open?
AWS Systems Manager Session Manager, Azure Bastion and Google Cloud Identity-Aware Proxy provide authenticated, logged access without opening inbound ports. Each session is recorded, which is better evidence than SSH keys ever gave you.
Want your network reviewed?
Firms in the network review rules and redraw the diagram before an audit.
Get matched