CP-7: Alternate Processing Site

CP-7 is a continuity requirement that forces an operational decision: where do your critical workloads run if your primary processing capability goes down, and how fast can you resume? The control is narrower than “business continuity” in general. It targets processing capability (compute, platforms, and supporting services) and requires an alternate processing site that is established in advance, with the agreements and technical prerequisites to transfer operations and resume essential mission and business functions within a defined time.

For most organizations, the alternate site is either a second cloud region/account, a second data center/colo, or a contracted third-party recovery environment. The compliance trap is treating CP-7 as a policy statement instead of a build-and-prove requirement. Auditors will look for concrete linkages: essential functions → supporting systems → recovery objectives → alternate site design → executed agreements → test results.

If you own GRC, your job is to turn CP-7 into a small set of non-negotiables that engineering, infrastructure, and third-party management can execute. This page gives you a requirement-level checklist, the evidence to retain, and common audit failure points.

Regulatory text

NIST SP 800-53 Rev. 5 (CP-7) excerpt: “Establish an alternate processing site, including necessary agreements to permit the transfer and resumption of [organization-defined processing] for essential mission and business functions within [organization-defined time period] when the primary processing capabilities are unavailable;” ¹

What the operator must do (plain reading):

• Establish means you must pick and stand up an alternate site ahead of time, not during an incident.
• Necessary agreements means legal/contractual permissions and commitments must exist (internal MOUs or third-party contracts) so you can actually run workloads there.
• Transfer and resumption of processing means you can move execution to the alternate site and bring critical services back.
• Essential mission and business functions means you must scope what is “essential,” then tie it to systems/workloads.
• Within an organization-defined time period means you must define your recovery time requirement and show your design and testing supports it. ²

Plain-English interpretation (what CP-7 really demands)

CP-7 requires a pre-arranged place to run your critical computing when your primary site is unavailable, plus proof you can switch over and operate within your own defined recovery window.

Think of CP-7 as four commitments you must be able to evidence:

1. A real alternate site exists for in-scope workloads (not “we could restore somewhere”).
2. You have rights and capacity to use it (contracts, reserved capacity, accounts, network access).
3. Your workloads can run there (architecture, dependencies, data replication, IAM, keys, configs).
4. You have practiced (failover/failback tests, lessons learned, updated runbooks).

Who it applies to (entity and operational context)

CP-7 typically applies when you operate information systems aligned to NIST SP 800-53, including:

• Federal information systems.
• Contractor systems handling federal data (for example, environments supporting federal contracts where 800-53 is flowed down). ¹

Operationally, it applies to:

• Production environments supporting essential functions (customer-facing services, safety/regulatory operations, revenue operations, identity services, core integrations).
• Shared services that become single points of failure (identity provider, DNS, secrets/KMS, CI/CD used for emergency changes, logging needed for response).

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

Use this sequence to operationalize CP-7 without turning it into a multi-year program.

Step 1: Define “essential functions” and the recovery window

• Create a short list of essential mission/business functions (owned by business leaders, not only IT).
• For each function, document the required resumption time (your organization-defined time period) and the minimum service level needed during recovery. ¹
• Map functions to the systems/workloads that must be restored to claim “resumed.”

Exam tip: Auditors accept your chosen recovery window, but they will not accept a missing definition.

Step 2: Select the alternate processing site pattern

Pick one pattern per workload tier and document why:

• Active/active across sites (highest complexity, fastest recovery).
• Active/passive warm standby (common for critical apps).
• Backup-and-restore to alternate site (acceptable for less time-sensitive services if it meets your defined window).

Your “site” can be:

• A second cloud region/account/subscription,
• A separate data center/colo,
• A contracted third-party recovery facility.

Step 3: Put agreements and access in place

This is the “you can actually run there” layer:

• Third-party contracts: capacity commitments, service dependencies, support SLAs, data location constraints, breach notification hooks relevant to continuity operations.
• Internal agreements: if another business unit provides the alternate environment, document responsibilities and funding ownership.
• Access: break-glass accounts, privileged access workflows, and documented authorization to execute failover actions.

Common hangup: Teams say “the cloud is the alternate site.” Cloud still requires account structure, quota/capacity assumptions, support plans, and run permissions.

Step 4: Engineer dependency readiness (the part that breaks during real outages)

For each in-scope system:

• Data replication: databases, object stores, and stateful queues must replicate to the alternate site with defined controls for consistency and recovery.
• Secrets and keys: ensure KMS/HSM, certificates, and secret stores exist and are accessible in the alternate site.
• Network and identity: routing, DNS, VPN/peering, firewall rules, and identity federation must support emergency operations.
• External dependencies: document what can block failover (payment processors, upstream APIs, telecom, managed identity, SaaS).

Create a dependency register that states: “If primary is down, dependency X is available from alternate site: yes/no; workaround: …”

Step 5: Write executable runbooks (not narrative DR plans)

For each essential function:

• Trigger criteria (who declares failover, who approves).
• Failover steps with commands/automation references.
• Validation steps (health checks, smoke tests, data integrity checks).
• Communication steps (internal, customer, third parties).
• Failback steps and data reconciliation approach.

Step 6: Test and record evidence

Run exercises that demonstrate:

• You can transfer processing to the alternate site.
• You can resume essential functions within your defined window. ¹

Testing scope should include at least one representative workload per critical tier plus shared services (identity, DNS, logging). Capture failures, corrective actions, and retest evidence.

Step 7: Assign ownership and set recurring evidence

CP-7 fails most often due to “somebody else owns it.” Assign:

• Control owner (often Infra/BCP with Security oversight),
• System owners responsible for workload readiness,
• Third-party owners for contract and capacity reviews.

In Daydream, implement CP-7 as a control with a named owner, an implementation procedure, and a recurring evidence list so audits do not become archaeology. ²

Required evidence and artifacts to retain

Auditors look for a clean thread from requirement → design → operation. Keep:

• Essential functions inventory with defined recovery windows (organization-defined).
• System/workload mapping to essential functions.
• Alternate site architecture diagrams (network, identity, data replication, region/site separation).
• Agreements: contracts/MOUs, capacity commitments, support terms, and documented authorization to fail over.
• Runbooks: failover and failback procedures, with role assignments.
• Test artifacts: exercise plans, execution logs, timestamps, results, issues, corrective actions, retest notes.
• Access evidence: break-glass process, approved access lists, periodic access reviews for DR roles.
• Change management hooks: proof the alternate site stays aligned after major releases (tickets, release checklists, configuration baselines).

Common exam/audit questions and hangups

Expect these questions in a NIST-aligned assessment:

• “Show me the alternate processing site for System X. What is it, and where is it documented?”
• “Where are the agreements that guarantee you can run there during a regional/provider outage?”
• “Which essential functions depend on this system, and what is the required resumption time?”
• “Show evidence of a failover test and the results. What changed afterward?”
• “How do you ensure the alternate site is kept current with production changes?”

Hangups that slow audits:

• No single mapping between essential functions and systems.
• Alternate site exists but cannot operate due to missing keys, IAM, DNS, or third-party allowlists.
• Tests are tabletop only, with no proof of processing transfer/resumption.

Frequent implementation mistakes (and how to avoid them)

1. Calling backups an alternate site. Backups are necessary, but CP-7 requires a site established to resume processing, plus the ability to transfer and run. Document the compute/runtime plan, not only storage.
2. Ignoring shared services. Identity, DNS, and secrets management frequently block recovery. Treat them as first-class recovery dependencies.
3. No contract reality check. If a third party provides the alternate environment, confirm capacity and access rights in writing. Keep the executed agreement.
4. “We can build it during an incident.” CP-7 expects the alternate site is established. Pre-provision accounts, networking, and base infrastructure.
5. One-and-done testing. A single successful test becomes stale after major architecture changes. Tie DR validation to change management for critical systems.

Enforcement context and risk implications

No public enforcement cases were provided in the source data for CP-7, so this page does not cite enforcement actions.

From a risk standpoint, CP-7 gaps typically surface as:

• Extended outages with cascading business impact.
• Inability to meet contractual uptime/continuity commitments.
• Audit findings for “control not implemented” or “not operating effectively” due to missing evidence of alternate site readiness. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and decisions)

• Name the CP-7 control owner and system owner counterparts.
• Define essential functions and recovery windows for the top business services. ²
• Pick the alternate site strategy per tier (active/active, warm standby, restore).
• Inventory current agreements and identify contract gaps for third-party or cloud dependencies.

Days 31–60 (build the operational backbone)

• Document the alternate site architecture for critical systems, including dependency readiness (identity, DNS, KMS, network).
• Put missing agreements in place or document interim internal authorizations.
• Create failover/failback runbooks that are executable and role-assigned.
• Configure monitoring/health checks that can validate service resumption at the alternate site.

Days 61–90 (prove it and operationalize evidence)

• Run at least one failover exercise for a critical workload and capture results.
• Track corrective actions to closure and update runbooks.
• Set recurring evidence collection (tests, access reviews, architecture review triggers after major changes).
• In Daydream, map CP-7 to an owner, implementation procedure, and recurring evidence artifacts so audit prep is a routine export, not a scramble. ²

Frequently Asked Questions

Does a second cloud region count as an alternate processing site?

Yes, if it is established in advance and you can transfer processing and resume essential functions within your defined time window. You still need documented access, dependency readiness, and evidence of testing. ²

Can we satisfy CP-7 with backups plus Infrastructure-as-Code templates?

Sometimes, but only if your approach demonstrably restores processing and resumes essential functions within your organization-defined time period. Keep proof that the restore procedure is executable and tested, not just designed. ¹

What counts as “necessary agreements”?

Any executed contract, MOU, or internal agreement that grants you the right and practical ability to operate at the alternate site during an outage, including capacity/access assumptions. The agreement should align to the recovery approach you chose. ¹

How do we scope CP-7 for a complex microservices environment?

Start with essential functions, then identify the minimum set of services and shared dependencies required to claim resumption. Document that dependency set and test failover at the function level, not service-by-service in isolation.

How often do we need to test the alternate processing site?

NIST SP 800-53 CP-7 requires you to establish the site and be able to resume within your defined time window, but the control text does not specify a fixed test frequency. Set a recurring cadence based on system criticality and trigger additional tests after major architecture changes. ¹

What evidence is most persuasive in an audit?

A clear mapping from essential functions to systems, a documented alternate site architecture, executed agreements, and a dated failover test record with results and corrective actions. That package shows both design and operating effectiveness. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5