IR-03 Incident Response Testingir-3
Whether an AWS call fetches evidence for this control, and what to run. Its Rev5 baselines, the indicators that reach it and the FedRAMP guidance attached to it open below.
Partial2 of 2 recipes reach IR-03, and none is rated full — the output narrows the question, a human judgement closes it.
Amazon GuardDuty · Amazon S3 · AWS Security Hub · Amazon Athena · AWS CloudTrail2 recipes · 9 calls
Collect evidence (2)
Authored AWS recipes whose output is evidence for IR-03. This mapping is this project’s opinion (overlay v3.0.0), versioned separately from the dataset — the upstream FedRAMP rules name none of these tools.
- 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 referencequarterlycliguardduty-incident-after-actionAmazon GuardDuty · AWS Security Hub · Amazon S3
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.
- 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 remediationquarterlycliguardduty-pattern-review-past-incidentsAmazon GuardDuty · AWS CloudTrail · AWS Security Hub · Amazon Athena · Amazon S3
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.
What NIST requires of IR-03
The control statement from NIST 800-53 Rev5, verbatim. Square brackets are organization-defined parameters — yours to set, not FedRAMP's to dictate.
Test the effectiveness of the incident response capability for the system [frequency] using the following tests: [tests].
NIST SP 800-53 Rev5 catalog 5.2.0, from usnistgov/oscal-content at 78650f0. The FedRAMP dataset carries no control text; this is borrowed and pinned.
Rev5 baseline membership
Membership is the whole relationship — a baseline is a set of control ids. Class A carries no baseline at all. The Low/Moderate/High labels are an interpretation from control counts, not a dataset fact.
KSI indicators reaching this control (3)
Under 20x, these indicators are how this control is demonstrated — automated KSI evidence stands in for narrative control evidence.
- INRKSI-INR-AARGenerating After Action Reports
Incident after action reports are generated and lessons learned are persistently incorporated.
- INRKSI-INR-RPIReviewing Past Incidents
Past incidents are persistently reviewed for patterns or vulnerabilities that were not previously apparent or identified.
- RPLKSI-RPL-TRCTesting Recovery Capabilities
The capability to recover from incidents and contingencies aligned with defined recovery objectives is persistently tested.
FedRAMP guidance & parameters
Where you read the rule. Guidance names an FRR document, never a clause, so the links below offer the whole document and leave the reading to you.
- Follow the FedRAMP Incident Evaluation and Communication rules.This guidance points at the Incident Evaluation and Communication rules (IEC, 8 requirements).
All 8 IEC requirements
Pages exist for the 209 controls reached by at least one KSI. Baseline-only controls are the orphans on /coverage. Control titles and full text live in the NIST catalog, not this dataset.