CP-4(5): Self-challenge

CP-4(5): self-challenge sits in the Contingency Planning family and focuses on proving that your system can tolerate disruption, not just claiming it can. The control text is intentionally parameterized, which pushes an operator decision back onto you: what methods will you use, and what do you intend to achieve by using them. (NIST SP 800-53 Rev. 5 OSCAL JSON)

For a Compliance Officer, CCO, or GRC lead, the fastest path to implementation is to make this requirement “audit-shaped”: name an owner, define a repeatable procedure, constrain the blast radius, and produce consistent evidence artifacts each cycle. If you cannot show a self-challenge plan, execution records, and remediation tracking, most assessors will mark the control as not implemented or not operating effectively, even if engineering teams run occasional game days.

This page gives requirement-level guidance you can hand to an engineering leader and an auditor at the same time: what the requirement means, who it applies to, what to do step-by-step, what evidence to retain, and the exam questions that commonly stall teams.

Regulatory text

Control excerpt (verbatim): “Employ {{ insert: param, cp-04.05_odp.01 }} to {{ insert: param, cp-04.05_odp.02 }} to disrupt and adversely affect the system or system component.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator meaning of the parameters: NIST leaves two blanks for you to define in your environment:

1. What you will employ (the self-challenge methods/techniques), and
2. What you are trying to achieve (the objective of the disruption and what “adversely affect” means in measurable terms for your system). (NIST SP 800-53 Rev. 5 OSCAL JSON)

What you must do: You must intentionally create controlled disruption using your chosen self-challenge techniques and observe the system or component response, then use the results to validate and improve resilience and contingency outcomes. The control expects purposeful testing, not accidental downtime.

Plain-English interpretation (what auditors expect you to mean)

CP-4(5): self-challenge requirement expects a documented, repeatable practice where you:

• Induce failure modes on purpose (or conditions that mimic them),
• Limit harm with guardrails (so production impact is controlled and authorized),
• Measure what happened (detection, failover, recovery behaviors, data integrity, operational response),
• Fix what you learn (through tracked corrective actions), and
• Repeat on a defined cadence aligned to risk.

Even if your SRE team already runs “game days,” the compliance gap is usually governance: unclear scope, missing approvals, no defined objectives, and no consistent artifacts.

Who it applies to

Entity types: This requirement is commonly applied to:

• Federal information systems, and
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down via authorization requirements. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational context (where you should apply it):

• Mission/business-critical applications where continuity and recovery matter.
• High-dependency components (identity, DNS, key management, network egress, message queues, databases).
• Shared services and platforms (Kubernetes control plane, CI/CD runners, secrets systems).
• Third-party dependencies that can fail and cascade (cloud regions, SaaS identity providers). This control is about your system, but your system includes dependencies you rely on.

What you actually need to do (step-by-step)

Use this sequence to implement CP-4(5) in an “assessment-ready” way.

Step 1: Assign ownership and publish the procedure

• Name a control owner (often the continuity/resilience lead, SRE manager, or IR/BCP program owner).
• Publish a CP-4(5) self-challenge procedure that states scope, safety constraints, required approvals, and required evidence outputs.
• Map the control to the owner and recurring artifacts so execution is not personality-driven. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Step 2: Define the self-challenge objectives (what “adversely affect” means)

Write objectives that an auditor can evaluate. Examples:

• Validate failover behavior for a service dependency.
• Validate recovery steps in a runbook under time pressure.
• Validate monitoring and alerting detects the induced fault and routes to the correct on-call.
• Validate data integrity under partial failures (timeouts, retries, queue backlogs).

Keep objectives tied to contingency outcomes, not performance tuning.

Step 3: Choose self-challenge techniques with guardrails

Select techniques appropriate for your architecture and risk tolerance. Common techniques (choose what fits your system):

• Dependency interruption (block outbound calls to a critical API in a test environment).
• Compute disruption (terminate instances/pods in a controlled scope).
• Network degradation (latency injection, packet loss in a sandbox).
• Credential/key rotation stress (simulate expired credentials and confirm recovery paths).
• Regional/zone unavailability simulations (where feasible and safe).

Guardrails you should require in the procedure:

• Approved scope (system/component, environments included/excluded).
• Blast radius limits (tenant limits, time windows, rollback steps).
• Safety checks (backup readiness, stakeholder notification, on-call presence).
• Stop conditions (what triggers abort).

Step 4: Plan each event like a controlled change

For each self-challenge event, produce a short plan:

• Objective(s) and hypotheses
• Exact method and steps
• Monitoring/measurement plan (what logs/alerts confirm success/failure)
• Roles (facilitator, injectors, observers, incident commander if needed)
• Communications plan (who is notified before/during/after)
• Backout plan

Treat this as a resilience test that may become an incident.

Step 5: Execute, capture telemetry, and record results

During execution, capture:

• Start/stop times, affected components, user impact (if any)
• Evidence of detection (alerts, tickets, paging events)
• Evidence of response (incident timeline, commands executed, decision points)
• Evidence of recovery (service restored, data checks passed)
• Deviations from the plan and why

Auditors respond well to “we planned X, observed Y, and fixed Z” with timestamps and artifacts.

Step 6: Post-event review and corrective actions

Hold a short post-event review and produce:

• Findings (what worked, what failed, what surprised you)
• Root cause or contributing factors (where appropriate)
• Corrective actions with owners and due dates
• Updates to runbooks, monitoring thresholds, escalation paths
• Inputs to contingency plan updates (if plans were wrong or incomplete)

Step 7: Feed results back into CP-4 core artifacts

CP-4(5) is an enhancement, so tie outputs back to your contingency planning and operational readiness:

• Update recovery runbooks and training materials
• Update system architecture docs if resilience assumptions were wrong
• Track recurring failure patterns and prioritize them in engineering roadmaps

Required evidence and artifacts to retain

Retain evidence in a form that stands alone during an assessment. Minimum artifacts most teams need:

1. CP-4(5) Self-challenge procedure (owner, scope, guardrails, required outputs)
2. Self-challenge schedule or triggers (risk-based rationale)
3. Per-event plan (objectives, steps, rollback, approvals)
4. Approvals (change record, risk acceptance, stakeholder sign-off where required)
5. Execution record (timeline, logs/alerts/screenshots, incident tickets if created)
6. Post-event report (findings, corrective actions)
7. Remediation tracking (ticket IDs, closure evidence, updated docs)
8. Control mapping showing ownership, procedure location, and evidence repository path (NIST SP 800-53 Rev. 5 OSCAL JSON)

If you use Daydream to manage control operations, treat CP-4(5) like any other requirement: assign an owner, store the procedure, and attach recurring evidence artifacts so audits become a review exercise instead of a scramble.

Common exam/audit questions and hangups

Expect these questions and prepare the artifacts above to answer them quickly:

• “What self-challenge techniques do you employ, and why those?” (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “Show me one recent self-challenge event end-to-end: plan, approvals, execution evidence, and remediation.”
• “How do you prevent self-challenge from causing uncontrolled outages?”
• “How do you confirm the system was ‘adversely affected’ in a meaningful way, not just a no-op test?”
• “How do results change contingency plans, runbooks, or engineering priorities?”
• “Who signs off, and how is risk accepted if customer impact is possible?”

Hangups usually appear when teams can’t show repeatability (one-off game day) or can’t prove a feedback loop (no remediation tickets, no updated docs).

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails CP-4(5)	Fix
Running informal game days with no written objectives	Hard to show the intent “to disrupt and adversely affect” is deliberate and measured	Require a one-page plan with explicit objectives and hypotheses
No guardrails or approvals	Auditors see uncontrolled operational risk	Embed self-challenge into change management with stop conditions
Testing only in a lab that doesn’t mirror production	Evidence doesn’t demonstrate resilience of the real system	Define environment strategy: production-like staging plus tightly scoped production tests where justified
Capturing screenshots but not outcomes	“We did a thing” is not “we validated resilience”	Record what broke, what detected it, and how recovery performed
No remediation tracking	Control becomes theater	Create tickets for fixes, link them to the event report, and show closure evidence

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CP-4(5). From a risk standpoint, self-challenge is about reducing the gap between documented recovery assumptions and real behavior under failure. If you skip it, the most common operational consequence is discovering brittle dependencies during an actual outage, when stakes are highest and recovery is slow.

Practical 30/60/90-day execution plan

Use phases rather than promises about exact completion times.

Next 30 days (stand up the control)

• Assign CP-4(5) control owner and backups.
• Draft and approve the self-challenge procedure with guardrails and required artifacts. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Identify the first set of candidate components and pick low-risk self-challenges (start with staging or a narrow production slice).
• Create templates: event plan, execution log, post-event report, corrective action tracker.

Next 60 days (run and prove repeatability)

• Execute initial self-challenge events and produce complete evidence packages.
• Hold post-event reviews and open remediation tickets.
• Update runbooks/monitoring based on findings.
• Socialize learnings with IR/BCP stakeholders so outputs feed contingency planning.

Next 90 days (operationalize and scale)

• Expand coverage to additional critical components and third-party dependencies.
• Define a risk-based schedule or triggers (for example: after major architecture changes).
• Automate evidence collection where possible (log exports, ticket links, change records).
• Use Daydream (or your GRC system) to keep the procedure, ownership, and recurring artifacts in one place for audit readiness.

Frequently Asked Questions

Do we have to run self-challenge in production to meet CP-4(5)?

The text does not mandate production testing, but it requires disruption that meaningfully “adversely affect[s] the system or system component.” (NIST SP 800-53 Rev. 5 OSCAL JSON) If staging is not representative, plan a narrowly scoped production test with strong guardrails and approvals.

What counts as a “self-challenge technique” under CP-4(5)?

The control is parameterized, so you define the techniques that create controlled disruption in your environment. (NIST SP 800-53 Rev. 5 OSCAL JSON) Document the chosen techniques and the rationale for how they test contingency and recovery assumptions.

How do we show auditors that the disruption was intentional and controlled?

Keep the per-event plan, approvals, rollback steps, and execution record together. Auditors want to see deliberate objectives, pre-approved scope, and stop conditions, plus proof you ran the event as planned.

Who should own CP-4(5): GRC, SRE, or IR?

Put ownership with the team that can run and fix resilience tests (often SRE or platform engineering), with GRC setting evidence requirements and review gates. The key is a named owner and a repeatable procedure with artifacts. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What evidence is “enough” for a mature program?

A mature package shows a closed loop: plan → execution telemetry → post-event findings → remediation closure → updated runbooks/contingency artifacts. If any link is missing, the control usually gets challenged during assessment.

We already do tabletop exercises. Does that satisfy CP-4(5)?

Tabletop exercises help, but CP-4(5) explicitly expects methods that “disrupt and adversely affect the system or system component.” (NIST SP 800-53 Rev. 5 OSCAL JSON) Keep tabletops as a complement and add at least some technical fault injection or controlled disruption.