CP-2(3): Resume Mission and Business Functions

CP-2(3) requires you to pre-plan how you will restart your organization’s defined mission and business functions within a stated recovery time after you activate your contingency plan. To operationalize it, set recovery time objectives per function, map dependencies and recovery sequences, assign accountable owners, and prove through exercises that you can meet the timelines. ¹

Key takeaways:

• Define which mission/business functions are in scope and the maximum time allowed to resume each after contingency activation. ¹
• Translate timelines into executable runbooks: sequencing, dependencies, responsible roles, and recovery prerequisites. ¹
• Keep assessment-ready evidence: plan text, dependency maps, exercise results, and corrective actions tied to resumption timelines. ¹

CP-2(3): resume mission and business functions requirement is a planning-and-proof control. Assessors are looking for two things: (1) that you’ve identified the functions that must come back first after a disruptive event, and (2) that you can resume them within the time window you defined, measured from contingency plan activation. The control language is short, but the operational lift is real because “resume” is not the same as “systems are up.” It means the business can perform the function at an acceptable level, with the people, process steps, data, third parties, and technology working together.

For a CCO, GRC lead, or Compliance Officer, the fastest path is to treat CP-2(3) as a mini “service restoration contract” between the business and IT/operations: each critical function has an owner, a target resumption time, dependencies, and a recovery sequence that can be executed during an incident without improvisation. Your goal is assessment-ready clarity: a reviewer should be able to trace from a function, to its resumption time requirement, to the specific procedure and evidence that show you can meet it. ²

Regulatory text

Requirement (verbatim): “Plan for the resumption of {{ insert: param, cp-02.03_odp.01 }} mission and business functions within {{ insert: param, cp-02.03_odp.02 }} of contingency plan activation.” ¹

What the operator must do

• Name the mission and business functions that matter (the parameterized placeholder reflects your defined set of functions). ¹
• Set a resumption time window for those functions, measured from the moment you activate the contingency plan (the second placeholder is your defined timeframe). ¹
• Write the plan so it is executable, not aspirational: a recovery sequence, prerequisites, roles, and handoffs that restore the functions in time. ¹

Plain-English interpretation

You must be able to answer, in writing: “If we declare a contingency event, how do we get our most important business outcomes running again fast enough?” CP-2(3) forces you to turn business impact thinking into a practical restart plan.

Assessors usually probe four realities behind the wording:

1. Time starts at contingency plan activation, not when an outage begins. Your trigger criteria must be clear enough to anchor the clock.
2. Functions come first; systems support them. A resumed function may require multiple systems, manual workarounds, or third-party processes.
3. Resumption is staged. You may restore a minimal viable level first, then full capacity later; your plan must define what “resumed” means for each function.
4. A plan without evidence fails in practice. Exercises, test results, and corrective actions show the plan is used and improved. ²

Who it applies to

CP-2(3) applies where NIST SP 800-53 is the control baseline or is flowed down contractually, including:

• Federal information systems subject to NIST SP 800-53 control selection and assessment. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are imposed via contracts, overlays, or agency requirements. ²

Operationally, this control lands on environments where downtime has mission impact: citizen services, regulated processing, security operations, revenue collection, healthcare delivery, and critical internal services (identity, endpoint management, ticketing) that are required to restore other functions.

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

Step 1: Define “mission and business functions” in scope

Create a short catalog of functions (not applications). Examples: “process customer payments,” “dispatch field service,” “authenticate workforce access,” “issue safety alerts,” “settle trades.”

For each function, define:

• Business owner accountable for resumption acceptance.
• Minimum acceptable service level that counts as “resumed” (for example: manual processing allowed, reduced throughput acceptable).
• Resumption time requirement: your chosen timeframe from contingency plan activation. ¹

Deliverable: a “Function Resumption Register” that is controlled, versioned, and reviewed on a defined cadence.

Step 2: Convert timelines into recovery sequencing

Build an ordered recovery sequence that makes sense under stress:

• Tier functions (first-wave, second-wave, later) based on mission impact.
• Document dependencies per function:
  • People: specific roles, on-call coverage, surge staffing
  • Process: manual workarounds, approvals, communications
  • Technology: identity, network, key apps, data stores
  • Third parties: cloud/SaaS, payment processors, call centers, logistics
• Set prerequisites: credentials, break-glass access, backup availability, clean-room builds, alternate sites.

A strong artifact is a one-page “recovery dependency map” per top-tier function, with the sequencing logic explicit.

Step 3: Write executable runbooks tied to each function

For each in-scope function, produce a runbook that a responder can follow:

• Activation trigger and who declares contingency activation (ties the start time to a role).
• Recovery steps in order (include decision points and stop conditions).
• Contacts and escalation paths (include third-party escalation procedures).
• Data restoration steps and validation checks that confirm the function is actually operating.
• Communications steps: internal stakeholders, customers, regulators (as applicable).

Keep the runbook format consistent. Consistency reduces mistakes during an incident.

Step 4: Validate through exercises and capture corrective actions

Your plan must survive reality. Run exercises that prove the resumption steps and timelines are achievable.

• Tabletop for governance and decision-making (activation criteria, prioritization conflicts).
• Technical recovery test for critical dependencies (identity, network, backups).
• End-to-end functional restoration for at least the most critical function(s), including business validation that the function is “resumed” per your definition.

Track gaps to closure. The audit posture comes from the loop: test → finding → remediation → retest.

Step 5: Assign ownership and recurring evidence

Operationalize ownership so the control does not decay:

• Control owner (often BC/DR lead or resiliency manager)
• Function owners (business)
• Technology owners (app, infrastructure, identity)
• Third-party relationship owner for critical providers

Practical way to keep this clean: maintain a control mapping that ties CP-2(3) to owner, procedure, and recurring evidence artifacts, so you can answer assessors quickly and consistently. Daydream is commonly used here to keep the mapping, evidence requests, and renewal reminders in one place without chasing spreadsheets. ¹

Required evidence and artifacts to retain

Assessments tend to move faster when evidence is pre-organized. Maintain:

• Contingency plan section explicitly addressing resumption of mission/business functions and the defined timeframe. ¹
• Function Resumption Register (functions, owners, resumption definition, timelines).
• Dependency maps (systems, people, facilities, third parties).
• Runbooks (function-oriented, versioned, approved).
• Exercise package: scenarios, attendance, results, timestamps, issues list.
• Corrective action log: owner, target date, status, retest notes.
• Change records showing runbook updates after material system/process changes.

Common exam/audit questions and hangups

Expect questions like:

• “Show me where the plan states the resumption timeframe, and how it’s measured from activation.” ¹
• “Which functions are ‘mission and business functions’ here, and who approved that list?”
• “Define ‘resumed’ for this function. What does the business accept as minimum operation?”
• “Prove you can meet the timeframe: show the last exercise evidence and remediation.”
• “What third parties are required to resume the function, and what happens if they are down?”

Hangups that slow audits:

• Timelines exist for systems (RTO/RPO) but not for functions.
• Runbooks restore servers but don’t include business validation steps.
• Third-party dependencies are undocumented or lack escalation paths.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
“Resume” equals “service is reachable”	Users may not be able to complete the business outcome	Add business acceptance checks (transactions, workflows, reconciliations)
One blanket resumption time for everything	Creates false confidence and poor sequencing	Set timelines per function; document rationale
No clear activation trigger	The “clock” is ambiguous	Define who activates contingency and what evidence marks activation
Dependency mapping stops at applications	People/process/third party gaps derail restoration	Expand dependencies to roles, manual steps, third parties
Tests are informal or not retained	You cannot prove capability	Standardize exercise evidence package and corrective action tracking

Enforcement context and risk implications

No public enforcement cases were provided in the source material for CP-2(3). The practical risk is still direct: if you cannot resume critical functions within your defined timeframe after a contingency activation, you face mission failure, contractual nonperformance, and audit findings tied to control design and operating effectiveness. ²

A practical 30/60/90-day execution plan

First 30 days (Immediate)

• Assign a single accountable owner for CP-2(3) and identify function owners.
• Draft the Function Resumption Register for top critical functions.
• Set initial resumption time requirements and define “resumed” for each function. ¹
• Identify top third-party dependencies and confirm escalation contacts.

By 60 days (Near-term)

• Produce function-oriented runbooks for the highest-priority functions.
• Complete dependency maps and sequence diagrams for those functions.
• Run a tabletop exercise focused on activation criteria, prioritization, and communications.
• Open corrective actions with owners and due dates; start remediation.

By 90 days (Operationalize)

• Run at least one end-to-end recovery test that includes business validation of “resumed.”
• Close or formally risk-accept high-severity corrective actions with documented approvals.
• Baseline recurring evidence: runbook review cadence, exercise schedule, and artifact repository structure.
• Implement a control-to-evidence mapping workflow (often tracked in Daydream) so evidence collection does not restart from zero each assessment cycle. ¹

Frequently Asked Questions

What counts as “mission and business functions” for CP-2(3)?

Use a business-outcome list, not an application list. If leadership would call an emergency meeting when it stops, treat it as a candidate function and document the owner, dependencies, and resumption time. ²

Does CP-2(3) require a specific RTO like “24 hours”?

No fixed number is stated in the control text; you define the timeframe parameter. What matters is that the plan explicitly commits to a timeframe from contingency activation and you can support it with tested procedures. ¹

How do we prove “resumption” versus “systems restored”?

Add business validation steps to each runbook (for example, complete a transaction, reconcile a report, or execute a core workflow). Keep exercise evidence showing the validation occurred and whether it met the timeframe. ²

What if a third party is required to resume the function?

Treat the third party as a dependency with a named owner, escalation process, and workaround path if the provider is unavailable. Document this in the dependency map and runbook so the recovery sequence remains executable. ²

Can we meet CP-2(3) with a tabletop exercise only?

A tabletop can validate governance and sequencing, but it often won’t prove technical and operational feasibility. Pair it with at least one practical recovery test for the most critical function and retain the results and corrective actions. ²

How should a GRC team keep evidence audit-ready without constant chasing?

Maintain a control mapping that links CP-2(3) to the owner, procedure, and recurring evidence artifacts, and collect exercise packages and runbook reviews in a consistent repository. Teams often manage this workflow in Daydream to reduce manual follow-up. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5