CP-11: Alternate Communications Protocols

CP-11 requires you to pre-establish and prove you can switch to alternate communications protocols to keep critical operations running when primary communications fail. Operationalize it by identifying mission-essential communication paths, defining approved alternates (technical and procedural), testing failover, and retaining evidence that the alternates work under realistic outage conditions. ¹

Key takeaways:

• CP-11 is about capability, not a policy statement; you must be able to communicate through alternates during disruption. ¹
• Your scope is every system and team that supports continuity of operations, including third parties that provide network, voice, incident, or crisis communications.
• Testing and evidence are the difference between “documented” and “implemented”; plan for repeatable exercises and artifacts.

A lot of continuity plans assume the network will be “mostly up.” CP-11 forces you to plan for the opposite: the communications method you normally depend on may be degraded, unavailable, or untrusted during an incident. That includes production network paths, corporate email, identity systems that back your collaboration tools, and even the conferencing platform you use to coordinate response.

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize the cp-11: alternate communications protocols requirement is to treat it as a targeted engineering-and-operations control: define what “communications” must exist for continuity, define which alternate protocols are allowed, make sure you can switch under pressure, and collect evidence that you can do it.

CP-11 also becomes a supply-chain dependency review in practice. If your “alternate” relies on the same provider, the same identity plane, or the same physical facility, it may not be alternate in any meaningful sense. The goal is defensible resilience: clear ownership, documented procedures, and repeatable demonstrations tied to your continuity objectives. ²

Regulatory text

Requirement (verbatim): “Provide the capability to employ {{ insert: param, cp-11_odp }} in support of maintaining continuity of operations.” ¹

What the operator must do

• Provide the capability: You must implement real mechanisms (technical and/or procedural) that enable communications when primary channels are unavailable. A written plan alone will not satisfy the “capability” standard. ¹
• Employ alternate communications protocols: Define and approve alternates that are suitable for your environment (for example, out-of-band incident bridges, alternate network paths, alternate collaboration channels, alternate addressing and routing methods). The control text intentionally leaves the parameter open because the right protocols depend on your mission and threat model. ¹
• Support continuity of operations: Tie alternates to continuity scenarios that matter: cyber incident, DDoS, cloud control-plane outage, ISP failure, regional disaster, identity provider outage, or facility loss. Your alternates must support the communications needed to sustain mission-essential functions. ²

Plain-English interpretation

CP-11 means: If your normal way of communicating fails, you can still coordinate, escalate, and operate using pre-approved alternate methods. That includes (1) technical connectivity (routing, networks, voice/data paths) and (2) human coordination channels (incident command communications, escalation trees, executive updates).

A workable CP-11 implementation answers four questions:

1. What communications are mission-essential? (incident coordination, on-call paging, customer notifications, recovery coordination with third parties)
2. What is the primary path? (corporate email, Teams/Slack, VPN, VoIP, SD-WAN, production network)
3. What is the alternate path and protocol? (out-of-band messaging, alternate carrier, alternate conferencing bridge, alternate network tunnel, radio/satellite where applicable)
4. How do you switch, and how do you prove it works? (runbooks, roles, exercises, logs, test results)

Who it applies to

CP-11 is commonly applied to:

• Federal information systems and the organizations operating them. ¹
• Contractor systems handling federal data, including cloud service providers, SaaS platforms, MSPs, and product teams operating regulated environments for government customers. ¹

Operationally, it applies wherever continuity depends on communications:

• SOC/incident response and crisis management
• IT operations and network engineering
• Business continuity / disaster recovery (BC/DR)
• Executive communications and legal/compliance notification flows
• Third parties providing telecom, conferencing, paging, managed network, or cloud connectivity

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

1) Set ownership and scope (make it auditable)

• Assign a control owner (often BC/DR lead or Head of Infrastructure) and a GRC accountability owner (you or your delegate).
• Define in-scope systems and functions: incident coordination, DR execution, customer communications, and internal escalation.
• Document how CP-11 maps into your continuity plan and incident response plan so it is testable, not “floating.”
  Practical tip: In Daydream, track CP-11 as a requirement with a named owner, implementation procedure, and recurring evidence list so the control doesn’t degrade after the first audit.

2) Inventory primary communications dependencies

Build a simple dependency map for continuity communications:

• Internal collaboration (email, chat, conferencing)
• Identity/auth (SSO/IdP, MFA, device management) that gates access to collaboration
• Network paths (ISP, SD-WAN, VPN, DNS, public cloud connectivity)
• On-call paging/alerting
• Executive and customer notification channels

Output artifact: “Continuity Communications Dependency Map” with owners and failure modes.

3) Define “alternate” in a way that survives scrutiny

Alternates should not share the same single point of failure as the primary. Watch for hidden coupling:

• Same identity provider for primary and alternate collaboration tools
• Same carrier or last-mile path for primary and alternate internet
• Same cloud region for primary and alternate incident tooling
• Same MDM policy that can lock you out during a widespread device incident

Create an “Alternate Communications Protocols Standard” that specifies:

• Approved alternates by use case (incident command, on-call escalation, executive briefings, DR coordination)
• Minimum accessibility requirements (who must be able to access, from what devices/locations)
• Security constraints (encryption expectations, retention rules, approved data types)
• When to switch (trigger criteria) and who can authorize the switch

4) Build procedures that work under stress

Create runbooks that answer:

• How to declare “primary comms degraded”
• How to move the war room to the alternate channel
• How to distribute access details if corporate email is down
• How to handle external communications (customers, regulators, critical third parties)

Keep procedures short. One page is better than a binder during an outage.

5) Implement technical enablement

Examples (choose what fits your environment):

• Pre-provisioned out-of-band incident bridge with separate admin credentials
• Secondary paging path (or secondary admin access method) for on-call teams
• Alternate network connectivity for key recovery staff (for example, separate ISP at critical sites, pre-staged cellular hotspot capability, or a dedicated out-of-band management network where relevant)
• Alternate DNS resolution or routing path for continuity-critical services (where applicable)

6) Test the alternates and capture evidence

Testing should demonstrate you can:

• Assemble the right responders using the alternate channel
• Access critical systems needed to restore service (or coordinate with teams who can)
• Maintain communications for the duration of an exercise

Run at least one exercise that assumes the primary channels are unavailable. Capture artifacts listed below.

7) Operationalize as a recurring control

CP-11 fails over time as tools change. Put it on a maintenance loop:

• Review alternates when you change IdP, conferencing, paging, WAN, or DR architecture
• Refresh access lists and break-glass credentials
• Re-test after major organizational changes or third-party changes

Required evidence and artifacts to retain

Auditors will ask for proof of capability. Keep these in a single CP-11 evidence folder:

• Control narrative / procedure describing alternate communications protocols and when they are used
• Communications dependency map (primary vs alternate, owners, dependencies)
• Approved alternate protocols standard (what’s allowed, constraints, escalation)
• Runbooks (switch criteria, access distribution, roles)
• Exercise plan and after-action report showing alternate comms were used
• Test outputs: screenshots, bridge logs, paging logs, incident ticket timestamps, chat exports (redacted as needed), recovery coordination notes
• Access governance: list of authorized users for alternates, break-glass process evidence, periodic access review results
• Third-party support evidence: contracts/SOW excerpts or support commitments that affect alternate comms, plus contact trees

Common exam/audit questions and hangups

Expect questions like:

• “Show me the alternate communications protocols you can use if email and chat are down.”
• “How do you coordinate incident response if your SSO provider is unavailable?”
• “Demonstrate evidence from the last exercise where alternates were used.”
• “How do you ensure alternates are secure and access-controlled?”
• “Which third parties are required for your alternate path, and what happens if they are unavailable?”

Hangups that stall audits:

• The “alternate” is just another app behind the same SSO and same network.
• No clear trigger for switching, so the plan reads theoretical.
• Tests exist, but they never actually used the alternate channel.

Frequent implementation mistakes and how to avoid them

1. Mistake: Alternate channel depends on the same identity plane.
   Fix: Design at least one access path that works during IdP outage (break-glass accounts, alternate auth, or emergency access procedures consistent with your policy).

2. Mistake: Assuming personal phones = alternate comms.
   Fix: Decide formally what is allowed, what data can be shared, and how you retain incident records. Document it.

3. Mistake: No distribution mechanism when corporate email is down.
   Fix: Maintain an offline-accessible contact tree and a procedure to share bridge details via alternate channels.

4. Mistake: Testing only in ideal conditions.
   Fix: Run an exercise that explicitly disables or forbids primary channels. Document what failed and what changed.

5. Mistake: Evidence scattered across teams.
   Fix: Centralize artifacts in your GRC system (Daydream or equivalent), mapped to CP-11 with a recurring evidence checklist.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CP-11, so this page does not cite enforcement outcomes.

From a risk standpoint, CP-11 gaps typically show up as:

• Slower incident containment because teams cannot coordinate
• Loss of decision-making and escalation during outages
• Inability to execute DR because staff cannot access instructions or channels
• Audit findings framed as “control not implemented” due to lack of testable evidence ¹

Practical 30/60/90-day execution plan

Days 0–30: Establish design and ownership

• Assign owners, define in-scope functions, and document the dependency map.
• Decide approved alternates by scenario (cyber incident, cloud outage, ISP outage, IdP outage).
• Write the “switch to alternates” runbook and get operations sign-off.

Days 31–60: Implement and validate

• Provision the alternate channels (accounts, bridges, access groups, contact trees).
• Configure break-glass access consistent with your access control practices.
• Train incident commanders and on-call leads on the switch procedure.

Days 61–90: Exercise, fix gaps, and lock evidence

• Run a continuity communications exercise where primary comms are assumed unavailable.
• Produce an after-action report with remediation items and owners.
• Store evidence and set a recurring review cadence in Daydream so CP-11 stays current as tooling changes.

Frequently Asked Questions

What counts as an “alternate communications protocol” for CP-11?

Any pre-approved method you can switch to when primary communications fail, as long as it supports continuity communications and is realistically accessible during disruption. The key is documented approval, operational readiness, and test evidence. ¹

Does CP-11 require a specific technology (satellite phones, radios, etc.)?

No specific technology is mandated in the provided control text. You choose alternates that fit your environment and continuity needs, then prove you can use them. ¹

How do I handle security and retention if we use an out-of-band messaging app?

Define what data can be shared, who can access it, and how incident records are retained for audit and post-incident learning. Put those rules in the approved alternate protocols standard and train teams on it.

Our “alternate” tool uses the same SSO as our primary tool. Is that acceptable?

It may fail a resilience review if the IdP outage is a plausible scenario for you. Document the dependency and add an alternate access method or a separate channel that does not require the same identity dependency.

What evidence do auditors expect for CP-11?

They expect proof of capability: documented alternates, runbooks, and exercise artifacts that show you actually used the alternates under a simulated failure. Keep logs, screenshots, tickets, and after-action reports tied to CP-11.

How should we manage third parties involved in alternate communications?

Identify which third parties are required for alternates (telecom, conferencing, paging, managed network), document their role in continuity, and ensure contact paths and support expectations are captured in your continuity communications artifacts.

Footnotes

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

2. NIST SP 800-53 Rev. 5