SOC 2 network security is an area where companies often overthink the requirements or underthink the implementation. Some organizations assume they need enterprise-grade network appliances and dedicated security operations centers. Others assume that because they're "in the cloud," network security is their cloud provider's problem. Neither assumption is correct, and both lead to audit findings.

The Trust Services Criteria covering network security — primarily CC6.6 and CC6.7 — don't prescribe specific tools, firewall brands, or network architectures. What they require is that you've identified the risks to your network environment, implemented controls to address those risks, and can demonstrate that those controls are operating effectively. Whether you accomplish that with a $200,000 next-generation firewall or with cloud-native security groups and VPC configurations doesn't matter to your auditor. What matters is that your approach is documented, appropriate for your risk profile, and backed by evidence.

This guide covers what SOC 2 actually requires for network security, how to implement those requirements using the tools most SaaS companies already have, and how to collect the evidence your auditor will request. If you've been putting off network security because the requirements feel vague or the solutions feel expensive, this post will give you a practical path forward that works for companies of any size.

Understanding CC6.6 and CC6.7 for Network Security

SOC 2 addresses network security through two primary criteria that, while related, cover different aspects of how your network protects data and systems.

CC6.6 — Logical Access Security Measures

CC6.6 requires that the organization restricts logical access to its information assets through security measures that protect against threats from sources outside the system boundaries. In plain language, this means controlling who and what can access your systems from outside your network.

For cloud-hosted SaaS companies, "outside the system boundaries" includes the public internet, other VPCs or cloud accounts, third-party integrations, employee home networks, and any other network that isn't part of your controlled environment. CC6.6 requires that you have mechanisms in place to prevent unauthorized access from all of these sources.

The practical implementation of CC6.6 typically involves network perimeter controls such as firewalls or security groups, network segmentation that separates production from non-production environments, access controls on management interfaces and administrative ports, VPN or zero-trust network access for administrative activities, and monitoring for unauthorized access attempts.

CC6.7 — Data Transmission Protection

CC6.7 focuses on protecting data during transmission. It requires that the organization protects information during transmission, including transmission over the internet and other communication networks, from unauthorized access.

This criterion drives your encryption-in-transit requirements. For most SaaS companies, CC6.7 implementation includes TLS 1.2 or higher for all external communications, encrypted connections for internal service-to-service communication, secure protocols for database connections, encrypted channels for administrative access such as SSH and HTTPS, and certificate management practices. The specifics of encryption requirements are covered in detail in our encryption standards guide, but the network security controls that support those encryption requirements — ensuring that unencrypted communication channels don't exist and that certificates are properly managed — fall under your network security program.

Network Architecture for SOC 2

Your network architecture is the foundation of your network security controls. A well-designed architecture makes individual security controls more effective and easier to demonstrate to auditors.

Network Segmentation

Network segmentation is the practice of dividing your network into isolated zones, each with its own security controls and access restrictions. For SOC 2, segmentation serves two purposes: it limits the blast radius of a security incident, and it reduces your audit scope by clearly defining which network segments are in scope.

Production environment should be isolated from all other environments. Production databases, application servers, and infrastructure management systems should exist in their own network segment with strict access controls. No development or testing traffic should touch production network resources.

Staging and QA environments should be separate from production and ideally separate from each other. Staging may mirror production architecture, but it should never share network resources with production. If staging has less restrictive access controls than production (which is common), shared network resources would undermine your production security posture.

Development environments should be the most isolated from production. Developers typically need broader access within development, and that broader access should never bleed into production through shared network segments, peered VPCs, or common security groups.

Management and monitoring infrastructure — your CI/CD systems, monitoring platforms, logging infrastructure, and administrative tooling — needs carefully considered placement. These systems often require access to production for legitimate operational purposes, but that access should be narrowly scoped through security groups and network policies rather than broad network-level access.

Cloud-Specific Architecture

For companies running on AWS, GCP, or Azure, network segmentation translates to cloud-native constructs.

VPCs (Virtual Private Clouds) provide the broadest level of isolation. Best practice is separate VPCs for production, staging, and development. If you use a single VPC, use subnets and security groups aggressively to achieve equivalent isolation.

Subnets divide your VPC into smaller network segments. Use private subnets for resources that don't need direct internet access (databases, internal services) and public subnets only for resources that must be internet-facing (load balancers, API gateways). Production databases should never sit in public subnets.

Security groups act as virtual firewalls for individual resources. Configure security groups with the principle of least privilege — only allow the specific ports, protocols, and source IP ranges that each resource actually needs. Default-deny is the correct posture. A security group that allows all inbound traffic on all ports from all sources is a finding waiting to happen.

Network ACLs provide an additional layer of network-level filtering at the subnet level. While security groups are stateful (they track connections), NACLs are stateless and can serve as a backup control layer.

Network Diagrams

Your auditor will want to see a current network diagram that accurately represents your architecture. This diagram should show all major network segments and the trust boundaries between them, the flow of data between segments, internet-facing entry points, connections to third-party services and cloud providers, administrative access paths, and monitoring and logging infrastructure.

The diagram doesn't need to show every individual server or container — it needs to show the architecture clearly enough that your auditor can understand how data flows through your environment and where security controls are applied.

Keep your network diagram current. An architecture diagram from two years ago that doesn't reflect your current infrastructure creates more problems than having no diagram at all. Review and update your diagram at least quarterly and whenever significant infrastructure changes are made.

Firewall Requirements and Implementation

Firewalls are the most visible network security control and one of the first things auditors evaluate. In cloud environments, "firewall" typically means a combination of security groups, network ACLs, cloud-native firewalls, and potentially web application firewalls.

Default-Deny Posture

The fundamental firewall principle for SOC 2 is default-deny: block everything by default and explicitly allow only the traffic that's needed for legitimate business operations. This applies to both inbound and outbound traffic.

Inbound rules should explicitly define which ports and protocols are allowed from which sources. Your web servers might allow HTTPS (port 443) from the internet. Your database should only allow connections from your application servers' security group. Your SSH access should be restricted to your VPN or bastion host IP range.

Outbound rules are often overlooked but equally important. If a system is compromised, unrestricted outbound access allows the attacker to exfiltrate data freely. Restrict outbound traffic to the destinations and ports that each system legitimately needs. Yes, this is harder to manage than allowing all outbound traffic. Yes, it's worth it.

Firewall Change Management

Changes to firewall rules should follow your change management process. This is one of the controls auditors specifically sample because firewall changes directly affect your security posture.

Document each firewall rule change with a description of what changed and why, who requested the change, who approved the change (someone other than the requester), the date the change was implemented, and evidence that the change was tested. For most cloud environments, infrastructure-as-code tools like Terraform or CloudFormation provide a natural audit trail for security group changes through version control. Your auditor will appreciate being able to see the Git history of your security group definitions rather than manually reviewing console change logs.

Web Application Firewalls

A web application firewall (WAF) protects your web applications from common attack patterns like SQL injection, cross-site scripting, and other OWASP Top 10 vulnerabilities. While SOC 2 doesn't explicitly require a WAF, it's a control that auditors view favorably because it demonstrates defense-in-depth for internet-facing applications.

Cloud-native WAF options include AWS WAF, Azure Web Application Firewall, and Google Cloud Armor. Third-party options include Cloudflare WAF and Fastly Signal Sciences. For most SaaS companies, a cloud-native WAF with managed rulesets provides adequate protection without the complexity and cost of a dedicated WAF appliance.

Intrusion Detection and Prevention

SOC 2 requires that you have the ability to detect unauthorized access attempts and other security events on your network. This is where intrusion detection systems (IDS) and intrusion prevention systems (IPS) come in.

Cloud-Native Detection Options

Modern cloud providers offer built-in threat detection services that satisfy SOC 2 requirements without deploying and managing dedicated IDS/IPS appliances.

AWS GuardDuty analyzes VPC flow logs, DNS logs, and CloudTrail events to detect threats including unauthorized access attempts, compromised instances communicating with known malicious IPs, unusual API calling patterns, and cryptocurrency mining activity. GuardDuty is straightforward to enable, reasonably priced, and provides the kind of automated threat detection that auditors expect to see.

Google Cloud Security Command Center (SCC) provides similar capabilities for GCP environments, including threat detection, vulnerability scanning, and security configuration monitoring. The premium tier includes container threat detection and additional security analytics.

Azure Microsoft Defender for Cloud offers threat detection, vulnerability assessment, and security recommendations across Azure workloads. It integrates with Azure Sentinel for more advanced security analytics and SIEM capabilities.

What to Alert On

Not every detected event requires an alert. Configure your detection systems to alert on events that indicate genuine security concerns. High-priority alerts should include successful access from unusual geographic locations, repeated authentication failures followed by success suggesting credential stuffing, outbound connections to known malicious IP addresses or domains, changes to security groups or network ACLs outside of approved change windows, unusual data transfer volumes suggesting exfiltration, and new privileged API calls from IAM users that don't typically make them. Configure alert routing so that security-relevant alerts reach your incident response team through PagerDuty, Slack, or email, and ensure they're acknowledged within defined timeframes.

For a comprehensive view of security tools that support SOC 2 compliance, including network security alongside other control categories, our dedicated tools guide covers the full landscape.

Network Monitoring and Logging

Network-level logging provides the evidence trail that demonstrates your network security controls are operating and captures the data needed for incident detection and forensic investigation.

VPC Flow Logs

VPC flow logs capture information about IP traffic flowing to and from network interfaces in your cloud environment. They're essential for SOC 2 because they provide evidence of network-level access patterns and enable detection of unauthorized access attempts.

Enable flow logs on all VPCs that contain production resources. Configure them to capture both accepted and rejected traffic — rejected traffic is particularly valuable because it shows that your firewall rules are blocking unauthorized access attempts.

Store flow logs in a central logging repository with appropriate retention periods. Most SOC 2 auditors expect at least 90 days of log retention, though some prefer 180 days or more. Ensure logs are stored in a tamper-proof or append-only configuration so they can't be modified after the fact.

DNS Logging

DNS logs capture domain name resolution queries from your systems. They're valuable for detecting connections to known malicious domains, identifying data exfiltration through DNS tunneling, and understanding the communication patterns of compromised systems.

Cloud-native DNS logging through Route 53 query logging, Cloud DNS logging, or Azure DNS Analytics captures this data without deploying additional infrastructure.

Log Retention and Protection

Your network logs should follow the same retention and protection policies as your application logs. Define retention periods that satisfy both your audit requirements and any regulatory obligations. Protect logs from modification or deletion by storing them in append-only storage, restricting access to log repositories, and monitoring for unauthorized access to log data.

Centralize your network logs alongside your application and security logs in a SIEM or log management platform. Fragmented logging across multiple tools and accounts makes both monitoring and audit evidence collection significantly harder. See our detailed guide on logging and monitoring requirements for the full picture.

Wireless Network Security

If your organization has office space with wireless networks, SOC 2 requires that those networks are secured appropriately. Even in a remote-first world, many companies maintain office space for at least some employees, and the wireless networks in those spaces need to meet security standards.

Office WiFi Security

Your corporate wireless network should use WPA3 or WPA2-Enterprise with RADIUS authentication tied to your identity provider. This ensures that only authenticated employees can access the corporate network and that access is revoked when employees leave.

Segment your wireless network from your production infrastructure. Office WiFi should provide internet access and potentially access to internal tools, but it should never provide direct network-level access to production systems. Production access should always go through your VPN, bastion host, or zero-trust access solution, regardless of whether the employee is in the office or working remotely.

Guest Network Isolation

If you provide WiFi for visitors, guests, or personal devices, that network must be completely isolated from your corporate network. Guest networks should provide internet access only, with no ability to reach internal systems, printers, file shares, or any other corporate resource.

Remote Work Considerations

For remote-first companies, office WiFi security may be a non-issue because there is no office. However, your auditor may ask about how you handle employee home network security. The practical answer for most companies is that you don't control employee home networks — instead, you ensure that all connections to corporate systems go through encrypted channels (VPN, TLS, SSH) and that endpoint security controls on employee devices (access control and endpoint protection) provide security regardless of the underlying network.

This approach — securing the endpoints and the connections rather than the network — is increasingly accepted by auditors and is the practical reality for any company with remote employees.

Common Network Security Gaps in SOC 2 Audits

Understanding the most frequent network security findings helps you avoid them. These gaps appear consistently in SOC 2 audits across SaaS companies of all sizes.

Overly Permissive Security Groups

The most common finding is security groups that allow more access than necessary. A security group that allows SSH (port 22) from 0.0.0.0/0 (the entire internet) is a textbook example. Even if SSH access requires key-based authentication, exposing the port to the internet creates unnecessary attack surface. Restrict SSH access to your VPN or bastion host IP range. Review security groups quarterly and remove rules that are no longer needed.

Another common issue is security groups that allow all traffic between application tiers rather than restricting to specific ports and protocols. Your web servers should connect to your database on the database port only, not on all ports. Tightening these rules reduces blast radius and demonstrates mature network security practices.

No Outbound Traffic Controls

Many companies meticulously control inbound traffic but leave outbound traffic completely unrestricted. This means that if a system is compromised, the attacker can freely communicate with command-and-control servers and exfiltrate data to any destination. While restricting outbound traffic is more operationally complex, it's a control that auditors increasingly expect to see, particularly for production systems that handle sensitive data.

Start by understanding what outbound destinations your production systems legitimately need — cloud API endpoints, payment processors, email services, monitoring platforms — and restrict outbound traffic to those destinations. DNS-based filtering through services like your cloud provider's DNS firewall can block outbound connections to known malicious domains without requiring you to maintain IP allowlists for every legitimate destination.

Stale Network Diagrams

An outdated network diagram is worse than no diagram at all because it gives your auditor the impression that you don't understand your own environment. If your diagram shows three application servers but you've since scaled to twelve, or if it's missing the new microservice you deployed six months ago, your auditor will question whether your security controls reflect your actual architecture.

Assign ownership of the network diagram to someone who has visibility into infrastructure changes — typically a DevOps or platform engineering team member. Include diagram review in your change management process so that significant infrastructure changes trigger diagram updates.

Missing Network Segmentation Between Environments

Production, staging, and development environments that share VPCs, subnets, or security groups represent a segmentation failure. Development environments typically have broader access controls and contain test data, and if they share network resources with production, a compromise in development could provide a pathway into production.

This is particularly problematic when developers have broad access to development environments, which is normal and expected, but that broad access extends to production network segments because the environments aren't properly isolated. Separate VPCs or, at minimum, separate subnets with strict security group rules between environments are the standard your auditor expects to see.

No Regular Firewall Rule Reviews

Firewall rules accumulate over time. Temporary rules added during debugging become permanent. Rules created for services that have since been decommissioned remain active. Without regular review, your firewall configuration drifts from your documented security posture.

Conduct quarterly reviews of your security group rules, network ACLs, and any other firewall configurations. For each rule, verify that it's still needed, that it follows the principle of least privilege, and that it's documented. Remove rules that are no longer necessary and tighten rules that are overly broad. Document the review and its findings as evidence for your auditor.

Implementing Network Security Step by Step

If you're building your network security program from scratch or bringing an existing program up to SOC 2 standards, this phased approach helps you prioritize the work.

Phase 1 — Architecture and Segmentation (Weeks 1-2)

Start with your network architecture. Document your current state, identify segmentation gaps, and plan the target architecture. If your production and development environments share network resources, separating them is the highest-priority change. Implement VPC or subnet isolation between environments, configure security groups with default-deny posture, and document your architecture in a network diagram.

Phase 2 — Access Controls and Firewalls (Weeks 3-4)

Review and tighten all security group rules. Remove overly permissive rules, restrict administrative access to VPN or bastion host IP ranges, and ensure that service-to-service communication is restricted to required ports. Implement outbound traffic controls for production systems. Configure and test your WAF if you have internet-facing applications.

Phase 3 — Monitoring and Detection (Weeks 5-6)

Enable VPC flow logs, DNS logging, and cloud-native threat detection services like GuardDuty. Configure alerting for security-relevant events and establish the escalation path for network security alerts. Verify that alerts are being received and investigated within defined timeframes.

Phase 4 — Documentation and Evidence (Weeks 7-8)

Finalize your network security policy documenting your architecture, segmentation strategy, access controls, monitoring approach, and change management requirements. Set up evidence collection processes for ongoing compliance — quarterly security group reviews, firewall change records, monitoring reports, and alert investigation documentation.

This eight-week timeline produces a network security program that satisfies SOC 2 requirements and provides genuine protection for your infrastructure. The timeline assumes you're working with cloud infrastructure and cloud-native security tools. Organizations with on-premise components or legacy network infrastructure may need additional time.

Evidence Collection for Network Security

Your auditor will request specific evidence for network security controls. Organizing this evidence proactively reduces audit friction.

Architecture Documentation

Provide a current network diagram showing your architecture, segmentation, and security controls. Include a written description of your network architecture that explains the segmentation strategy and the rationale behind it. Your system description should reference your network architecture, and your network diagram should be consistent with what's described.

Firewall and Security Group Configurations

Your auditor will want to see the actual configurations of your firewalls and security groups, not just descriptions of your policy. Export security group rules, network ACL configurations, and WAF rulesets. If you manage infrastructure as code, provide the relevant Terraform or CloudFormation configurations along with version control history showing the change management process.

Monitoring and Detection Evidence

Provide evidence that your intrusion detection capabilities are active and generating alerts. This includes screenshots or exports from GuardDuty, SCC, or other detection tools showing active monitoring. Include examples of alerts that were generated, investigated, and resolved. Show alert routing configuration demonstrating that security alerts reach the appropriate team members.

Access Logs and Flow Data

Provide samples of VPC flow logs showing that logging is active and capturing relevant data. Show examples of administrative access to network management interfaces, demonstrating that access follows your defined procedures and is logged.

Change Management Evidence

For any firewall or security group changes during your observation period, provide the change records showing what was changed, why, who approved the change, and evidence of testing. This ties directly to your broader change management process.

A solid network security program doesn't require enterprise-grade appliances or a dedicated network security team. What it requires is a thoughtful architecture, appropriate use of cloud-native security controls, consistent monitoring, and thorough documentation. Our Network Security Policy provides the documented foundation for your network security program, and our Network Diagram package gives you professionally designed templates for the architecture documentation your auditor expects. Both are included in the Complete Bundle alongside all the policies and documentation you need for SOC 2 compliance.

Start with your architecture. Get the segmentation right, configure security groups with default-deny, enable monitoring and logging, and document everything. These fundamentals satisfy the vast majority of SOC 2 network security requirements and provide a strong foundation for building more advanced capabilities over time.