Controls3 May 2026 6 min read

SOC 2 WAF Requirements: Web Application Firewall Setup

Configure AWS WAF for SOC 2. Learn which managed rule groups to enable, how WAF maps to CC6 and CC7 criteria, and how to collect WAF evidence for auditors.

Key Takeaways

A WAF is expected by most SOC 2 auditors as a defense-in-depth control for public-facing web applications.
AWS WAF managed rule groups (Core, Known Bad Inputs, SQL Injection, XSS) cover the most common attack vectors.
WAF logs provide application-layer attack evidence for CC7.2 anomaly detection.
Enable rate limiting rules to satisfy availability protection requirements.
Associate WAF with CloudFront, ALB, or API Gateway — wherever your public endpoints live.

In this guide

WAF and SOC 2 Criteria Mapping
Creating an AWS WAF Web ACL
Managed Rule Groups to Enable
Rate Limiting for Availability
WAF Logging Configuration
WAF Evidence for Auditors

WAF and SOC 2 Criteria Mapping

A Web Application Firewall (WAF) filters HTTP/HTTPS traffic to your web application, blocking common attack patterns — SQL injection, cross-site scripting, path traversal, protocol attacks. For SOC 2, a WAF addresses CC6.6 (protecting information assets from unauthorized access), CC7.1 (detecting misuse of applications), and CC7.2 (detecting anomalies and threats).

SOC 2 doesn't explicitly mandate a WAF, but auditors increasingly expect one for customer-facing SaaS products. Without a WAF, an auditor may note that application-layer attacks (OWASP Top 10) have no dedicated control, which can be a finding under CC6 or a risk acceptance that requires justification.

Creating an AWS WAF Web ACL

AWS WAF v2 web ACLs can be associated with CloudFront distributions, Application Load Balancers, API Gateways, and App Runner services. For a regional ALB: in the WAF console, create a Web ACL, select regional scope, associate the ALB resource.

For global (CloudFront): create the WAF Web ACL in us-east-1 (global), associate with your CloudFront distribution. Rules in the ACL are evaluated in priority order — lower numbers are evaluated first. Set the default action to ALLOW for most configurations (rules explicitly block known bad traffic) rather than BLOCK all and allow-list known good traffic.

Managed Rule Groups to Enable

AWS Managed Rules are pre-built rule groups maintained by AWS. Enable these for a baseline SOC 2-compliant WAF configuration: (1) AWSManagedRulesCommonRuleSet — blocks common web exploits (OWASP Top 10, CWE). (2) AWSManagedRulesKnownBadInputsRuleSet — blocks requests with known malicious inputs. (3) AWSManagedRulesSQLiRuleSet — SQL injection protection. (4) AWSManagedRulesLinuxRuleSet — Linux-specific exploits (if running Linux servers). (5) AWSManagedRulesAmazonIpReputationList — blocks IPs associated with bots and malicious activity.

Start with all rules in COUNT mode, not BLOCK mode. Review the count of matched requests for 1-2 weeks to identify false positives before switching to BLOCK. This prevents your WAF from blocking legitimate traffic on deployment.

For additional protection, consider AWS Marketplace managed rules from F5, Imperva, or Cloudflare for enhanced threat intelligence and application-specific rules.

Rate Limiting for Availability

Rate limiting rules block clients that exceed a defined request threshold, protecting against DDoS attacks and brute force attempts. Add a rate-based rule to your Web ACL: block any IP that sends more than 2000 requests in a 5-minute window (adjust based on your legitimate traffic patterns).

For login endpoints, configure a tighter rate limit (e.g., 100 requests per 5 minutes per IP) using a scope-down statement that matches the /login or /api/auth path. This protects against credential stuffing attacks and satisfies CC6.2 authentication protection requirements.

AWS Shield Standard (included with WAF) provides automatic DDoS protection for layer 3 and 4 attacks. For applications requiring SLA-backed DDoS protection, upgrade to AWS Shield Advanced.

WAF Logging Configuration

Enable WAF logging to capture all request inspection data. Delivery destinations: Amazon Kinesis Data Firehose (to S3 for long-term retention and Athena analysis), CloudWatch Logs (for real-time alerting), or Amazon S3 directly.

WAF logs include: timestamp, action (allow/block/count), matched rule, source IP, request URI, headers, and body (if configured). Enable logs and configure a retention period of at least 90 days for SOC 2 audit evidence. Query logs via Athena to investigate blocked attack patterns.

Create CloudWatch Metrics and Alarms for blocked requests: alarm when AllowedRequests drops by more than 50% (possible outage) or BlockedRequests spikes more than 500% (active attack). Route alarms to your incident response channel.

WAF Evidence for Auditors

(1) WAF Web ACL configuration screenshot showing associated resources and enabled rule groups. (2) WAF logging configuration showing destination and retention. (3) Sample WAF log metrics or dashboard showing blocked requests over the audit period. (4) Rate limiting rule configuration. (5) AWS Shield Standard acknowledgment (automatic) or Shield Advanced subscription for enhanced DDoS protection.

Frequently Asked Questions

Is a WAF required for SOC 2, or just recommended?

Not explicitly required by the AICPA criteria, but expected by most auditors for customer-facing web applications. Without a WAF, auditors may note it as a risk mitigation gap and request a documented risk acceptance. Most enterprise SOC 2 customers also ask whether you have a WAF as part of their security questionnaire.

Should we use AWS WAF or a third-party WAF (Cloudflare, Imperva)?

Both satisfy SOC 2 requirements. AWS WAF integrates natively with ALB, CloudFront, and API Gateway with no latency overhead. Third-party WAFs like Cloudflare offer more advanced features (bot management, advanced DDoS, global anycast network) and are appropriate if you have higher threat exposure or need global performance. The evidence collection approach is the same — screenshot the configuration and export logs.

We use API Gateway — does it need a WAF?

Yes, if your API handles sensitive data or is publicly accessible. Associate a WAF Web ACL with your API Gateway stage in the API Gateway console under Stages > select stage > Web Application Firewall (WAF). The same managed rules apply.

How do we handle WAF false positives that block legitimate requests?

Start in COUNT mode to identify false positives before enabling BLOCK mode. For specific rules with high false positive rates, switch just that rule to COUNT mode. For known legitimate request patterns that trigger rules, add an IP-based allow list or a scope-down statement that excludes specific paths or headers from the rule.

Does WAF logging count as security monitoring for CC7.2?

Yes. WAF logs are application-layer attack data that directly satisfies CC7.2 anomaly detection for web application threats. Combined with CloudTrail (infrastructure layer), VPC Flow Logs (network layer), and GuardDuty (threat intelligence layer), WAF logging provides comprehensive multi-layer monitoring evidence.