Contingency Plan | Resume Mission and Business Functions

To meet NIST SP 800-53 Rev 5 CP-2(3), your contingency plan must explicitly define which mission and business functions you will resume after a disruption and the time period within which each must be restored once the plan is activated. You operationalize this by mapping functions to recovery time objectives, concrete recovery steps, owners, dependencies, and testable evidence. ¹

Key takeaways:

• Define “mission and business functions” in your context, then assign a specific resumption time period to each once contingency activation occurs. ¹
• Your plan must be executable: owners, prerequisites, dependencies (including third parties), and step-by-step runbooks tied to time targets.
• Auditors look for proof you can meet your stated time period: tests, results, corrective actions, and evidence that updates follow system or business change.

CP-2(3) sounds simple, but programs fail it for one reason: the contingency plan describes “how we recover” while never committing to “what must be back” and “by when” after activation. The control enhancement forces precision. You have to define the mission/business functions that matter, then plan the resumption of those functions within a defined time period starting from the moment you activate the contingency plan. ¹

For a FedRAMP-aligned cloud environment, this requirement is not limited to infrastructure recovery. It includes business-relevant outcomes such as restoring authentication, logging, customer support workflows, billing if applicable, and any function your authorizing customer depends on to meet their own mission. Your “time period” must be realistic, internally approved, and backed by capabilities: people, tooling, alternate processing paths, and third-party commitments.

This page gives requirement-level guidance you can apply immediately: how to scope “functions,” set resumption time periods, write actionable runbooks, and retain evidence that survives an assessment.

Regulatory text

Requirement (verbatim): “Plan for the resumption of organization-defined mission and business functions within an organization-defined time period of contingency plan activation.” ¹

What the operator must do:

1. Define which mission and business functions are in scope for the system/service.
2. Define the time period within which each function must be resumed, measured from contingency plan activation.
3. Document a realistic, executable plan to resume those functions within that time period, not just “recover systems.” ¹

Plain-English interpretation

You must be able to answer, in writing and with evidence:

• “If we declare an incident/disaster and activate the contingency plan, what business outcomes do we restore first?”
• “How fast do we restore each outcome?”
• “What exact steps, in what order, with what dependencies, get us there?”

In practice, assessors expect your resumption time period(s) to align with your broader contingency planning posture (for example, your BIA outputs, recovery objectives, and test results), but CP-2(3) specifically cares that the plan includes function resumption targets tied to activation. ¹

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies. ¹

Operational context where this control shows up:

• FedRAMP or NIST 800-53 aligned authorization, where your system supports agency mission needs.
• Production environments where outages, ransomware, cloud region failures, identity failures, or third-party incidents can halt delivery of critical services.
• Any environment where “mission function” is broader than IT (for example, case processing, citizen services, payments, or public safety workflows that rely on your service).

Common scoping boundary: apply this at the system boundary defined for authorization. If multiple products share infrastructure, you still need function resumption commitments per authorized system because dependencies and priorities vary.

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

Step 1: Define “mission and business functions” for the system

Create a function inventory that reflects outcomes, not components.

Good function statements (outcome-based):

• “Users can authenticate and obtain access tokens to the service.”
• “Customer can submit and retrieve records through the primary API.”
• “Security team can ingest and review audit logs needed for incident response.”

Weak function statements (component-based):

• “Database is up.”
• “Kubernetes cluster is running.”

Tie each function to:

• Primary users (agency operators, public users, internal teams)
• Supporting systems/services
• Data stores involved
• Third parties (IdP, DNS, email provider, ticketing system, payments, MSSP)

Step 2: Set a resumption time period per function

CP-2(3) requires an “organization-defined time period” from contingency plan activation. ¹

Operationalize this as a simple table in the contingency plan:

Function	Priority	Resumption time period (from plan activation)	Minimum acceptable service level	Owner
Authentication for privileged admins	Highest	[your defined period]	Break-glass access only acceptable initially	IAM lead
Primary customer API	High	[your defined period]	Read-only mode acceptable	SRE lead
Audit log availability to IR team	High	[your defined period]	Access to last known good log archive	SecOps lead

Rules that make this defensible:

• Use one clock start: contingency plan activation time.
• Define what “resumed” means (minimum acceptable service level). Without that, teams claim success while customers still cannot operate.
• Get formal approval from business/system owners. If the CCO or authorizing stakeholder signs off, it signals governance, not wishful thinking.

Step 3: Build resumption runbooks that can meet the time periods

For each high-priority function, add a runbook that includes:

1. Activation trigger and decision authority
   • Who can activate the plan and how the decision is recorded.
2. Prerequisites
   • Offline admin credentials, break-glass procedure, access to backups, contact lists, encryption keys, vendor portals.
3. Recovery steps with sequencing
   • “Restore identity first, then network controls, then app tier, then data.”
4. Dependency recovery
   • Explicitly call out third parties and what happens if they are down (alternate IdP, alternate comms channels, manual workarounds).
5. Validation
   • Specific checks that prove the function is “resumed” at the defined minimum service level.
6. Communications
   • Internal updates, customer/agency notifications, and escalation paths.

Step 4: Align third-party commitments to your resumption plan

If your function resumption depends on third parties (cloud hosting, DNS, IdP, monitoring, support desk), you need contractual and operational alignment:

• SLA/SLO expectations (qualitative is fine if you cannot negotiate numbers).
• Escalation contacts and on-call processes.
• Evidence of their own continuity capabilities, when obtainable through due diligence.

A common failure is writing a fast resumption target that assumes third-party recovery priorities match yours. Fix it by documenting dependency-specific contingencies (alternate providers, cached configurations, manual procedures).

Step 5: Test the resumption of functions, not just backups

Design tabletop and technical tests that validate:

• You can activate the plan cleanly (decision record exists).
• Runbooks restore the function within your defined time period.
• Workarounds deliver the minimum acceptable service level.
• Gaps become tracked corrective actions with owners and due dates.

Step 6: Keep it current through change management

Any change that impacts dependencies, architecture, staffing, or third parties should trigger a contingency plan review. Most audit findings arise because the plan is “approved” but stale: wrong phone numbers, deprecated services, or a recovery step that no longer matches production.

Where Daydream fits (practical, non-disruptive)

If you manage many third parties that underpin resumption, Daydream can centralize third-party due diligence artifacts, map vendors to critical functions, and track continuity-related evidence requests and renewals so your CP-2(3) commitments match third-party reality.

Required evidence and artifacts to retain

Assessors typically want evidence in three buckets: definitions, executable plans, and proof.

Definitions

• Approved list of mission/business functions for the system
• The defined resumption time period(s) per function and the definition of “resumed”

Executable plan artifacts

• Contingency plan document that includes function resumption section
• Function-specific runbooks with owners, prerequisites, dependencies, and validation steps
• Dependency map (including third parties) for each critical function
• Contact lists and escalation paths (with a review cadence you can defend)

Proof

• Tabletop and/or technical test plans and results
• Evidence of activation decision records during exercises
• Corrective action tracking (tickets, postmortems, lessons learned) and closure evidence
• Change management records showing reviews/updates after material changes

Common exam/audit questions and hangups

• “Show me where you defined your mission and business functions.”
• “Where is the time period defined, and what is the start time?” (Auditors will look for ambiguity between ‘incident start’ and ‘plan activation.’)
• “How do you prove you can resume Function X within your time period?” (They want test results tied to that objective.)
• “What third parties must be up to meet this? What if they are not?”
• “When was the plan last updated, and what triggered the update?”

Frequent implementation mistakes and how to avoid them

1. Mistake: Only listing IT assets, not functions.
   Avoidance: Write function outcomes in user language, then map systems beneath them.

2. Mistake: Defining a time period but not defining “resumed.”
   Avoidance: Add “minimum acceptable service level” per function and validation checks.

3. Mistake: Time periods that assume perfect conditions.
   Avoidance: Include staffing assumptions, access prerequisites, and third-party failure modes.

4. Mistake: Testing “backup restore” and calling it resumption.
   Avoidance: Test end-to-end function availability and operational workflow (auth, access controls, logging, customer usability).

5. Mistake: Stale plans.
   Avoidance: Tie plan review to architecture change, major releases, and third-party changes; retain change-trigger evidence.

Risk implications

Failing CP-2(3) creates two practical risks:

• Operational risk: you restore infrastructure but cannot restore mission outcomes quickly enough for customers to operate, which drives extended outages and manual workarounds.
• Assurance risk: you may pass “we have a plan” controls while failing “we can meet our own objectives.” That gap shows up fast in FedRAMP-style assessments because the requirement explicitly demands defined time periods and mission/function resumption planning. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Identify system owner(s) and the decision authority for contingency plan activation.
• Produce a draft mission/business function list and validate it with business and technical leads.
• Draft the resumption time period table and “resumed means…” definitions for top functions.
• Build a dependency map for those functions, including third parties.

By 60 days (Near-term)

• Write or update function-level runbooks with prerequisites, sequencing, and validation.
• Run a tabletop exercise focused on resuming the highest-priority functions; capture evidence and gaps.
• Open corrective actions for missing prerequisites (break-glass, access, backups, contacts) and assign owners.

By 90 days (Operationalize)

• Run at least one technical exercise that executes key runbook steps and validates function resumption.
• Close high-risk corrective actions or document compensating steps and revised assumptions.
• Implement a lightweight governance loop: change-triggered updates, periodic reviews, and third-party dependency revalidation (use Daydream to track evidence requests and renewal dates if third parties are a major dependency).

Frequently Asked Questions

Do I need a separate resumption time period for every function?

No, but you need defined time periods for the mission and business functions you choose to define. Grouping is acceptable if the grouping is logical, documented, and testable against the plan activation clock. ¹

What counts as “contingency plan activation” in practice?

Define it as a formal decision point with an authorized approver and a recorded timestamp. Examiners commonly challenge plans where “activation” is implied but never operationally defined.

Can “resumption” mean partial service (for example, read-only mode)?

Yes, if you document the minimum acceptable service level per function and your stakeholders accept it. Your runbooks and validation checks must confirm that minimum state.

How do I handle third-party outages that block my resumption targets?

Document the dependency explicitly and add a fallback (alternate provider, cached configuration, manual workflow, or a revised minimum service level). Keep due diligence evidence that you evaluated the third party’s continuity posture.

What evidence is most persuasive in an audit?

Test results that tie directly to the defined function and its resumption time period, plus corrective actions that show you addressed gaps. A signed plan without exercises rarely satisfies assessors for this enhancement. ¹

Our architecture changes weekly. How do we keep this from becoming shelfware?

Make contingency updates a change-management deliverable for material changes (identity, networking, data stores, region strategy, third parties). Keep a simple log of what changed, what runbook was updated, and who approved it.

Footnotes

1. NIST Special Publication 800-53 Revision 5