IR-08 Incident Response Planir-8

IR-3 wants incident response tested, IR-4 wants incidents handled and lessons learned applied, IR-4.1 wants automated handling support, and IR-8 wants an incident response plan. GuardDuty findings and Security Hub insights are telemetry, not proof that anyone acted on them. The S3 AAR objects close the loop: they show someone reviewed the finding, and that the review produced a document. What the API cannot prove is that the lessons were actually incorporated into the plan — that is a human judgement from the AAR content. An after-action report without a recommendation-to-plan-change linkage is a finding without a fix. If no AARs exist yet, this recipe is the trigger to create them, not evidence that the control is satisfied. Substitute your detector ID, evidence bucket name and insight ARNs. GuardDuty list-findings returns at most 50 findings per page; add --max-results and --next-token pagination for a full quarter.

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.

IR-3 wants testing for repeated flaws, IR-4/4.1 wants incident handling, IR-5 wants incident monitoring, and IR-8 wants the response plan. The pattern review is the quarterly audit of whether the environment is getting healthier or sicker: a recurring finding type across quarters means the root cause was not fixed, and a high Count on a GuardDuty finding means the same attack vector struck multiple times. The honest gap: finding telemetry does not prove anyone reviewed the pattern — the review is the human step of comparing this quarter against last quarter and recording the conclusion. If the same finding type appears in every quarterly pull, the control is failing even when the telemetry is clean, because the root cause is unaddressed. The CloudTrail signin query is a sample, not exhaustive — replace with an Athena query against your trail S3 bucket for a full year of authentication events. Security Hub FirstObservedAt and LastObservedAt show how long a finding has persisted; a gap between them and the current date means the finding was fixed and then reintroduced. This recipe deliberately states no assertion: the check that matters — this quarter's finding types compared against last quarter's, read against the prior after-action report's root-cause fix — spans two collections and a document, so no single command output decides it. A quarter-over-quarter diff is the reviewer's work, and writing it down as a machine assertion would claim a check nothing can run.