Why GuardDuty Is Required for SOC 2

SOC 2's CC7.2 criterion requires that organizations monitor systems for threats and anomalous activity. GuardDuty is AWS's managed threat detection service — it analyzes CloudTrail events, VPC Flow Logs, and DNS logs to identify malicious patterns without requiring you to build custom detection logic.

In practice, auditors expect to see GuardDuty enabled in every active region. An account without GuardDuty cannot credibly claim to be monitoring for threats — which is a failing control under CC7.2.

Step 1 — Enable GuardDuty in All Regions

Enable GuardDuty as a one-time action per region. If you use AWS Organizations, enable it organization-wide from the management account:

# Enable in a specific region
aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES \
  --features '[{"Name":"S3_DATA_EVENTS","Status":"ENABLED"},{"Name":"EKS_AUDIT_LOGS","Status":"ENABLED"},{"Name":"MALWARE_PROTECTION","Status":"ENABLED"}]'
# Enable organization-wide (from management account)
aws guardduty create-members \
  --detector-id YOUR-DETECTOR-ID \
  --account-details file://member-accounts.json

Enable at FIFTEEN_MINUTES publishing frequency for security environments — SIX_HOURS delays detection for cost savings, but reduces your ability to respond quickly.

Optional features worth enabling:

• S3 Data Events — detects data exfiltration from S3 buckets
• EKS Audit Logs — detects threats in Kubernetes control planes
• Malware Protection — scans EC2/ECS workloads for malware

SecureSpect check: aws.guardduty.detector_enabled — flags any region where the detector is disabled or suspended.

Step 2 — Route Findings to Your Notification Channel

GuardDuty findings are useless if no one sees them. Route HIGH and CRITICAL severity findings to your team using EventBridge:

# Create EventBridge rule for high-severity GuardDuty findings
aws events put-rule \
  --name "GuardDutyHighSeverityFindings" \
  --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": {
      "severity": [{ "numeric": [">=", 7] }]
    }
  }' \
  --state ENABLED

Route to an SNS topic that sends to Slack or PagerDuty. For SOC 2, you need evidence that findings were received by someone — not just that they were generated.

Step 3 — Document Finding Responses

For SOC 2 Type II, auditors sample GuardDuty findings from across the audit period and verify that each was reviewed and closed. You need a process and a trail.

Minimum required process:

Finding generated → automated alert to on-call channel

On-call engineer acknowledges within defined SLA (e.g., 4 hours for HIGH)

Finding investigated: is it a true positive, false positive, or informational?

Finding archived in GuardDuty with documented rationale

If true positive: incident created, remediation tracked

Documenting in a ticketing system: Create a ticket for every HIGH and CRITICAL finding. Include the GuardDuty finding ID, the affected resource, the investigation notes, and the resolution. This becomes your SOC 2 evidence for CC7.2 and CC7.3.

Common GuardDuty Finding Types for SaaS

|---|---|---| Most GuardDuty findings for well-managed SaaS environments are low-severity informational or false positives. The key is having a documented process for evaluating and closing them — not that every finding is a security incident.

Step 4 — Verify with SecureSpect

SecureSpect checks two things beyond "is GuardDuty enabled":

Active HIGH/CRITICAL findings without resolution — a finding that's been open for more than 30 days is a red flag for auditors. SecureSpect flags any unresolved HIGH/CRITICAL findings as a failing control.

Organization-level enablement — GuardDuty enabled in the management account but not delegated to member accounts is a coverage gap. SecureSpect verifies enablement across all accounts in scope.