Security Hub finding workflow status plus GuardDuty detection coverage, showing incident response procedures are exercised: enabled insights, automated response actions routed through EventBridge, automated notifications, and Systems Manager Automation documents that encode response steps
The API supplies the facts, but a human judgement against a documented baseline turns them into evidence.
Fetch
$ aws securityhub get-findings --filters '{"WorkflowStatus":[{"Value":"RESOLVED","Comparison":"EQUALS"}],"SeverityLabel":[{"Value":"HIGH","Comparison":"EQUALS"}]}' --query 'Findings[].{Id:Id,Title:Title,Type:Types[0],Severity:Severity.Label,Resource:Resources[0].Id,Updated:UpdatedAt}'$ aws guardduty list-detectors --query 'DetectorIds[0]'$ aws guardduty get-detector --detector-id <DETECTOR_ID> --query '{Status:Status,Features:Features[].{Name:Name,Status:Status}}'$ aws events list-rules --name-prefix guardduty --query 'Rules[].{Name:Name,Pattern:EventPattern,Targets:State}'$ aws ssm list-documents --filters Key=Owner,Values=Self --filters Key=DocumentType,Values=Automation --query 'DocumentIdentifiers[].{Name:Name,Owner:Owner,Version:DocumentVersion,Type:DocumentType}'$ aws cloudwatch describe-alarms --alarm-name-prefix SecurityHub --query 'MetricAlarms[].{Name:AlarmName,State:StateValue,Actions:AlarmActions,Metric:MetricName}'Expected output
Security Hub findings that reached RESOLVED status (proving the workflow was exercised end-to-end), GuardDuty detector status with features showing which data sources are enabled, EventBridge rules prefixed with guardduty that route findings to targets, Systems Manager Automation documents owned by the account that encode response steps, and CloudWatch alarms that fire on Security Hub metrics.
Assertions — what makes it a pass
| Field | Must be | For | Proves |
|---|---|---|---|
| resolved-high-findings.Findings | existsThe RESOLVED/HIGH get-findings call returns a non-empty Findings array within the review window, proving the incident response workflow was exercised end to end rather than merely configured. | every row | IR-04IR-04 (01)IR-08 |
Authored opinion, like the commands. Units live in the operator name — max-age-days is days, and nothing here is converted for you.
Map — what it proves
- recipe10
- recipe— an authored recipe collects evidence for this control
- KSI only— a Key Security Indicator reaches it, but no recipe is authored yet
- orphan— no Key Security Indicator reaches it — a person writes it up instead
What else these families can fetch:IR 10/24 →SI 10/35 →
GovCloud
Security Hub, GuardDuty, EventBridge, Systems Manager and CloudWatch are available in both AWS GovCloud (US-East) and (US-West); findings and document ARNs use partition arn:aws-us-gov. GovCloud FIPS endpoints are used by default for all services.
Notes & assertions
IR-4 wants incident handling capability, IR-4.1 wants automated incident handling, IR-6/6.1/6.3 want reporting to authorities with automated support, IR-7/7.1 want response assistance/coordination, IR-8/8.1 want the incident response plan and its updates, and SI-4.5 wants system monitoring. The evidence here is the infrastructure of response, not the act of responding: resolved findings show the workflow was used, enabled GuardDuty features show detection is active, EventBridge rules show automated routing exists, SSM Automation documents show response steps are encoded as code, and CloudWatch alarms show monitoring. What none of this proves is that the procedures are effective, that notifications reached the right authorities within SLA, or that the incident response plan was actually updated after the event. Those are narrative gaps filled by the plan document, notification records, and AARs. The workflow status is the only pass/fail field here — a finding stuck in NEW or NOTIFIED rather than RESOLVED is a control failure. Substitute your detector ID.
References
- AWS CLI: securityhub get-findings (WorkflowStatus and SeverityLabel filters) https://docs.aws.amazon.com/cli/latest/reference/securityhub/get-findings.html
- AWS CLI: events list-rules (EventBridge guardduty rules) https://docs.aws.amazon.com/cli/latest/reference/events/list-rules.html
- AWS CLI: ssm list-documents (Automation documents) https://docs.aws.amazon.com/cli/latest/reference/ssm/list-documents.html
- AWS CLI: cloudwatch describe-alarms https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/describe-alarms.html
This AWS mapping is authored opinion (overlay v3.0.0), versioned separately from the dataset and written against ruleset 2026.07.14.01. The upstream FedRAMP dataset names none of these tools.
The Incident Response run (3)
- automatable
- partial — needs judgement
- narrative — no API proves this
Every authored recipe filed under INR, in the order the plan works them. The mark says how much of the evidence the command produces on its own.
- partialGuardDuty findings and Security Hub insight summaries that were reviewed, together with evidence that the findings fed into an after-action review cycle — AAR documents stored as versioned S3 objects with the incident IDs they referencequarterlyguardduty-incident-after-actionAmazon GuardDuty · AWS Security Hub · Amazon S3
- partialSecurity Hub finding workflow status plus GuardDuty detection coverage, showing incident response procedures are exercised: enabled insights, automated response actions routed through EventBridge, automated notifications, and Systems Manager Automation documents that encode response stepsyou are heremonthlysecurityhub-incident-review-proceduresAWS Security Hub · Amazon GuardDuty · AWS Systems Manager · Amazon CloudWatch
- partialRecurring GuardDuty finding types and patterns queried across a multi-quarter window, plus Athena SQL over CloudTrail data, surfacing whether the same attack vectors repeat and whether the same misconfigurations are reintroduced after remediationquarterlyguardduty-pattern-review-past-incidentsAmazon GuardDuty · AWS CloudTrail · AWS Security Hub · Amazon Athena · Amazon S3