Controls2 May 2026 6 min read

GuardDuty for SOC 2: Threat Detection Configuration

Configure AWS GuardDuty for SOC 2 CC7.2 threat detection. Learn which finding types matter, how to route alerts, and what evidence auditors need.

Key Takeaways

GuardDuty is AWS's managed threat detection service and directly satisfies CC7.2 anomaly detection.
Enable GuardDuty in all regions and all accounts — attackers target unused regions.
Configure SNS and Slack/PagerDuty alerts so HIGH severity findings are actioned within your IR SLA.
GuardDuty Malware Protection for EBS/S3 satisfies CC6.8 malware detection.
Findings must be reviewed and either remediated or suppressed with justification — untouched findings are a CC4.2 gap.

In this guide

What Is GuardDuty?
Enabling GuardDuty Across All Accounts
Key Finding Types for SOC 2
Alert Routing Configuration
GuardDuty Malware Protection
GuardDuty Evidence for Auditors

What Is GuardDuty?

AWS GuardDuty is a managed threat detection service that continuously monitors for malicious activity and unauthorized behavior using machine learning, anomaly detection, and threat intelligence. It analyzes CloudTrail logs, VPC Flow Logs, DNS logs, and S3 access logs without requiring you to configure or manage any log pipelines.

For SOC 2, GuardDuty is the primary evidence for CC7.2 (anomaly detection) and contributes to CC7.3 (incident response) and CC6.8 (malware protection). It is a relatively low-cost, low-overhead control that provides significant security value.

Enabling GuardDuty Across All Accounts

Enable GuardDuty in every AWS account and every region — including regions you don't actively use. Attackers deliberately target unused regions to launch resources undetected. Using AWS Organizations, designate a delegated administrator account for GuardDuty (typically your security or management account) and auto-enable GuardDuty in all existing and new member accounts.

In the GuardDuty console > Settings > Accounts: auto-enable GuardDuty for new accounts. For existing accounts, select all and choose "Enable GuardDuty." Centralize findings in the delegated administrator account using GuardDuty's finding aggregation feature.

Key Finding Types for SOC 2

GuardDuty categorizes findings by service (IAM, S3, EC2, EKS, RDS, Lambda) and severity (LOW, MEDIUM, HIGH). For SOC 2 CC7.2, the most important finding types to act on: UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B (console login from unusual location), CredentialAccess:IAMUser/AnomalousBehavior (unusual API call patterns), Exfiltration:S3/ObjectRead.Unusual (unusual S3 data access), Trojan:EC2/DNSDataExfiltration (DNS-based data exfiltration), and CryptoCurrency:EC2/BitcoinTool.B (cryptomining on EC2).

Configure suppression rules for known false positives — for example, if your deployment pipeline runs from a specific IP that GuardDuty flags as anomalous. Suppression rules archive findings matching specified criteria, keeping your findings list focused on real issues.

Alert Routing Configuration

GuardDuty findings should route to your incident response process. Configure EventBridge rules to catch GuardDuty findings and route them to SNS, which delivers to Slack or PagerDuty. Filter by severity — route HIGH severity to PagerDuty for immediate on-call response, MEDIUM to a Slack channel for next-business-day review, LOW to a log for weekly review.

EventBridge rule pattern for HIGH severity GuardDuty findings: { "source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"], "detail": { "severity": [{"numeric": [">=", 7]}] } }. Connect this to an SNS topic that triggers your on-call rotation.

Also integrate GuardDuty with AWS Security Hub — Security Hub aggregates GuardDuty findings with Config findings, Inspector results, and third-party tool findings, giving you a single pane for security review.

GuardDuty Malware Protection

GuardDuty Malware Protection scans EBS volumes attached to EC2 instances and ECS containers when GuardDuty detects a potential malware finding. It also provides on-demand and scheduled scanning for S3 buckets.

Enable Malware Protection in GuardDuty Settings > Malware Protection. For S3, configure object-level scanning for buckets containing user-uploaded content — any file uploaded by end users should be scanned before being served or processed.

GuardDuty Malware Protection satisfies CC6.8 malware protection for AWS workloads. Combine with endpoint EDR (CrowdStrike, SentinelOne) for developer laptop coverage.

GuardDuty Evidence for Auditors

(1) GuardDuty enabled status screenshot for each region and account. (2) Delegated administrator configuration in AWS Organizations. (3) Sample findings from the audit period showing HIGH severity findings were actioned within your IR SLA. (4) Suppression rules list with justifications for each rule. (5) EventBridge/SNS alert routing configuration. (6) Security Hub integration showing GuardDuty as an enabled integration. (7) If zero HIGH findings in the period: document this as a positive outcome with a statement that GuardDuty was active and findings were reviewed on schedule.

Frequently Asked Questions

Does GuardDuty replace a SIEM?

GuardDuty is not a full SIEM — it analyzes AWS-specific data sources and applies threat intelligence to detect known attack patterns. A SIEM (Splunk, Sumo Logic, Datadog Security) aggregates logs from multiple sources and provides custom detection rules. For SOC 2, GuardDuty alone is sufficient for CC7.2 evidence; a SIEM adds depth and is expected in larger organizations.

How much does GuardDuty cost, and how do we control costs?

GuardDuty pricing is based on CloudTrail event volume, VPC Flow Log volume, and DNS query volume. Costs vary but typically run $50-500/month for a small SaaS company. Control costs by enabling S3 Protection and Kubernetes Protection only for accounts that use these services, and by filtering out noisy, low-value findings rather than processing them repeatedly.

What should we do when GuardDuty fires a HIGH severity alert?

Treat it as a potential security incident. Open an IR ticket, identify the affected resource, determine if the finding is genuine or a false positive, and if genuine, contain the affected resource (isolate the EC2 instance, disable the IAM credentials). Follow your IR runbook. Document the investigation and resolution. This documentation is direct CC7.3 evidence.

GuardDuty shows findings we already know about — how do we suppress them?

Create suppression rules in GuardDuty for known false positives. Navigate to GuardDuty > Findings > Actions > Create suppression rule. Specify the finding type and the criteria (e.g., specific EC2 instance ID or IP range from your CI/CD system). Document the suppression rule justification — auditors may ask why certain finding types are suppressed.

Does GuardDuty meet the CC7.2 requirement alone, or do we need additional monitoring?

GuardDuty alone meets the AWS infrastructure anomaly detection requirement for CC7.2. For comprehensive CC7.2 coverage, also address application-level monitoring (application logs with anomaly detection), endpoint monitoring (EDR), and network monitoring (VPC Flow Logs with custom alerts). The breadth of monitoring expected scales with the size and complexity of your environment.