AWS WAF for SOC 2: Web ACL Setup, Logging, and Evidence Collection
How AWS WAF v2 satisfies SOC 2 CC6.6 boundary protection requirements, what auditors check, and how to enable WAF logging for continuous compliance evidence.
AWS WAF and SOC 2 CC6.6
SOC 2 CC6.6 requires organizations to implement logical access security measures to protect against threats from sources outside the entity's system boundaries. For web applications, a Web Application Firewall (WAF) is the primary defense mechanism that auditors expect to see.
AWS WAF v2 allows you to define Web ACLs (Access Control Lists) with rules that inspect HTTP/HTTPS requests and block or rate-limit based on IP addresses, geographic origin, known bad actors (AWS Managed Rules), SQL injection patterns, and cross-site scripting patterns.
SecureSpect checks two WAF conditions for CC6.6:
aws.waf.web_acl_exists — CC6.6
Verifies at least one WAFv2 Web ACL exists and is associated with a resource
(CloudFront, ALB, API Gateway, or AppSync).
aws.waf.logging_enabled — CC7.1
Checks that WAF logging is enabled on all Web ACLs, sending request logs
to S3, CloudWatch Logs, or Kinesis Data Firehose.
Creating a Basic WAF Web ACL for SOC 2
If you're starting from scratch, here's the minimum viable WAF configuration:
# Create a WAFv2 Web ACL in us-east-1 (required for CloudFront)
aws wafv2 create-web-acl --name production-web-acl --scope CLOUDFRONT --region us-east-1 --default-action Allow={} --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=ProductionWebACL --rules '[
{
"Name": "AWSManagedRulesCommonRuleSet",
"Priority": 1,
"OverrideAction": {"None": {}},
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesCommonRuleSet"
}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "CommonRuleSet"
}
}
]'
For SOC 2, at minimum include:
AWSManagedRulesCommonRuleSet— Protects against OWASP Top 10AWSManagedRulesKnownBadInputsRuleSet— Blocks known bad request patterns- Rate limiting rules on authentication endpoints
Enabling WAF Logging for Audit Evidence
WAF logging is the most commonly missed configuration. You can have a WAF deployed, but without logging, you have no evidence that it's functioning. Auditors want to see that WAF is not just deployed but operational.
Enable logging to CloudWatch Logs:
# Create a CloudWatch log group for WAF
aws logs create-log-group --log-group-name aws-waf-logs-production
# Enable WAF logging (log group name must start with aws-waf-logs-)
aws wafv2 put-logging-configuration --logging-configuration '{
"ResourceArn": "arn:aws:wafv2:us-east-1:123456789:global/webacl/production-web-acl/abc123",
"LogDestinationConfigs": [
"arn:aws:logs:us-east-1:123456789:log-group:aws-waf-logs-production"
]
}' --region us-east-1
Retain WAF logs for at least 12 months (the length of a full Type II audit period). Set a CloudWatch Logs retention policy:
aws logs put-retention-policy --log-group-name aws-waf-logs-production --retention-in-days 365
What Auditors Look For in WAF Evidence
During a SOC 2 audit, expect questions about:
FAQ
Do I need WAF if I already have security groups and NACLs? WAF operates at layer 7 (HTTP/HTTPS), while security groups and NACLs operate at layer 3/4 (IP/port). You need both. WAF catches SQL injection and XSS; security groups catch unauthorized ports.
Is AWS Shield needed for SOC 2? No. AWS Shield Standard is free and automatically enabled. WAF is the required CC6.6 control. Shield Advanced is optional for DDoS protection.
Which WAF scope should I use — REGIONAL or CLOUDFRONT? Use CLOUDFRONT if your application is behind CloudFront. Use REGIONAL for ALBs and API Gateways in a specific region.