- Differentiate by role — general users need recognize-and-report training; responders and decision-makers need training on the plan, the tooling, and their specific authorities.
- Anchor training triggers to real events (role assignment, onboarding, significant system change) rather than one annual slot everyone forgets.
- Count exercise participation under 03.06.03 as role-based training where it genuinely covers the role, and record it as such.
03.06.04OFFICIAL TITLEPENDING NIST SME REVIEW
03.06.04 — Incident Response Training
03.06 Incident Response · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Requires providing incident response training to system users consistent with assigned roles and responsibilities — within an organization-defined time period of assuming an incident response role or acquiring system access, when required by system changes, and at an organization-defined frequency thereafter — and reviewing and updating the training content at an organization-defined frequency and following organization-defined events.
Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.
NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗Independent interpretation
What this requirement is after
Everyone with a part in incident response gets trained for that part, on a clock: the ordinary user who must recognize and report something odd, the responder who isolates a host, the executive who decides about disclosure. New responders are not left to learn the plan during their first live incident.
Across revisions
New as a standalone requirement in Rev. 3 — Rev. 2 named no dedicated incident response training requirement, leaving it implicit in the general training family. Transitioning organizations need role-based incident response training with defined timing, which general security awareness does not supply.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- Training records tied to incident response roles, dated against the defined time periods
- The training content with its review and update history
Artifacts
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
The other revision
Where this came from in Rev. 2
No direct Rev. 2 counterpart — this requirement is new in Rev. 3. Open the transition crosswalk →
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |