Skip to main content
← All controls
CP-2 / CP-8 / IR-6 NIST SP 800-53 Rev 5

Do you have a status page or public communication channel that operates independently of your primary infrastructure?

Demonstrate that the organization maintains an independently-hosted status communication channel that remains operational during primary infrastructure failures or security incidents.

Description

What this control does

This control requires organizations to maintain a status page or public communication channel (e.g., status.company.com, third-party status service, social media account) that is hosted separately from the primary production infrastructure and application stack. The communication channel must remain operational during outages, security incidents, or infrastructure failures affecting main systems. This ensures stakeholders, customers, and partners receive timely updates about service availability, planned maintenance, and security events even when primary systems are compromised or unavailable.

Control objective

What auditing this proves

Demonstrate that the organization maintains an independently-hosted status communication channel that remains operational during primary infrastructure failures or security incidents.

Associated risks

Risks this control addresses

  • Customers and partners cannot receive incident notifications during a distributed denial-of-service (DDoS) attack that takes down primary web infrastructure
  • Security incident response teams cannot publish public advisories or guidance when attacker activity disrupts primary communication platforms
  • Stakeholders flood support channels with duplicate inquiries during outages due to lack of centralized status information, overwhelming incident response resources
  • Regulatory notification obligations are not met in a timely manner because communication infrastructure fails simultaneously with production systems
  • Reputational damage escalates when the organization appears unresponsive during incidents because all communication channels share the same failure domain
  • Social engineering attacks succeed when attackers exploit information vacuums created by the absence of authoritative status updates during disruptions
  • Mean time to recovery (MTTR) increases as internal teams lack a reliable channel to coordinate with external vendors and service providers during infrastructure failures

Testing procedure

How an auditor verifies this control

  1. Request documentation identifying the organization's designated status page URL or public communication channel, including hosting provider and infrastructure dependencies
  2. Review architecture diagrams and network topology documentation to verify the status page infrastructure is isolated from primary production systems, including separate hosting providers, DNS zones, or content delivery networks
  3. Obtain configuration exports or service agreements confirming the status channel uses different authentication systems, databases, and network paths than production infrastructure
  4. Interview incident response and communications personnel to understand procedures for updating the status page during various incident scenarios
  5. Review historical incident reports from the past 12 months and verify that status page updates were posted during documented outages or security events
  6. Perform a simulated failure test by requesting IT operations to demonstrate updating the status page while simulating primary infrastructure unavailability (or review records of such testing)
  7. Verify the status page is accessible from external networks without requiring VPN access or authentication that depends on primary infrastructure
  8. Examine change management records to confirm regular maintenance, monitoring, and testing of the independent status communication channel
Evidence required Architecture diagrams showing infrastructure separation, status page hosting agreements or service contracts with third-party providers, configuration exports demonstrating DNS and hosting independence, incident response runbooks referencing status page update procedures, historical status page logs or screenshots showing updates during actual incidents, test records documenting simulated failure scenarios where status updates were successfully posted, and monitoring dashboards showing status page availability metrics independent of primary infrastructure.
Pass criteria The organization operates a status page or public communication channel that is verifiably hosted on infrastructure independent of primary production systems, with documented evidence of successful use during at least two actual or simulated infrastructure failures within the past 12 months.