CP-3: Contingency Training
The cp-3: contingency training requirement means you must train system users on their contingency and recovery duties, tailored to their roles, and be able to prove the training happened. To operationalize it fast, define role-based training modules tied to your contingency plan, deliver them on a repeatable cadence, and keep completion evidence that maps back to CP-3. 1
Key takeaways:
- CP-3 requires role-based contingency training for system users, not a generic “BCP awareness” course. 1
- Auditors look for a tight chain: roles → required actions in the contingency plan → training content → completion evidence. 2
- Your fastest path is to assign a control owner, publish a procedure, and standardize recurring evidence artifacts for assessment readiness. 1
CP-3 sits in the Contingency Planning (CP) family of NIST SP 800-53 and is easy to misunderstand. Many programs treat it like general security awareness or a once-a-year “business continuity overview.” That typically fails in an assessment because CP-3 is about whether people can execute their specific recovery responsibilities under pressure: declaring an incident, initiating failover, restoring from backups, communicating status, and operating from alternate processes when normal systems are unavailable.
From an operator’s perspective, CP-3 is a training logistics and evidence problem. You need (1) a role model that reflects how recovery actually happens in your environment, (2) training content that references your system’s contingency plan and the tasks people will perform, and (3) proof that training was delivered to the right users. The control text is short, but the expectation is not.
This page gives requirement-level implementation guidance to help a Compliance Officer, CCO, or GRC lead operationalize CP-3 quickly: what it means in plain English, who must be trained, what artifacts to keep, what auditors ask for, and how to build a repeatable training program that survives staff turnover and reorgs. 3
Regulatory text
NIST SP 800-53 Rev. 5, CP-3 excerpt: “Provide contingency training to system users consistent with assigned roles and responsibilities:” 1
Operator interpretation of the text
- “System users” includes more than “all employees.” It means anyone who will take action during a contingency event for the system in scope: engineers, IT ops, help desk, security responders, application owners, business process owners, and any privileged users who perform recovery tasks.
- “Consistent with assigned roles and responsibilities” is the key phrase. Your training must be mapped to role-specific responsibilities that exist in your contingency plan and operating procedures.
- The control is assessed on both design (is there a defined training requirement and curriculum) and operation (did the right people complete it, and can you prove it). 2
Plain-English requirement (what CP-3 really demands)
You must ensure the people who would be involved in responding to a disruption for a specific system are trained on what to do, based on their role. Training has to be targeted, repeatable, and evidenced. A generic “BCP policy overview” rarely shows role alignment, so it typically won’t satisfy the “consistent with roles” part of CP-3. 1
Who it applies to (entity and operational context)
CP-3 is commonly expected in:
- Federal information systems and programs aligned to NIST SP 800-53. 2
- Contractor systems handling federal data, including environments where NIST SP 800-53 controls are flowed down through contracts or authorizations. 2
Operationally, CP-3 applies per system or per system boundary as defined in your security authorization or control scope. If you run multiple production systems, you can centralize training delivery, but you still need to show that training is relevant to each system’s contingency processes.
What you actually need to do (step-by-step)
1) Assign ownership and write the CP-3 procedure
Create a short, executable procedure that answers:
- Who owns CP-3 (often the contingency planning owner or GRC control owner with IT partnership).
- Which systems are in scope.
- Which roles require training.
- How training is delivered (LMS, tabletop session, live drills, runbook walk-through).
- How completion is tracked and how exceptions are handled. 2
Practical tip: Keep the procedure separate from the policy. Auditors want an operational description they can test.
2) Build a role-to-training matrix tied to your contingency plan
Start from your contingency plan and recovery runbooks. Identify the roles that have “must do” actions during disruption. Common roles to include:
- Incident commander / on-call lead
- Backup/restore operator
- Infrastructure/platform engineer (failover, capacity, DNS)
- Application owner (feature flags, safe mode, data integrity checks)
- Security (triage, containment coordination)
- Communications lead (status page, internal updates)
- Business owner (RTO/RPO decisions, manual workarounds)
Then document a role-to-training matrix:
| Role | Contingency responsibilities (from plan/runbooks) | Required training module(s) | Evidence source |
|---|---|---|---|
| Backup operator | Restore, validate, document restoration | Backup & restore walkthrough | LMS completion + restore lab signoff |
| On-call lead | Declare severity, coordinate recovery | Incident command + escalation path | Attendance roster + quiz |
This is where many programs win or lose CP-3. The matrix proves “consistent with assigned roles.” 1
3) Write training content that references real tasks
Keep modules short and job-relevant. Cover:
- How to access contingency documentation during an outage (offline copies, alternate access paths).
- Role-specific checklists (restore steps, failover steps, validation criteria).
- Communication expectations (who to notify, timing, templates).
- Where evidence is recorded during a contingency event (ticketing, incident timeline).
Avoid content that reads like a policy recital. Use screenshots, runbook excerpts, and “if X then Y” decision points.
4) Deliver training and enforce completion for in-scope users
Pick delivery methods that match roles:
- LMS module for baseline responsibilities.
- Instructor-led runbook walk-through for operators.
- Tabletop exercises for leadership and coordination roles.
Enforce completion by integrating training assignment with onboarding and role changes (e.g., HRIS triggers, IAM group membership, or on-call roster membership).
5) Record and retain evidence that maps back to CP-3
Evidence must show:
- Who was trained.
- What they were trained on.
- When it happened.
- That training aligns to the role and the system’s contingency responsibilities. 2
This is where Daydream typically fits: teams centralize CP-3 ownership, link training obligations to roles, and auto-collect recurring evidence artifacts (exports from LMS, sign-in rosters, runbook review attestations) so audits stop becoming a spreadsheet scavenger hunt. 1
Required evidence and artifacts to retain
Minimum artifact set (keep it tight, but complete):
- CP-3 control implementation statement (how your program meets the requirement) mapped to the control owner and scope. 2
- Role-to-training matrix tied to contingency plan responsibilities.
- Training content (slides, LMS module outline, runbook walk-through agenda).
- Training completion records (LMS export, attendance rosters, acknowledgments).
- Exceptions log (users who missed training, compensating action, remediation date).
- Change log showing periodic updates when contingency processes change (new DR architecture, new failover steps).
Retention period is typically driven by your broader records policy and audit needs; CP-3 itself does not specify a retention duration in the excerpt provided. 1
Common exam/audit questions and hangups
Expect assessors to ask:
- “Show me who is required to take contingency training for System X and why.”
- “Show evidence that the on-call team completed training relevant to their recovery tasks.”
- “How do you ensure new team members get trained before they are added to the on-call rotation?”
- “How do you update training when the contingency plan changes?” 2
Hangups that trigger findings:
- Training exists, but it’s generic and not mapped to roles.
- You trained “all employees,” but missed privileged operational roles or contractors who perform recovery work.
- Evidence exists, but you can’t prove population completeness (no authoritative roster or role mapping).
Frequent implementation mistakes (and how to avoid them)
-
Mistake: Treating CP-3 as annual awareness training.
Fix: Split baseline awareness from role-based contingency modules. Keep the role mapping explicit. 1 -
Mistake: No link to the actual contingency plan/runbooks.
Fix: Put contingency plan section references or runbook identifiers directly in the training outline and matrix. -
Mistake: Training population is guessed, not derived.
Fix: Derive training assignments from an authoritative source: on-call roster, IAM groups, CMDB application ownership, or org chart with named responsibilities. -
Mistake: Evidence is scattered and recreated for every audit.
Fix: Standardize evidence artifacts (monthly LMS export, roster snapshot, matrix version) and store them in a control evidence repository. Daydream is commonly used to keep that evidence chain current across systems and owners. 1
Enforcement context and risk implications
No public enforcement cases were provided in the source catalog for CP-3, so you should treat this as an assessment-readiness and operational resilience control rather than a directly “fined” item in isolation.
Risk you are actually managing:
- Operational failure during outages because people do not know recovery steps or escalation paths.
- Assessment findings that can delay authorization, renewals, or contractual approvals when you cannot show role-based training and evidence. 2
Practical 30/60/90-day execution plan
First 30 days (stabilize scope and accountability)
- Name the CP-3 control owner and publish a one-page procedure.
- Identify systems in scope for your immediate assessment boundary.
- Build the first role-to-training matrix for the highest criticality system.
- Inventory existing training assets (BCP training, incident response training, DR runbooks) and note gaps.
By 60 days (deliver training and start evidence collection)
- Publish role-based modules (even if v1 is a runbook walk-through plus a short quiz).
- Assign training based on on-call roster and privileged role groups.
- Start recurring evidence collection (completion exports, attendance rosters, matrix versioning).
- Create an exceptions workflow for missed training and contractor onboarding.
By 90 days (make it repeatable and audit-ready)
- Expand the matrix to remaining in-scope systems or define system-specific deltas.
- Add a change trigger: any contingency plan update requires training update review.
- Run a tabletop or operational walkthrough and capture attendance and lessons learned.
- Centralize evidence and mappings in a single system of record (many teams implement this in Daydream to keep control mapping, ownership, and artifacts aligned). 3
Frequently Asked Questions
Does CP-3 require training for every employee?
CP-3 is scoped to “system users” with contingency responsibilities, and the training must be consistent with assigned roles. Train everyone who will act during a disruption for the system, then document how you determined that population. 1
Can we satisfy CP-3 with a tabletop exercise instead of an LMS course?
You can use instructor-led formats if they teach role-specific responsibilities and you retain attendance and materials. Many programs combine an LMS baseline with a tabletop for key roles so the evidence is clearer. 2
How do we prove the training is “consistent with roles and responsibilities”?
Maintain a role-to-training matrix that cites the contingency plan/runbooks and shows which module covers each responsibility. Auditors accept this because it connects role definition, content, and completion evidence. 1
What about contractors or third parties on the on-call rotation?
If they perform recovery actions for your system, treat them as in-scope system users for CP-3 and require the same role-based training and evidence. Track them through contracts, access groups, and on-call rosters. 2
Our contingency plan is shared across multiple systems. Do we need separate training per system?
You can centralize common content, but you still need to show it’s relevant to the system(s) in scope and covers the specific responsibilities people have for those systems. A shared core module plus system-specific add-ons usually satisfies assessors. 2
What’s the minimum evidence set to keep auditors from sampling us to death?
Keep the implementation statement, role-to-training matrix, training materials, completion records, and an exceptions log. Store them together so you can answer “who, what, when, why this role” without rebuilding the story each audit. 2
Footnotes
Frequently Asked Questions
Does CP-3 require training for every employee?
CP-3 is scoped to “system users” with contingency responsibilities, and the training must be consistent with assigned roles. Train everyone who will act during a disruption for the system, then document how you determined that population. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
Can we satisfy CP-3 with a tabletop exercise instead of an LMS course?
You can use instructor-led formats if they teach role-specific responsibilities and you retain attendance and materials. Many programs combine an LMS baseline with a tabletop for key roles so the evidence is clearer. (Source: NIST SP 800-53 Rev. 5)
How do we prove the training is “consistent with roles and responsibilities”?
Maintain a role-to-training matrix that cites the contingency plan/runbooks and shows which module covers each responsibility. Auditors accept this because it connects role definition, content, and completion evidence. (Source: NIST SP 800-53 Rev. 5 OSCAL JSON)
What about contractors or third parties on the on-call rotation?
If they perform recovery actions for your system, treat them as in-scope system users for CP-3 and require the same role-based training and evidence. Track them through contracts, access groups, and on-call rosters. (Source: NIST SP 800-53 Rev. 5)
Our contingency plan is shared across multiple systems. Do we need separate training per system?
You can centralize common content, but you still need to show it’s relevant to the system(s) in scope and covers the specific responsibilities people have for those systems. A shared core module plus system-specific add-ons usually satisfies assessors. (Source: NIST SP 800-53 Rev. 5)
What’s the minimum evidence set to keep auditors from sampling us to death?
Keep the implementation statement, role-to-training matrix, training materials, completion records, and an exceptions log. Store them together so you can answer “who, what, when, why this role” without rebuilding the story each audit. (Source: NIST SP 800-53 Rev. 5)
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream