GuardDuty Finding Triage Runbook for Small Security Teams

Retrospective: this article looks back at events from November 2017, written in 2026 with the benefit of hindsight.

GuardDuty generates findings; your team turns them into decisions. This runbook gives small security teams a consistent way to triage GuardDuty findings.

Severity first

• High (7.0–8.9+): investigate within an hour. Often indicates active compromise.
• Medium (4.0–6.9): investigate the same business day.
• Low (1.0–3.9): review weekly in bulk; tune if noisy.

For every finding, answer five questions

1. What resource? Instance, access key, bucket, cluster or database.
2. Who owns it? Use tags or your account inventory.
3. Is the activity expected? Penetration test, new deployment, a scanner you run?
4. What else happened? Check CloudTrail around the same time for the same identity or resource.
5. What can it reach? IAM role permissions and network paths define the blast radius.

Common finding types and first actions

• Compromised credentials (UnauthorizedAccess:IAMUser…): deactivate the access key, then investigate.
• Instance talking to malicious IPs or mining pools: isolate the instance with a restrictive security group, snapshot the volume for forensics.
• S3 anomalous access: review the principal and data accessed; restrict the bucket.
• Unusual API activity from a role: check whether credentials were taken from an instance (look for IMDS misuse).

Tuning

Use suppression rules for findings you have confirmed as expected — for example, a known vulnerability scanner — and document the reason. Use trusted IP lists for your own egress addresses.

Closing the loop

Record each finding's outcome. Recurring findings point to missing preventive controls, not just alerts to close.