Security requirement
Test the effectiveness of the incident response capability [Organization-defined: frequency].
Discussion
Organizations test incident response capabilities to determine their effectiveness and identify potential weaknesses or deficiencies. Incident response testing includes the use of checklists, walk-through or tabletop exercises, and simulations. Incident response testing can include a determination of the effects of incident response on organizational operations, organizational assets, and individuals. Qualitative and quantitative data can help determine the effectiveness of incident response processes.
Tailoring decisions required
Resolve these values through the governing organization’s approved tailoring and risk-management process before declaring the requirement implemented.
Implementation perspective
Treat Incident Response Testing as a CUI protection outcome that must be reflected in the system boundary, documented implementation, operational behavior, and assessment evidence. Pay particular attention to prepared detection, coordinated response, reporting, recovery, and lessons learned for incidents involving CUI.
- Confirm the requirement is in scope for the CUI system components, services, users, and external connections being assessed.
- Resolve every organization-defined parameter through an approved governance and tailoring process.
- Map each clause of the requirement to an accountable owner, implementation mechanism, and evidence source.
- Verify that inherited and shared implementations are supported by current provider evidence and responsibility boundaries.
- Collect evidence during normal operation and review changes, exceptions, and deficiencies on a risk-based cadence.
Questions to ask
- Which CUI assets, data flows, users, and services are protected by this requirement?
- Which portions are implemented locally, inherited, shared, or not applicable, and what evidence supports that determination?
- Do the system security plan, deployed configuration, operating process, and assessment evidence tell the same story?
- What change, incident, or threshold should trigger reassessment?
Evidence and validation
- incident response plans and playbooks
- case records and timelines
- exercise and tabletop results
- lessons-learned and corrective-action tracking
Common failure patterns
- plans that do not match the current architecture
- unclear authority for containment decisions
- evidence lost during response
- lessons learned recorded but not implemented
Assessment objectives and methods
Assessment objectives (1)
- SR-03.6.3.
the effectiveness of the incident response capability is tested [Organization-defined: frequency].
Examine
- incident response policy and procedures
- contingency planning policy and procedures
- procedures for incident response testing
- procedures for contingency plan testing
- incident response testing material
- incident response test results
- incident response test plan
- incident response plan
- contingency plan
- system security plan
- other relevant documents or records
Interview
- personnel with incident response testing responsibilities
- personnel with information security responsibilities
Source NIST SP 800-53 controls
These controls are referenced by the official SP 800-171 Rev. 3 OSCAL record. Open the corresponding control pages for complete control text, enhancements, D3FEND mappings, and related learning.
Authoritative sources
- NIST SP 800-171 Revision 3 official publication ↗
- NIST SP 800-171A Revision 3 official publication ↗
- NIST OSCAL Content release used for this import ↗
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. The official publications, the responsible federal agency, and the governing contract or agreement determine applicability, tailoring, assessment depth, and required implementation.