Firewall Requirements for SOC 2 Compliance

One of the questions that comes up in almost every SOC 2 readiness engagement we run is: "What exactly do auditors want to see for firewalls?" The answer we give surprises many teams — SOC 2 does not prescribe specific firewall products, architectures, or rule configurations. It is principle-based, which means it requires you to demonstrate that you have implemented security measures to protect against threats from outside your system boundaries. In our experience, this principle-based approach is both a strength and a source of confusion. It gives you flexibility to use cloud-native security controls rather than traditional firewall appliances, but it also means you need to clearly articulate and evidence how your network security architecture satisfies the Trust Service Criteria. The organizations that struggle are the ones that cannot explain their firewall decisions to an auditor, not the ones using the wrong firewall technology.

This guide covers SOC 2 firewall requirements, including the relevant Trust Service Criteria, cloud-native firewall implementations across AWS, Azure, and GCP, WAF deployment, evidence collection strategies, and how to work with your auditor on network security evidence.

Relevant Trust Service Criteria

CC6.1 — Logical Access Security

CC6.1 requires that the entity implements logical access security software, infrastructure, and architectures over protected information assets. Firewalls are a core component of logical access infrastructure because they control which network traffic can reach your systems.

CC6.1 Requirement	Firewall Implementation
Logical access is restricted	Firewall rules restrict network access to authorized sources, ports, and protocols
Infrastructure protects information assets	Firewalls create network boundaries that prevent unauthorized access to databases, application servers, and internal services
Access architectures are implemented	Firewall architecture defines network zones (public, application, data) with controlled access between them

CC6.6 — Security Measures Against Threats Outside System Boundaries

CC6.6 is the most directly relevant criterion for firewalls. It requires that the entity implements controls to prevent or detect and act on threats from sources outside the boundaries of the system. This is where your firewall architecture, rule set, and monitoring capabilities are evaluated.

What we tell clients is that CC6.6 is where the auditor spends the most time on network security. The criterion asks you to demonstrate:

• How you define your system boundaries (what is inside vs outside)
• What controls protect those boundaries from external threats
• How those controls are monitored and maintained
• How you detect and respond to threats that attempt to cross those boundaries

In our experience, the system boundary definition is the critical starting point. If you cannot clearly define where your system boundaries are — which network segments are within scope, which connections cross the boundary, and what controls exist at each crossing point — the auditor cannot evaluate whether your firewall controls are adequate.

CC6.7 — Restricting Data Transmission and Movement

CC6.7 requires restricting the transmission, movement, and removal of information to authorized internal and external users and processes. Firewalls support CC6.7 by controlling which data flows are permitted across network boundaries.

CC6.7 Requirement	Firewall Role
Data transmission is restricted	Egress firewall rules control what data can leave your network
Movement of information is controlled	Network segmentation firewalls control data flow between internal zones
Unauthorized transmission is prevented	DLP-capable firewalls and WAFs inspect traffic for unauthorized data movement

Additional Relevant Criteria

Criteria	Firewall Relevance
CC6.2 — Registration and authorization	Network access requires that sources are identified and authorized through firewall rules
CC7.1 — Monitoring infrastructure	Firewall logs and alerts are part of your security monitoring infrastructure
CC7.2 — Monitor system components	Firewall events are monitored for anomalies indicating potential security incidents
CC7.3 — Evaluate security events	Firewall alerts feed into your security event evaluation process
CC8.1 — Change management	Firewall rule changes are subject to your change management process

Cloud-Native Firewalls

AWS Security Groups and NACLs

In our experience, the majority of SOC 2 clients use AWS as their primary cloud platform. AWS provides two levels of native network firewall controls.

Security Groups (Stateful)

Security Groups are the primary firewall control in AWS. They operate at the instance (ENI) level and are stateful, meaning return traffic is automatically permitted.

Security Group Best Practice	SOC 2 Justification
Default deny inbound	CC6.1 — Restrict access to authorized traffic only
Specific source restrictions (no 0.0.0.0/0 except for public-facing services)	CC6.6 — Prevent unauthorized access from outside system boundaries
Port-specific rules (not all-traffic rules)	CC6.1 — Least-privilege network access
Security group references instead of IP ranges where possible	CC6.1 — Access tied to identity (service role) rather than network location
Descriptive rule names and documentation	CC8.1 — Change management traceability

Network ACLs (Stateless)

Network ACLs provide an additional layer of firewall control at the subnet level. They are stateless, meaning both inbound and outbound rules must be explicitly defined.

What we recommend is using Security Groups as your primary firewall control and NACLs as a secondary defense-in-depth layer. In our experience, auditors are satisfied with Security Groups alone for most architectures, but NACLs demonstrate defense-in-depth for organizations that want a stronger control posture.

AWS Network Firewall

AWS Network Firewall provides stateful and stateless traffic inspection at the VPC level, with IDS/IPS capabilities and domain-based filtering. What we tell clients is that AWS Network Firewall is appropriate for organizations that need centralized traffic inspection across multiple VPCs or advanced threat detection, but it is not required for SOC 2 compliance if your Security Groups and NACLs are properly configured.

Azure Network Security Groups

Azure NSGs function similarly to AWS Security Groups, providing stateful firewall rules that can be applied to subnets or individual network interfaces.

Azure NSG Best Practice	SOC 2 Justification
Default deny inbound with explicit allow rules	CC6.1 — Restrict access to authorized sources
Application Security Groups (ASGs) for role-based rules	CC6.1 — Logical grouping of resources with similar access requirements
NSG flow logs enabled	CC7.1 — Monitor network traffic for security events
Network Watcher integration	CC7.2 — Continuous monitoring of network components
Azure Firewall for centralized traffic management	CC6.6 — Centralized threat protection at network boundaries

GCP Firewall Rules

GCP firewall rules are applied at the VPC network level and can target instances using network tags or service accounts.

GCP Firewall Best Practice	SOC 2 Justification
Default deny ingress (GCP default)	CC6.1 — Restrict inbound access to explicitly authorized traffic
Service account-based targeting	CC6.1 — Access rules tied to workload identity rather than IP
Priority-based rule ordering with explicit deny rules	CC6.6 — Systematic approach to traffic filtering
VPC Flow Logs enabled	CC7.1 — Network traffic monitoring and analysis
Hierarchical firewall policies for organization-wide rules	CC6.6 — Consistent security baselines across projects

Cloud-Native Firewalls Are Sufficient

What we tell clients — and this is one of the most important points in this guide — is that cloud-native firewall controls are sufficient for SOC 2 compliance. You do not need to deploy third-party firewall appliances in a cloud environment to satisfy your auditor. The Trust Service Criteria are principle-based, and cloud-native security groups, NSGs, and firewall rules demonstrate appropriate network access controls when they are:

1. Configured following least-privilege principles
2. Documented and traceable to business requirements
3. Subject to change management processes
4. Monitored through logging and alerting
5. Reviewed periodically for continued appropriateness

In our experience, auditors understand cloud-native security controls and evaluate them the same way they would evaluate traditional firewall appliances — by reviewing the rules, the change control, and the monitoring.

WAF Implementation

Why WAF Matters for SOC 2

Web Application Firewalls protect your public-facing applications from application-layer attacks. While SOC 2 does not explicitly require WAF, CC6.6 requires security measures against external threats, and application-layer attacks (SQL injection, XSS, CSRF) are among the most common external threats to web applications.

What we recommend is deploying WAF for all public-facing web applications and APIs. In our experience, auditors increasingly expect WAF as a baseline control for organizations with web-based services.

WAF Options by Cloud Platform

Platform	WAF Service	Key Features	Integration
AWS	AWS WAF	Managed rule groups (OWASP, bot control, IP reputation), custom rules, rate limiting	CloudFront, ALB, API Gateway, App Runner
Azure	Azure WAF	OWASP rule sets, custom rules, bot protection	Application Gateway, Front Door, CDN
GCP	Cloud Armor	OWASP rule sets, adaptive protection, rate limiting, bot management	Cloud Load Balancing
Multi-cloud	Cloudflare WAF	Managed rules, custom rules, rate limiting, bot management, DDoS protection	DNS-based; works with any origin

WAF Configuration for SOC 2

What we recommend configuring in your WAF:

Configuration	Purpose	SOC 2 Criteria
OWASP managed rule set	Protect against common web application vulnerabilities	CC6.6 — Security measures against external threats
Rate limiting	Prevent brute force and denial-of-service attacks	CC6.6 — Threat prevention at system boundaries
IP reputation blocking	Block traffic from known malicious sources	CC6.6 — Threat detection and prevention
Bot management	Distinguish legitimate bot traffic from malicious bots	CC6.6 — Threat detection
Custom rules for application-specific protections	Address threats specific to your application logic	CC6.6 — Application-specific threat prevention
Logging enabled	Capture WAF events for monitoring and incident investigation	CC7.1 — Security monitoring

WAF Evidence for Auditors

Evidence	What It Shows	How to Collect
WAF configuration	Which rule sets are enabled and how they are configured	WAF console export or IaC definition
WAF event logs	Blocked and allowed requests with rule match details	WAF logging to CloudWatch, Azure Monitor, or similar
WAF metrics	Volume of blocked requests, rule match rates, false positive rates	WAF dashboard or monitoring platform
WAF rule update history	When managed rules were updated and any custom rule changes	WAF configuration change history or IaC commits

Evidence Collection

System Description

Your SOC 2 report's system description should clearly document your network security architecture. What we recommend including:

Description Element	Content
Network architecture overview	High-level description of your network topology, including VPCs, subnets, availability zones, and network zones
System boundary definition	Clear definition of what is inside your system boundary and what is outside
Firewall architecture	Description of firewall controls at each boundary crossing (security groups, NACLs, WAF, cloud firewall)
Network segmentation	How networks are segmented (production vs development, application tier vs data tier, public vs private)
Monitoring approach	How network traffic is monitored and how security events are detected

Evidence Package

In our experience, auditors request the following evidence for firewall controls during a SOC 2 audit:

Evidence	Source	Auditor Purpose
Network architecture diagram	Infrastructure documentation	Understand system boundaries and firewall placement
Firewall rule export	Cloud console or IaC repository	Evaluate whether rules follow least-privilege principles
Firewall rule documentation	Internal documentation or IaC comments	Verify that rules are justified and documented
Change management records	Ticketing system or IaC commit history	Verify that firewall changes follow change management process
Firewall logs (sample)	SIEM or log management platform	Verify that firewall events are logged and retained
Monitoring alert configuration	SIEM or monitoring platform	Verify that firewall events are actively monitored
WAF configuration	WAF console or IaC	Verify that application-layer protections are in place
Periodic review records	Review documentation or tickets	Verify that firewall rules are reviewed periodically

Continuous Evidence Through GRC Platforms

What we tell clients is that GRC platforms (Vanta, Drata, Secureframe) can automate portions of firewall evidence collection through cloud provider integrations. These integrations typically check:

• Whether security groups have overly permissive inbound rules (0.0.0.0/0)
• Whether specific high-risk ports are open to the internet (SSH port 22, RDP port 3389)
• Whether VPC flow logs are enabled
• Whether WAF is deployed for public-facing load balancers

In our experience, GRC platform checks are useful for continuous monitoring but do not replace the manual evidence collection that auditors require. They catch configuration drift between audits and alert you to issues before the auditor finds them.

Working with Auditors on Network Security Evidence

What Auditors Are Really Looking For

In our experience, auditors evaluating firewall controls are asking three fundamental questions:

1. Are your system boundaries clearly defined? The auditor needs to understand what is inside scope and what is outside before they can evaluate boundary controls.

2. Are the boundary controls appropriate for your risk profile? This is where the principle-based nature of SOC 2 matters — the auditor evaluates whether your controls are reasonable, not whether they match a specific checklist.

3. Are the controls operating effectively? This means evidence of ongoing operation: logs, monitoring alerts, change management records, and periodic reviews throughout the observation period.

Common Auditor Questions and How to Prepare

Auditor Question	What They Are Evaluating	How to Prepare
"Walk me through your network architecture"	System boundary understanding; network segmentation	Have a current network diagram; be able to explain each network zone and the controls between them
"How do you manage firewall rule changes?"	Change management for network security	Document your change management process; have sample change records ready
"Show me your firewall rules for production"	Least-privilege evaluation; rule documentation	Export current rules; ensure each rule has documentation or comments explaining its purpose
"How do you monitor network traffic?"	Security monitoring and event detection	Show SIEM configuration, alert rules, and sample alerts
"When was the last time you reviewed your firewall rules?"	Periodic review process	Have review records with dates, participants, findings, and remediation actions
"Do you have any rules allowing all inbound traffic?"	Overly permissive access	Review all rules before the audit; identify and remediate any 0.0.0.0/0 inbound rules not required for public services

Pre-Audit Firewall Checklist

What we recommend completing before your auditor begins fieldwork:

Checklist Item	Status Check
Network architecture diagram is current	Diagram reflects current infrastructure; no stale components
All firewall rules are documented	Every rule has a purpose, source, destination, and owner
No unnecessary 0.0.0.0/0 inbound rules	Only public-facing services (load balancers, CDN origins) have open inbound rules
Change management records exist for observation period	All firewall changes during the audit period went through change management
Firewall logs flow to SIEM	Logs are being collected, retained, and monitored
Alert rules are configured	SIEM rules trigger on security-relevant firewall events
Periodic rule review completed	At least one rule review occurred during the observation period
WAF is deployed for public-facing applications	WAF with managed rule sets is protecting web applications and APIs
GRC platform checks are passing	No firewall-related failures in your GRC platform compliance dashboard

Common Audit Findings

What We See Most Frequently

In our experience across dozens of SOC 2 audits, these are the network security findings that auditors raise most often:

Finding	Why It Happens	Prevention
SSH (port 22) open to 0.0.0.0/0	Development convenience; forgotten after initial setup	Use bastion hosts or AWS Systems Manager Session Manager; restrict SSH to known IP ranges
RDP (port 3389) open to 0.0.0.0/0	Remote access for Windows management	Use VPN or Azure Bastion; never expose RDP to the public internet
All-traffic security group rules	Overly permissive rules created during development	Enforce port-specific rules; flag all-traffic rules in GRC platform checks
No WAF for public-facing applications	WAF not considered during initial architecture	Deploy WAF as part of your standard deployment architecture for any public-facing service
Firewall changes without documentation	Rules changed directly in console without change request	Enforce IaC for firewall management; restrict console write access
VPC flow logs not enabled	Not enabled by default; overlooked during setup	Enable VPC flow logs for all VPCs as part of your standard account configuration
No periodic firewall rule review	Not scheduled or prioritized	Schedule quarterly reviews; assign ownership; track completion in your GRC platform
Flat network architecture	No segmentation between application tiers	Implement subnet-based segmentation with security groups controlling inter-tier access

Key Takeaways

• What we tell clients is that SOC 2 does not prescribe specific firewall products or architectures — the Trust Service Criteria (CC6.1, CC6.6, CC6.7) require you to demonstrate appropriate security measures at your system boundaries, and cloud-native firewall controls satisfy this requirement when properly configured and governed
• In our experience, the most important step in firewall compliance is clearly defining your system boundaries — the auditor cannot evaluate whether your boundary controls are adequate until they understand where those boundaries are, so your network architecture diagram and system description are foundational evidence
• What we recommend for cloud-native environments is Security Groups (AWS), NSGs (Azure), or VPC firewall rules (GCP) as your primary firewall controls, supplemented by WAF for public-facing applications — this combination satisfies SOC 2 requirements without the cost and complexity of third-party firewall appliances
• In our experience, the most common firewall audit findings are overly permissive inbound rules (SSH and RDP open to the internet), missing WAF for public-facing services, firewall changes made outside change management, and insufficient logging — all of which are preventable through configuration standards and process discipline
• What we tell clients about firewall evidence is that auditors need to see ongoing operation throughout the observation period, not just current state — this means change management records, log samples, monitoring alerts, and periodic review documentation spanning the full audit window
• We help our clients build network security architectures that satisfy SOC 2 auditors by combining cloud-native firewall controls with the documentation, change management processes, monitoring capabilities, and periodic reviews that demonstrate effective operation over time