Enabling GuardDuty across an AWS Organization satisfies the letter of a common SOC 2 control ("does the organization have threat detection in place") without necessarily satisfying what an auditor actually wants evidenced: a demonstrable, working process for identifying, triaging, and responding to security findings. GuardDuty enabled but not centrally aggregated, with findings scattered across dozens of member accounts and nobody reviewing them on a defined cadence, technically has threat detection running and functionally has no detection response process at all.
Why Multi-Account Findings Need Central Aggregation
Organizations running AWS Organizations with GuardDuty enabled at the account level generate findings independently per account, with no natural cross-account visibility unless a delegated administrator account is configured to aggregate them. Security Hub, configured with a delegated administrator, solves the visibility problem — but aggregation alone still isn't the evidence artifact an auditor wants; it's the substrate the actual evidence gets built on top of.
# Designating a Security Hub delegated administrator for org-wide aggregation
aws securityhub enable-organization-admin-account \
--admin-account-id 123456789012
# Auto-enabling Security Hub (and GuardDuty findings ingestion) for new accounts
aws securityhub update-organization-configuration \
--auto-enable --auto-enable-standards DEFAULT
Building the Triage-and-Response Evidence Layer
The evidence auditors actually want to see is a structured record showing: a finding was generated, someone (or some automated process) triaged its severity, a disposition was assigned (remediate, suppress with justification, escalate), and remediation happened within a defined SLA. GuardDuty and Security Hub give you the finding; they don't automatically give you the structured disposition record unless you build the pipeline connecting findings to a tracked response:
# Findings triage pipeline - creates a tracked disposition record per finding
def triage_new_findings(security_hub_client, ticket_system):
findings = security_hub_client.get_findings(
Filters={"WorkflowStatus": [{"Value": "NEW", "Comparison": "EQUALS"}]}
)["Findings"]
for finding in findings:
severity = finding["Severity"]["Label"]
sla_hours = {"CRITICAL": 4, "HIGH": 24, "MEDIUM": 72, "LOW": 168}[severity]
ticket = ticket_system.create_ticket(
title=finding["Title"],
severity=severity,
sla_deadline=datetime.utcnow() + timedelta(hours=sla_hours),
finding_id=finding["Id"],
account_id=finding["AwsAccountId"],
)
security_hub_client.batch_update_findings(
FindingIdentifiers=[{"Id": finding["Id"], "ProductArn": finding["ProductArn"]}],
Note={"Text": f"Tracked as {ticket['id']}", "UpdatedBy": "triage-pipeline"},
Workflow={"Status": "NOTIFIED"},
)
This closes the loop between "a finding exists" and "a finding has a tracked, SLA-bound response" — the actual thing SOC 2's incident detection and response controls are testing for.
Reducing Noise Without Losing Evidence
GuardDuty and Security Hub, especially aggregated across a large multi-account organization, generate a volume of findings that overwhelms a manual review process quickly — much of it low-severity or false-positive noise. Automated suppression rules for known-benign patterns (a specific finding type tied to an expected, documented behavior) are legitimate, but every suppression needs its own justification logged, since an auditor reviewing findings disposition will ask about suppressed findings just as readily as escalated ones.
Mapping to SOC 2 Trust Service Criteria
This aggregation-and-triage pipeline maps most directly to CC7.2 (monitoring for security events) and CC7.3 (evaluating and responding to identified security events) — the evidence artifact you want ready for an auditor sample is a specific finding, its triage timestamp, its disposition, and its resolution timestamp, queryable on demand rather than reconstructed from Slack threads after the fact.
Cost Consideration Alongside the Compliance Angle
GuardDuty and Security Hub both have usage-based pricing that scales with data volume and finding count — the same aggregation pipeline that improves compliance evidence also creates a natural point to review whether every enabled protection plan (S3 protection, EKS protection, RDS protection, Malware Protection) is actually providing proportional value for its cost across every member account, rather than uniformly enabled everywhere by default.
This aggregation pipeline is part of our AWS cloud infrastructure capability, alongside the response-runbook work covered in AWS security incident response runbook.
Ask us what your GRC platform isn't covering: 907-841-8407 or contact@rutagon.com.
Ask us what your GRC platform isn't covering →
Frequently Asked Questions
Does enabling GuardDuty alone satisfy a SOC 2 threat detection control?
It satisfies the detection half of the control; most auditors also expect evidence of a functioning triage and response process, which requires building the disposition-tracking layer on top of raw findings.
How does Security Hub's delegated administrator model work across an AWS Organization?
One account is designated as the delegated administrator, which then aggregates findings from GuardDuty, Security Hub, and other integrated services across all member accounts into a single view, without needing to log into each account separately.
What's a reasonable SLA for responding to a Critical severity GuardDuty finding?
This depends on your organization's risk tolerance and documented incident response policy, but same-day (often within hours) response for Critical findings is a common baseline, with longer windows for lower severities.
Can suppressing findings hurt us in an audit?
Suppression itself isn't a problem if it's justified and documented — auditors are typically more concerned with undocumented or unexplained suppression patterns than with the existence of suppression rules for known-benign findings.
Does this pipeline work with GuardDuty findings only, or other Security Hub-integrated services too?
The same triage-and-disposition pattern applies to any finding source integrated into Security Hub — AWS Config rules, Inspector, IAM Access Analyzer, and third-party integrations all normalize into the same findings format Security Hub aggregates.