CP-7(2): Accessibility

To meet the cp-7(2): accessibility requirement, you must identify what could prevent staff, data, and critical services from reaching your alternate processing site during an area-wide disruption, then document specific mitigations you will execute if those access paths fail. Treat it as an operational “route-and-reachability” plan for your recovery site, not a paper DR add-on. ¹

Key takeaways:

• CP-7(2) focuses on access constraints to alternate sites during regional disruptions, not general backup strategy. ¹
• You need explicit mitigation actions tied to defined accessibility failure scenarios (transport, network, facilities, staffing). ¹
• Auditors will look for evidence you assessed accessibility risks and can execute mitigations, not just that an alternate site exists. ¹

CP-7(2): Accessibility is a contingency planning enhancement under NIST SP 800-53 that gets practical fast: if your primary site goes down, can you actually reach and operate from the alternate processing site under the same conditions that caused the outage? An alternate site that is “available” on paper can still be unreachable due to regional travel restrictions, fuel shortages, widespread power loss, telecom outages, civil emergencies, or building access constraints. CP-7(2) forces you to confront those real failure modes and write down what you will do about them. ¹

For a CCO, GRC lead, or Compliance Officer, operationalizing the control comes down to three things: (1) a documented accessibility risk assessment for the alternate site, (2) a set of concrete mitigations mapped to each identified issue, and (3) retained evidence that the assessment is current and the mitigations are feasible (contracts, runbooks, contact trees, and test results). This page gives requirement-level guidance you can hand to IT, facilities, and business continuity owners and then audit against. ¹

Regulatory text

Requirement (excerpt): “Identify potential accessibility problems to alternate processing sites in the event of an area-wide disruption or disaster and outlines explicit mitigation actions.” ¹

Operator translation (what you must do):

1. Identify accessibility problems that could block your recovery to the alternate processing site specifically during area-wide events (the same kind of disruption that could also degrade roads, carriers, utilities, and local services). ¹
2. Document explicit mitigation actions for each problem. “Mitigation” must be something you can execute (a pre-negotiated contract, a technical failover design, a defined workaround, an alternate route), not a generic intention. ¹

Plain-English interpretation of the requirement

CP-7(2) is the “can we get there and run it?” check for your alternate processing site. You are expected to anticipate realistic conditions that accompany regional disasters (broad telecom outages, blocked travel corridors, building closures, limited staffing availability) and design your contingency approach so the alternate site remains reachable in practice. ¹

Who it applies to

Entities:

• Federal information systems
• Contractor systems handling federal data ¹

Operational context (where it bites):

• You have an alternate processing site (a secondary data center, colocation facility, cloud region, warm site, third-party hosted environment, managed service provider environment, or hybrid design).
• You rely on people, networks, and third parties to bring services up at that site (telecom carriers, cloud providers, colocation operators, fuel suppliers, critical SaaS providers, incident response retainers).
• You face regional disruption risk where primary and alternate sites could share dependencies (same power grid segment, carrier backbone, transportation corridors, or administrative authority). ¹

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

Step 1: Assign a control owner and define the system scope

• Name a single accountable owner (often BC/DR lead, IT resilience lead, or system owner) and document supporting owners for network, identity, facilities, and third-party management.
• Define which systems are in scope for the alternate site and which recovery tier they belong to (mission essential, important, best-effort). Keep the list stable enough for testing and evidence.
  Output: Control ownership RACI + scoped system inventory for CP-7(2) coverage.

Step 2: Build an “accessibility dependency map” for the alternate site

Capture the dependencies required to reach and operate the alternate processing site under stress. Use a table; auditors like tables because they show completeness.

Minimum categories to map:

• Physical access: building access process, badges/keys, security staffing, curfews, law enforcement restrictions.
• Staffing access: who must be on-site, who can work remote, cross-trained backups, union/HR constraints.
• Transportation: routes, public transit reliance, parking, lodging, fuel availability assumptions.
• Network reachability: VPN, direct circuits, carrier diversity, DNS, IdP availability, remote admin paths.
• Critical utilities and services: power, cooling, onsite generator refueling, water, vendor support availability.
• Third-party gates: colocation access approvals, cloud console access, managed service provider runbooks, emergency contacts.

Output: Alternate site accessibility dependency map.

Step 3: Identify area-wide disruption scenarios that stress those dependencies

You do not need exotic scenario modeling. You do need plausible “regional impact” conditions that could block access paths you assumed.

Examples you can document (adapt to your environment):

• Regional telecom outage affecting primary carrier and last-mile to the alternate site.
• Road closures or travel restrictions preventing on-site staff access.
• Widespread power outages affecting fuel delivery or building operations.
• Identity provider or MFA dependency outage blocking admin access to cloud control plane.
• Third-party facility limiting access due to safety/security conditions.

Output: Scenario list linked to impacted dependencies.

Step 4: Document explicit mitigation actions (the heart of CP-7(2))

For each identified accessibility problem, write:

• Trigger/condition: what failure indicates the problem exists.
• Mitigation action: what you will do, by whom, using what resources.
• Time sensitivity: what must happen first (order of operations).
• Fallback: what you do if the first mitigation fails.

Mitigation patterns that satisfy “explicit”:

• Pre-approved alternate access methods (secondary MFA method, break-glass accounts with protected storage, out-of-band admin channel).
• Carrier/path diversity (secondary circuit provider, alternate VPN endpoints, separate DNS hosting).
• Remote-first recovery runbooks (operate the alternate site without travel).
• Pre-negotiated emergency access process with the facility provider (named contacts, escalation chain, required IDs).
• Contracted logistics support (generator refuel priority terms, alternate suppliers).

Output: Mitigation register (problem → action → owner → required resources).

Step 5: Integrate mitigations into DR/COOP procedures and test them

CP-7(2) fails in practice when mitigations are written but not embedded into operational runbooks.

• Update DR runbooks to include the mitigations as steps, not appendices.
• Add at least one test objective per top accessibility risk (example: “recover without on-site access” or “recover with primary carrier unavailable”).
• Capture test evidence and track remediation actions.

Output: Updated runbooks + test plan + test results + remediation tracker.

Step 6: Set a maintenance cadence and evidence rhythm

Auditors will ask when you last reviewed the accessibility assessment and whether changes in carriers, buildings, cloud regions, or staffing were captured.

• Tie updates to change management triggers: new site, new carrier, new building operator process, IdP change, major org restructure.
• Reconfirm third-party emergency contacts and access procedures on a schedule your program can sustain.

Output: Review log + change triggers + contact verification records.

Required evidence and artifacts to retain

Keep evidence tight, dated, and attributable:

1. Control ownership and procedure

   • Named control owner
   • Written CP-7(2) procedure that references the alternate site and the accessibility assessment method

2. Accessibility assessment package

   • Accessibility dependency map
   • Area-wide disruption scenario list
   • Accessibility risks/issues register

3. Mitigation actions and readiness proof

   • Mitigation register with owners and prerequisites
   • Contracts/SOW excerpts or emails that show emergency access or support terms (where applicable)
   • Technical configurations supporting mitigations (screenshots, config exports, architecture diagrams)

4. Testing and operations

   • DR/BC test plans that include accessibility objectives
   • Test results, issues found, and closure evidence
   • After-action reports and updated runbooks

5. Third-party coordination

   • Alternate site provider escalation contacts and access instructions
   • Carrier escalation paths
   • Any facility access requirements and pre-approvals

Common exam/audit questions and hangups

Use these to pre-brief control owners:

• “Show me the accessibility problems you identified for the alternate site and how you selected them.”
• “Where are the mitigation actions documented, and who owns each action?”
• “How do you know these actions work during a regional event?” (Expect to show test results or exercised tabletop outcomes.)
• “What happens if staff cannot travel? Can you recover remotely?”
• “Do your alternate site and primary site share the same carrier, power, or administrative dependencies?”
• “How do you keep this current after network, IAM, or facility changes?” ¹

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating accessibility as “the site exists.”
   Avoid: Document specific blockers (badges, travel, carrier, identity) and pair each with executable mitigations. ¹

2. Mistake: Only addressing physical access, ignoring control-plane access.
   Avoid: Include IAM/MFA, VPN, DNS, and admin pathways in the dependency map; many recoveries fail due to authentication or network reachability constraints.

3. Mistake: Mitigations are vague (“we will coordinate with the provider”).
   Avoid: Name the provider process, required information, contacts, and an escalation path. Store the procedure with the runbook.

4. Mistake: No evidence rhythm.
   Avoid: Create recurring artifacts (review log, contact verification, test evidence) so you are never rebuilding the story right before an assessment.

5. Mistake: Third-party dependencies are assumed, not confirmed.
   Avoid: Confirm emergency access terms and include them in contract/SOW language where possible; otherwise retain written confirmation and contacts.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CP-7(2). Your practical risk is assessment failure and resilience breakdown: if the alternate processing site is unreachable during a regional incident, you can face prolonged outages, missed contractual obligations, and downstream compliance issues tied to availability commitments. The control is designed to force “single point of failure” thinking across geography, carriers, and people. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and document)

• Assign control owner and supporting SMEs (BC/DR, network, IAM, facilities, third-party risk).
• Build the alternate site accessibility dependency map.
• Draft the initial accessibility issues register and scenario list.
• Stand up a simple evidence folder structure and naming standard for artifacts.

Days 31–60 (mitigate and integrate)

• Write explicit mitigations for each accessibility issue, with owners and prerequisites.
• Update DR/COOP runbooks to embed mitigations as steps.
• Confirm third-party access and escalation paths; collect written confirmations and contacts.

Days 61–90 (prove it works)

• Run a tabletop or operational exercise that stresses at least one accessibility constraint (remote-only recovery, carrier outage, facility restricted access).
• Log findings, assign remediation owners, and update runbooks.
• Create the maintenance triggers in change management (site/carrier/IAM changes prompt CP-7(2) review).

Where Daydream fits (without creating extra work)

Most CP-7(2) gaps show up as “we did the work, but can’t prove it fast.” Daydream becomes useful when you map CP-7(2) to a named owner, a repeatable implementation procedure, and recurring evidence artifacts so assessment readiness stays current without a scramble. ¹

Frequently Asked Questions

Does CP-7(2) require a second physical data center?

No. It requires an alternate processing site and a documented assessment of accessibility problems to that site during area-wide disruption, plus explicit mitigations. A cloud region or third-party hosted environment can qualify if accessibility is addressed. ¹

What counts as an “accessibility problem” in practice?

Any realistic condition that prevents people or systems from reaching or operating the alternate site, including travel restrictions, facility access limits, carrier outages, or loss of identity/VPN access. Your dependency map should make these visible. ¹

How detailed do mitigation actions need to be?

Detailed enough that an operator can execute them under stress: triggers, steps, owners, contacts, and fallback actions. Generic statements (“coordinate with provider”) usually fail audits because they are not explicit. ¹

If our DR strategy is “restore from backups in a different cloud region,” does CP-7(2) still apply?

Yes, because “accessibility” includes control-plane access to the alternate region, identity dependencies, network paths, and third-party support processes. Document those paths and mitigations for regional outages. ¹

What evidence is most persuasive to auditors?

A dated accessibility assessment, a mitigation register with owners, and test results that show you exercised at least one accessibility constraint and fixed issues found. Contracts or written third-party confirmations strengthen the file. ¹

How do we handle shared dependencies between primary and alternate sites?

Treat shared dependencies as accessibility risks (same carrier, same IdP, same regional power exposure) and document mitigations such as alternate paths, alternate providers, or remote recovery methods that bypass the shared point of failure. ¹

Footnotes

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