Alternate Processing Site

To meet the alternate processing site requirement, you must pre-establish a secondary processing location (or cloud region/account/tenant) and the agreements, architecture, and procedures needed to transfer and resume essential system operations within your defined recovery time. Make it real: documented, technically ready, tested, and contractually permitted. ¹

Key takeaways:

• Define “essential functions,” a recovery time objective, and what “resumption” means for your system, then engineer the alternate site to meet it.
• Put enforceable agreements in place with every third party involved (cloud, colocation, managed services) so you can legally and operationally fail over.
• Keep auditor-ready evidence: architecture, runbooks, test results, tickets, and contract language that proves the alternate site can actually take over.

“Alternate processing site” sounds straightforward until you’re in an outage and discover your “backup plan” is a slide deck, or your cloud contract doesn’t allow the data movement you assumed. Under FedRAMP Moderate, CP-7 requires you to establish an alternate processing site and the necessary agreements to permit transfer and resumption of essential mission and business functions within a defined time period. ¹

For a Compliance Officer, CCO, or GRC lead, the operational goal is simple: prove you can keep the system’s critical services running (or restore them quickly) even if your primary processing capability is unavailable. The compliance goal is equally specific: define recovery targets, build and document an alternate site that can meet them, and retain evidence that the plan is contractually permitted and routinely exercised.

This page translates CP-7 into concrete implementation steps, audit-ready artifacts, and common examiner hangups. If you run in public cloud, “alternate processing site” often maps to a second region or an isolated secondary environment. If you rely on third parties, it includes their commitments, too. Your job is to turn all of that into something you can execute under stress.

Regulatory text

Requirement (CP-7): “Establish an alternate processing site, including necessary agreements to permit the transfer and resumption of organization-defined system operations for essential mission and business functions within an organization-defined time period.” ¹

What an operator must do

You must:

1. Pick what must recover first (the essential mission/business functions and the system operations that support them).
2. Define the recovery time you will meet (your “organization-defined time period,” typically expressed as an RTO in your continuity planning).
3. Stand up an alternate processing capability that can actually run those essential operations (not just store backups).
4. Secure the agreements that legally and operationally allow you to transfer processing and resume operations (cloud terms, colocation contracts, managed service SLAs, incident support, data portability terms).
5. Demonstrate readiness through documented procedures and evidence that the alternate site is viable (architecture, runbooks, test results, change records). ¹

Plain-English interpretation

CP-7 is “you can’t be a single point of failure.” If your primary processing location fails (region outage, facility loss, account compromise, extended network failure), you must have a prepared alternate site where you can run the system’s essential services again within your stated recovery time.

Two practical implications matter in exams:

• “Alternate site” is a capability, not a promise. Auditors look for technical feasibility: capacity, access, dependencies, and procedures.
• “Necessary agreements” is a real requirement. If a third party must help you fail over or provide the alternate site, the contract must support your plan.

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers (CSPs) operating FedRAMP Moderate systems.
• Federal Agencies operating or sponsoring systems where continuity obligations include alternate processing capability. ¹

Operational contexts where CP-7 becomes “make or break”:

• Single-region cloud deployments (primary risk: regional service disruption).
• Systems with stateful components (databases, queues, identity services) where “spin up elsewhere” is harder than it sounds.
• Third-party dependencies (managed databases, SaaS identity, MSP-operated infrastructure) that may not have matching multi-site commitments.
• Data residency or encryption key custody constraints that can block data movement during a crisis.

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

Use this as a build checklist that results in exam-ready artifacts.

1) Define scope: essential functions and recovery objectives

• Inventory system services and map them to essential mission/business functions.
• For each essential function, define:
  • Recovery Time Objective (RTO): the “organization-defined time period” you commit to.
  • Recovery Point Objective (RPO): how much data loss you can tolerate (often examined alongside CP-7 even if RPO is addressed in other controls).
• Document assumptions: what qualifies as “resumption,” what dependencies must be available (IdP, DNS, KMS, CI/CD access, logging).

Output artifacts

• Business Impact Analysis (BIA) excerpt or continuity impact notes
• System recovery objectives register (RTO/RPO by service)
• Dependency map (internal + third party)

2) Choose an alternate processing site pattern that matches your system

Typical patterns:

• Active/active: both sites serve traffic; failover is traffic shifting.
• Active/passive (warm standby): core services pre-provisioned; data replicated; scaled up during failover.
• Cold standby: minimal infrastructure; restore from backups; slower recovery.

Pick the pattern that can meet your RTO, then write it down as the continuity design. “Second region” alone is not sufficient if you cannot restore identity, keys, or network access in that region.

Design decisions to lock

• How data replicates (native replication, streaming, snapshot shipping)
• How you will fail over (DNS, global load balancing, routing changes)
• How you will rebuild immutable infrastructure (IaC pipelines, golden images)
• How you will maintain security controls (logging, monitoring, IAM) in the alternate site

Output artifacts

• Alternate site architecture diagram(s)
• Failover/failback sequence diagram
• Capacity plan for essential services at the alternate site

3) Put “necessary agreements” in writing (including third parties)

CP-7 explicitly calls out agreements. Build a contract checklist for each third party involved in the alternate site.

Agreement topics to verify

• Service availability across the alternate site (region/service coverage)
• Support responsiveness during declared incidents
• Data portability and access during emergencies
• Right to run and scale workloads in the alternate site (capacity, quotas)
• Any restrictions on replication, cross-region transfer, or backup restoration
• Subcontractor dependencies that could block resumption

If you rely on a managed service provider to execute failover steps, ensure the contract includes:

• Defined responsibilities during failover/failback
• Access and break-glass procedures
• Evidence obligations (tickets, reports, post-incident documentation)

Output artifacts

• Contract excerpts / addenda addressing continuity and failover
• Third-party responsibility matrix (RACI) for failover tasks
• Contact and escalation roster tied to incident response

4) Implement the alternate site technically (make it deployable on demand)

Engineers should be able to answer: “If the primary site is gone, what do we do first?”

Minimum operational expectations you should set internally:

• Infrastructure is reproducible (IaC) and stored in a reachable repository during primary-site outage.
• Credentials and secrets are accessible under controlled break-glass procedures.
• Monitoring/logging works in the alternate site, or you have a documented degraded-mode plan.
• Data restoration steps are scripted where possible.

Output artifacts

• IaC repos and change records
• Break-glass access procedure and approvals
• Backup/replication configuration records

5) Write the runbooks and practice them

Document step-by-step procedures:

• Failover runbook: who declares, who executes, which checks happen, what “service restored” means.
• Failback runbook: how you return to primary safely without data corruption.
• Communications runbook: internal/external notifications, including the sponsoring agency where applicable.

Then test the plan. Tabletop exercises are useful, but auditors will look harder for operational proof (tickets, change approvals, test logs). Keep the scope realistic: test the essential functions first.

Output artifacts

• Approved runbooks with version control
• Exercise plans, results, and remediation tickets
• Evidence of updates after testing (change log)

Required evidence and artifacts to retain

Keep a single “CP-7 evidence bundle” that you can hand to assessors:

• Continuity requirements: essential functions list, RTO definitions, dependency map
• Alternate processing site design: diagrams, environment inventory, capacity assumptions
• Agreements: contracts/addenda and third-party SLAs supporting failover/resumption
• Procedures: failover/failback runbooks, escalation contacts, communications templates
• Testing: exercise reports, screenshots/log exports, post-test corrective actions
• Change management: tickets showing the alternate site is maintained as production evolves

A practical tip: store the evidence bundle in a repository accessible during primary-site failure (and document how to access it).

Common exam/audit questions and hangups

Expect these questions:

• “Show me the organization-defined time period and where it was approved.”
• “Which services are essential, and how did you decide?”
• “Where is the alternate processing site, and what exactly runs there?”
• “Prove you can transfer and resume operations. Where are the test results?”
• “Which third parties are required, and where are the agreements that support failover?”
• “How do you handle IAM, KMS/keys, DNS, and logging during failover?”

Hangups that delay assessments:

• RTO exists in a BIA but is not mapped to system services or architecture decisions.
• Alternate site exists but cannot meet security requirements (logging gaps, missing approvals, incomplete boundary documentation).
• Contracts are silent on incident support, data movement, or scaling during emergencies.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Backups without a runnable site.
   Fix: Tie backups to restoration runbooks and pre-provisioned infrastructure capable of running essential workloads.

2. Mistake: “Second region” with shared fate.
   Fix: Identify shared dependencies (single IdP tenant, single CI/CD control plane, centralized KMS) and create an outage path that still works.

3. Mistake: No third-party continuity commitments.
   Fix: Add contract language for failover support, portability, and service coverage in the alternate location.

4. Mistake: Tests that don’t reflect reality.
   Fix: Test the path you would use under real constraints: limited access, time pressure, and degraded tooling. Record evidence.

5. Mistake: Alternate site drifts from production.
   Fix: Put configuration parity controls into change management. Treat alternate-site readiness as a release criterion for major changes.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t anchor your program to litigation narratives. The practical risk is still clear: failure to establish an alternate processing site can turn a localized incident into an extended outage with mission impact. Under FedRAMP, CP-7 gaps often show up as assessment findings because the evidence is concrete: missing agreements, missing tests, or an alternate site that cannot run the system as described. ¹

Practical 30/60/90-day execution plan

Use this as an execution rhythm. Adjust based on system complexity and release cadence.

First 30 days (stabilize scope and commitments)

• Confirm essential functions, dependencies, and recovery objectives (RTO) are documented and approved.
• Decide the alternate site pattern (active/active, warm standby, cold standby) and document the target-state architecture.
• Inventory third parties required for failover; start contract gap review for continuity language.
• Stand up a CP-7 evidence folder structure and assign owners per artifact.

By 60 days (build and document operational readiness)

• Implement or harden replication/backup restoration paths that support the alternate site.
• Produce failover and failback runbooks with named roles and escalation paths.
• Close critical third-party agreement gaps with addenda or written commitments.
• Validate that security dependencies work in the alternate site (IAM, keys, logging, monitoring) or document compensating steps.

By 90 days (prove it works and keep it current)

• Run a failover exercise for essential functions and capture evidence (logs, tickets, screenshots, outputs).
• Track remediation items to closure and update runbooks/architecture documentation.
• Add ongoing controls: alternate-site readiness checks, periodic exercises, and change management gates that prevent drift.
• If you manage evidence in Daydream, map each artifact to CP-7 once and keep it current via change tickets and test results, so the next assessment is evidence refresh instead of a scramble.

Frequently Asked Questions

Does “alternate processing site” have to be a physical data center?

No. In cloud environments it is often a separate region or separate isolated environment that can run essential services. The key is that it is established and capable of resuming operations within your defined time period. ¹

What counts as “necessary agreements”?

Any contract terms or written commitments required to transfer processing and resume operations, especially where third parties control infrastructure, support, or data movement. If failover depends on a provider’s action or capacity, the agreement must support it. ¹

Do we need to test failover, or is having diagrams enough?

CP-7 requires establishing the site and agreements for transfer and resumption; in practice, assessors expect proof the plan is executable. Keep evidence from exercises or controlled failover tests plus remediation records.

If we use multi-AZ in one region, does that satisfy CP-7?

Multi-AZ improves availability but may not address a region-level failure or other shared dependencies. Document your threat assumptions and ensure the alternate processing site is meaningfully separate for the scenarios you claim to cover.

What if our third party refuses to add continuity language to the contract?

Treat it as a risk decision. Document the gap, evaluate alternate providers or architectures that reduce dependence, and implement compensating procedures where possible. Keep the risk acceptance and rationale in your governance record.

How do we define “essential mission and business functions” for a SaaS product?

Start with the minimum set of customer-facing capabilities and security functions required to deliver the service safely (authentication, core workflows, data access, audit logging). Map those functions to specific system components so your alternate site scope is testable.

Footnotes

1. NIST Special Publication 800-53 Revision 5