Alternate Processing Site | Priority of Service

To meet the NIST SP 800-53 Rev 5 CP-7(3) “Alternate Processing Site | Priority of Service” requirement, you must ensure your alternate processing site agreement(s) explicitly grant your organization priority access to recovery capacity aligned to your availability needs, including stated recovery time objectives (RTOs). In practice, this means contractual priority-of-service language plus evidence that the provider can honor it during a regional event.

Key takeaways:

• Put priority-of-service in the alternate site agreement, tied to your RTOs and availability requirements (NIST Special Publication 800-53 Revision 5).
• Validate the priority is real: capacity reservation, call trees, escalation paths, and test results should support the contract.
• Auditors will ask for proof the agreement maps to system recovery targets, not generic “best effort” disaster recovery terms.

CP-7(3) is one of those requirements that looks like “just contract language” until you have to defend it under audit or during an actual disruption. The control enhancement expects more than “we have a DR site.” It expects your organization to secure priority access to that site so your recovery objectives are achievable during the same incident that drives everyone else to fail over.

For cloud service providers pursuing FedRAMP Moderate (and for federal agencies consuming or operating systems), this requirement usually lands across Security/GRC, sourcing/procurement, and the technical DR owner. Your recovery architecture and runbooks may be solid, but if your alternate processing capacity is shared and your agreement does not guarantee priority, an assessor can reasonably challenge whether your RTOs are attainable under stress.

This page translates the requirement into concrete execution steps: how to structure priority-of-service terms, how to map them to RTOs, what evidence to retain, and what audit questions to prepare for. The goal is to help you operationalize CP-7(3) quickly and defensibly.

Regulatory text

Requirement (excerpt): “Develop alternate processing site agreements that contain priority-of-service provisions in accordance with availability requirements, including recovery time objectives.” (NIST Special Publication 800-53 Revision 5)

What the operator must do

You must (1) have an alternate processing site arrangement and (2) document, in the agreement for that alternate site, priority-of-service provisions that are explicitly aligned to your availability requirements and RTOs (NIST Special Publication 800-53 Revision 5). The practical standard to meet is: if a disruptive event drives multiple customers to the same alternate capacity, your organization’s recovery still has a defined priority path consistent with your recovery objectives.

Plain-English interpretation (what this really means)

If your primary processing environment is unavailable, you need a second place to run the system. CP-7(3) adds a specific twist: your agreement for that second place must state you get priority service so you can recover within your planned timelines.

“Priority-of-service” is the contract and operational mechanism that answers:

• Who gets served first when capacity is limited?
• What capacity is reserved for you (if any)?
• What response and restoration commitments are made, and on what trigger?
• How do those commitments relate to your system’s RTOs?

This is most relevant where the alternate processing site is provided by a third party (colocation, DR-as-a-service, cloud provider DR region, managed hosting) or where you rely on shared internal enterprise recovery resources that can be oversubscribed.

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies (NIST Special Publication 800-53 Revision 5).

Operational contexts where CP-7(3) shows up in audits:

• You rely on a third-party recovery site, warm site, hot site, reserved instances, or recovery capacity that is contractually governed.
• Your recovery design depends on a secondary region/site that could be constrained during a large-scale outage (power, connectivity, regional disaster, cloud control plane issues).
• Your internal alternate site exists, but business units compete for shared recovery infrastructure.

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

1) Identify the “alternate processing site” dependency chain

Create a simple dependency list that answers:

• What is the alternate site (secondary data center, secondary cloud region, DRaaS provider, managed platform)?
• Who controls access to that capacity (your org or a third party)?
• What other third parties must be available for the alternate site to work (network carriers, DNS, identity provider, key management, ticketing/on-call tooling)?

Output: Alternate processing site dependency map (1–2 pages) tied to the system boundary.

2) Define availability requirements and recovery objectives that matter for the agreement

CP-7(3) explicitly points to “availability requirements, including recovery time objectives” (NIST Special Publication 800-53 Revision 5). Pull the authoritative values from your contingency plan/BCDR documentation and ensure they are:

• System-specific (not enterprise generic).
• Approved by the business owner/system owner.
• Feasible relative to the architecture.

Output: A short “RTO/RPO and availability requirements” statement you can attach to the agreement or cross-reference.

3) Translate RTOs into concrete priority-of-service terms

Priority-of-service provisions should not be vague. Draft terms that connect the provider’s obligations to your RTO-driven needs, such as:

• Priority classification: “Customer receives Priority Tier X during disaster declaration affecting primary site.”
• Reserved capacity language: Identify what compute/storage/network capacity is reserved or preferentially allocated.
• Provisioning target: A commitment for when recovery resources will be made available after invocation.
• Support and escalation: 24x7 contacts, escalation timelines, and authority to invoke.
• Concurrency and contention: What happens if multiple customers declare at once? Who arbitrates priority?

If the provider will not commit to reserved capacity, push for explicit priority sequencing (ahead of non-priority customers) and an operational mechanism to enforce it (named queues, pre-approved reservations, or pre-provisioned resources).

Output: Priority-of-service clause set (redlines or addendum).

4) Negotiate the agreement so it is auditable

What auditors and assessors look for is a defensible linkage: availability requirements → RTOs → agreement commitments (NIST Special Publication 800-53 Revision 5). To get there, ensure:

• The agreement names the system/service (or clearly includes it by reference).
• Priority-of-service is not contradicted by other terms like “best efforts” or broad force majeure that swallows the commitment.
• The agreement includes an invocation process (how you declare disaster and request priority service).
• You have the right to test, and testing does not void priority status.

Output: Executed agreement/addendum plus a one-page “audit mapping memo” that points to the exact sections.

5) Operationalize the contract in runbooks and on-call practice

A priority clause that no one can invoke during an incident fails in practice. Update:

• DR runbook to include: when to declare, who declares, how to contact the provider, what ticket type to open, what phrase/identifier triggers priority handling.
• On-call rosters and escalation paths.
• Communications templates.

Run at least a tabletop scenario that exercises the exact invocation path, then capture notes and corrective actions. This supports the “develop agreements” requirement with evidence that the terms are integrated into operations.

Output: Updated DR runbook + tabletop record + corrective action log.

6) Validate the provider can honor priority during stress

CP-7(3) is about agreements, but assessors often probe realism. Build a lightweight validation approach:

• Ask the provider for their procedure for handling priority customers during multi-tenant disaster events.
• Request evidence of capacity management practices relevant to your reserved/preferred allocation (even if summarized).
• Confirm support model and whether priority customers get a distinct escalation queue.

If you are the provider (CSP context), do the inverse: maintain internal procedures and capacity planning artifacts that demonstrate you can deliver priority-of-service as contracted.

Output: Provider confirmation package (emails, documents, meeting minutes) and an internal assessment note.

Required evidence and artifacts to retain

Keep these artifacts in your GRC repository with clear version control:

Core evidence

• Executed alternate processing site agreement(s) with priority-of-service provisions mapped to availability requirements and RTOs (NIST Special Publication 800-53 Revision 5).
• Recovery objectives and availability requirements approval (system owner/business owner sign-off).
• DR/contingency plan section that references the alternate processing site and invocation process.

Supporting artifacts (what saves time in audits)

• Contract excerpt index: page/section numbers for priority clauses, invocation, testing rights, and support escalation.
• Tabletop/test records showing the priority invocation workflow was exercised.
• Third-party management records: due diligence notes or periodic review notes that confirm the arrangement still meets RTO needs.

Common exam/audit questions and hangups

Assessors typically press on these points:

1. “Show me the priority-of-service language.”
   They want executed terms, not a policy statement.

2. “How does this guarantee your RTO?”
   Be ready with a mapping from RTO → required capacity/response → clause.

3. “What happens if everyone fails over at the same time?”
   If your agreement is silent on contention, expect a finding or at least follow-up questions.

4. “Who can declare disaster and invoke priority?”
   If the runbook does not name roles and contacts, you will struggle to defend operational readiness.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: “We have a DR site” but no priority guarantee

Avoidance: Ensure the agreement explicitly addresses priority-of-service, not just “access to facilities.”

Mistake 2: Priority language exists, but it is not tied to RTOs

Avoidance: Add an attachment or cross-reference to your recovery objectives and make the provider commitment readable against those objectives (NIST Special Publication 800-53 Revision 5).

Mistake 3: The clause is negated by broad “best effort” delivery terms

Avoidance: Review the contract holistically. If “best effort” is unavoidable, add specific operational commitments (reserved capacity, named queue, explicit response steps) that narrow ambiguity.

Mistake 4: No defined invocation path

Avoidance: Put invocation steps in both the contract (who contacts whom, how priority is requested) and your runbooks.

Mistake 5: Assuming cloud “multi-region” equals alternate processing site with priority

Avoidance: If your failover depends on capacity that might be constrained, document how priority is guaranteed (reservation constructs, support tiering, or contractual priority).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific actions.

From a risk standpoint, the control targets a predictable failure mode: during widespread disruption, shared recovery resources become scarce. Without priority-of-service provisions aligned to your RTOs, you can end up with a technically sound recovery design that fails under real contention. That creates availability risk, operational risk, and (for regulated environments) audit risk if you cannot demonstrate the agreement supports stated recovery objectives (NIST Special Publication 800-53 Revision 5).

A practical 30/60/90-day execution plan

Days 0–30: Get to a defensible baseline

• Inventory all systems in scope and identify which depend on an alternate processing site arrangement.
• Pull the approved availability requirements and RTOs for the in-scope system(s).
• Collect current agreements and highlight whether priority-of-service is explicit.
• Draft an “RTO-to-agreement mapping” memo to expose gaps quickly.
• If you use Daydream to manage third-party due diligence, set up a record for the alternate-site third party and attach current contracts, runbooks, and the RTO mapping so evidence stays audit-ready.

Days 31–60: Close the contract gap and align operations

• Negotiate an addendum or contract revision adding priority-of-service provisions aligned to RTOs (NIST Special Publication 800-53 Revision 5).
• Update contingency plan/runbooks with invocation steps, contacts, and escalation paths.
• Run a tabletop exercise that includes invoking priority-of-service, and log corrective actions.

Days 61–90: Prove durability and make it repeatable

• Perform a light provider capability confirmation (process for handling concurrent declarations, support escalation model).
• Add periodic review triggers in your third-party lifecycle process (renewal, major architectural change, new RTOs).
• Package the evidence set into an assessor-ready folder: executed agreement, mapping memo, runbooks, tabletop records, and review notes.

Frequently Asked Questions

Does CP-7(3) require a dedicated hot site?

No. It requires alternate processing site agreement(s) with priority-of-service provisions aligned to availability requirements and RTOs (NIST Special Publication 800-53 Revision 5). You can meet it with various architectures if the agreement credibly supports your recovery objectives.

What qualifies as “priority-of-service” language?

Contract terms that specify you receive preferential access to recovery resources or restoration actions during an event, with clear triggers and procedures. Vague “commercially reasonable efforts” language usually triggers audit follow-ups unless backed by specific, enforceable commitments.

We use a major cloud provider. Isn’t priority implied?

Don’t assume. Document what mechanism gives you priority access (reserved capacity constructs, contractual support tiering with defined response actions, or explicit priority clauses). Map that mechanism to your RTOs so the story is defensible (NIST Special Publication 800-53 Revision 5).

How do I map priority-of-service to RTO without sharing sensitive architecture details in a contract?

Use an attachment that states required recovery targets and service expectations at a high level, then reference it in the agreement. Keep sensitive build details in internal runbooks, and show auditors the linkage between the two.

What if the third party refuses to provide priority terms?

Treat it as a risk decision. Options include changing recovery design to reduce reliance on contested capacity, selecting a different provider, or formally accepting the risk with documented rationale and compensating controls. Auditors will still expect a clear explanation for how RTOs remain achievable (NIST Special Publication 800-53 Revision 5).

What evidence is most persuasive in an assessment?

Executed agreement text with priority-of-service clauses, a short mapping from availability requirements/RTOs to those clauses, and a tested invocation runbook. Add tabletop records to show the process is workable under pressure.