SOC 2 network security controls auditors expect
Network security under SOC 2 is increasingly a cloud question of security groups, segmentation, and identity rather than physical firewall appliances. Here is what CC6 and CC7 ask for and the evidence that holds up.
The criteria behind network security
Network controls draw mainly from the CC6 logical access group and the CC7 system operations group of the Trust Services Criteria. CC6.1 requires implementing logical access security software, infrastructure, and architectures over protected assets, which is where firewalls, security groups, and access architecture live, while CC6.6 specifically addresses protecting against threats from outside the system boundary, and CC6.7 covers restricting and protecting information in transit. CC7.1 and CC7.2 then pull network telemetry into detection, since intrusion detection and network monitoring feed the anomaly detection expected under system operations. Importantly, the criteria are written to be technology-neutral, so they describe boundary protection and segmentation as objectives rather than prescribing specific appliances. That neutrality is what lets a cloud-native architecture of VPCs and security groups satisfy the same criteria a traditional data-center firewall once did, provided you can show the controls achieve the objective.
Boundary protection and secure configuration
Auditors expect a defined and defended system boundary, which traditionally meant perimeter firewalls and a DMZ and today often means cloud-native controls such as AWS security groups and NACLs, Azure NSGs, or GCP firewall rules. Whatever the form, the control objective is the same: only explicitly permitted traffic crosses the boundary, ingress is restricted to the minimum necessary, and management interfaces such as SSH and RDP are not exposed to the open internet. Secure configuration matters as much as the rules themselves, so auditors look for hardened baselines, restricted default-allow rules, and periodic review of firewall and security-group configurations with documented sign-off. Next-generation firewalls and web application firewalls add deep packet inspection and application-layer filtering for organizations that need them, but a clean, least-privilege set of cloud security-group rules is fully credible evidence. The recurring finding here is overly permissive rules, such as a security group allowing 0.0.0.0/0 on a sensitive port, which is exactly the kind of misconfiguration an auditor will flag.
Segmentation and the zero-trust trend
Segmentation maps closely to CC6.6 and to the broader objective of limiting blast radius, and the most common and most-tested expression of it in SOC 2 is separating production from development and test environments. Auditors want that separation enforced at the network level rather than by convention, typically through distinct VPCs or subnets, distinct accounts, and security-group rules that prevent lateral movement between tiers. The industry trend is toward zero-trust networking, where a connection is authorized based on verified identity rather than network location, so a database in a production VPC does not implicitly trust a web server just because they share a subnet. Practically this shows up as microsegmentation, identity-aware proxies, and per-connection authorization for administrative access, and tools like service meshes or access proxies are increasingly cited as evidence. You are not required to adopt zero trust to pass SOC 2, but where you have implemented it, the identity-based authorization logs become strong evidence for both CC6 and CC7.
Detection at the network layer
Boundary controls keep traffic out; detection tells you when something got through or is probing, which is where intrusion detection and prevention systems and cloud-native equivalents come in. In cloud environments this often means VPC flow logs analyzed for anomalies, managed detection services such as AWS GuardDuty, and DNS filtering, feeding alerts into the same monitoring pipeline used for CC7.2. Auditors want to see not just that an IDS or detection service exists but that its alerts are reviewed and acted on, so IDS alert logs paired with documented response processes are far more persuasive than the mere presence of the tool. This is the join point between network security and the broader logging and monitoring program, and weakness in the review cadence here undermines both. A network that is well-segmented but generates detection alerts nobody triages is only half a control.
Evidence auditors request and common gaps
Plan to provide network architecture and data-flow diagrams showing trust zones and how production is segregated, firewall and security-group rule exports with periodic review sign-offs, and configuration evidence demonstrating least-privilege rules and hardened baselines. Auditors also commonly ask for change records tying network changes to your change management process, IDS or detection alert logs with response evidence, and proof that data in transit is protected with current TLS. Because this is a Type 2 examination, the diagrams and reviews need to reflect the period and ideally show a recurring review with dates and reviewers rather than a single point-in-time export. The predictable gaps are overly permissive security-group rules, production and non-production environments that share networks, architecture diagrams that no longer match reality, network changes made outside change management, and detection tooling whose alerts show no evidence of review. The cleanest programs keep an accurate diagram, a documented periodic review of network rules, and a clear link between segmentation design and the access and monitoring controls in the rest of the report.