GuardDuty findings accumulate fast once it's enabled across a multi-account Organization — reconnaissance findings from routine port scans, low-severity findings from expected behavior that just hasn't been suppressed yet, and genuine anomalies buried somewhere in the noise. Manually reviewing each one in the console doesn't scale, and an unreviewed finding backlog is itself an audit finding under SOC 2's monitoring criteria (CC7.1/CC7.2).
The Triage Problem in Plain Terms
GuardDuty assigns severity scores, but severity alone doesn't tell you who should look at a finding or whether it needs action. A high-severity finding on a sandbox account behaves differently from the same finding type on a production account handling customer data — context that GuardDuty itself doesn't have, but your triage pipeline should.
The Pipeline We Build
import boto3
def triage_guardduty_finding(finding):
"""Routes a GuardDuty finding to the right owner and suppression
logic based on account criticality and finding type."""
account_tier = get_account_tier(finding["AccountId"]) # prod, staging, sandbox
finding_type = finding["Type"]
severity = finding["Severity"]
if is_known_benign_pattern(finding_type, finding["Resource"]):
return suppress_with_reason(finding["Id"], "matches documented benign pattern")
priority = "P1" if (account_tier == "production" and severity >= 7.0) else \
"P2" if severity >= 4.0 else "P3"
owner = get_finding_type_owner(finding_type) # network team, IAM team, workload team
ticket = create_ticket(
title=f"[{priority}] GuardDuty: {finding_type}",
assignee=owner,
account=finding["AccountId"],
finding_id=finding["Id"],
)
log_evidence_record(finding, ticket, priority)
return ticket
Known-benign pattern suppression matters more than it sounds — without it, routine, expected activity (a security scanning tool's own reconnaissance-pattern traffic, a load testing tool that trips a behavioral finding) generates tickets forever, and teams eventually start ignoring the alert channel entirely, which defeats the entire purpose of triage.
Owner Routing by Finding Category
GuardDuty finding types map reasonably well to specific technical domains — IAM-related findings (UnauthorizedAccess:IAMUser/*) route to the identity/IAM owner, network findings (Recon:EC2/PortProbeUnprotectedPort) route to the network/infrastructure owner, and workload findings (CryptoCurrency:EC2/*) route to the specific account or application owner. Building this routing table once, rather than routing everything to a single security inbox, is what makes the pipeline sustainable past the first few weeks.
The Evidence This Produces
Every finding — suppressed or ticketed — gets logged with its classification decision, and that log is the CC7.2 evidence artifact: a complete, timestamped record showing every detected anomaly was evaluated and either explained (suppression with documented reason) or acted on (ticket with an owner and resolution). An auditor sampling findings from any point in the year can trace the full decision trail rather than relying on a narrative explanation of "we review these."
Frequently Asked Questions
How do we avoid over-suppressing and missing a real threat?
Suppression rules should be narrowly scoped to specific, documented patterns (a specific resource ARN, a specific finding type combined with a specific source) rather than broad severity-based suppression, and suppression rules themselves should be periodically reviewed rather than set once and forgotten.
Does this integrate with AWS Security Hub as well as GuardDuty directly?
Yes — Security Hub aggregates GuardDuty findings alongside other detectors, and the same triage and evidence pattern typically extends to Security Hub's consolidated finding stream, which we cover in more depth in our related piece on GuardDuty and Security Hub aggregation for SOC 2 evidence.
How long does building this triage automation typically take?
For an environment with GuardDuty already enabled across accounts, building the initial routing and suppression logic typically takes a few weeks, with ongoing tuning as new benign patterns get identified over the following months.
What happens to findings that don't match any owner routing rule?
They should route to a default owner (typically the security or platform team) rather than being dropped silently — an unrouted finding is still a finding that needs a documented disposition for audit purposes.
Ask us what your GRC platform isn't covering on GuardDuty evidence → rutagon.com/contact or call 907-841-8407.