The document, Communicating Under Pressure: Best Practices for Service Providers, addresses outages caused by cyberattacks, operator error, equipment failure, and natural hazards. CISA’s central premise is that an interruption at one provider can propagate through dependent systems, creating a public-information problem as well as a technology problem. That is particularly relevant to organizations that operate Microsoft 365 tenants, identity platforms, remote-access infrastructure, cloud-hosted line-of-business applications, or industrial environments where a loss of connectivity can interrupt the systems used to supervise physical processes.
CISA is not prescribing a polished public-relations exercise. Its guidance treats clear, accountable, and transparent communication as a resilience control: a way to tell affected users what is unavailable, what they should do now, and when to expect the next verified update without compromising law-enforcement work, technical containment, or legal obligations.
An outage plan needs a communications path that still works
The most important operational point is also the easiest one to overlook: organizations should assume their ordinary communications channels may be unavailable during the incident. A company whose public website, support portal, corporate email, Teams tenant, single sign-on service, or customer-notification platform relies on the same failed identity provider, network, DNS host, cloud region, or security control may find itself unable to publish the very message customers need.
CISA’s warning about disrupted or unreliable telecommunications services broadens that risk. A phone tree is not much of a contingency if the cellular network is congested, the contact list lives behind inaccessible SaaS authentication, and key decision-makers cannot reach the people authorized to speak publicly. IT teams commonly test recovery of virtual machines, Active Directory, backups, and network failover; far fewer regularly test whether a service owner can reach customers and staff without the normal corporate stack.
For Microsoft-focused organizations, this calls for separating crisis communications from the production environment as far as practical. That does not mean abandoning Microsoft 365 or Teams during every incident. It means documenting which channels depend on which services, who can use them, and what the fallback is if Entra ID, Exchange Online access, a local internet circuit, or endpoint management is impaired.
A credible plan should identify at least two independently reachable methods for communicating with four audiences: employees, customers, regulators or emergency partners, and the media or wider public. Independence matters more than the number of channels. A secondary status page hosted with the same cloud provider, published through the same DNS account, and administered by the same inaccessible single-sign-on tenant is not a meaningful fallback.
CISA’s existing emergency-communications work provides a useful reminder that priority telecommunications capabilities exist for eligible national-security and emergency-preparedness users, but those services are not an instant remedy. Telecommunications Service Priority designations must be arranged before an outage, and they apply to specifically identified critical circuits rather than every connection an organization happens to use. Wireless Priority Service can improve the chance of calls completing during congestion for authorized subscribers, but it does not create coverage where a network is down and does not displace calls already in progress.
The first message should say less, but say it reliably
During a cyber incident, pressure often produces one of two failures: silence while an organization waits for perfect technical certainty, or overconfident explanations that later have to be retracted. CISA’s guidance favors timely, accurate, audience-appropriate updates. Those terms are more demanding than they sound.
Timely does not require declaring the cause before the investigation establishes it. A first notice can state the known impact, the time the organization detected it, the steps users should take, and a specific time for the next update. “We are investigating” is insufficient when the organization already knows users cannot sign in, a customer portal is unavailable, or remote access has been temporarily disabled as a defensive measure.
Accuracy means separating observed symptoms from attribution. An administrator can say that remote desktop access has been suspended or that a billing portal is offline. They should not say ransomware caused the disruption merely because an alert appeared on a server, nor describe a compromise as contained while authentication logs, endpoint telemetry, and lateral-movement analysis are still incomplete. The FBI’s involvement in the guidance reflects a recurring incident-response tension: public statements can interfere with containment or an active investigation if they disclose defensive gaps, affected assets, or intelligence useful to the attacker.
Audience-appropriate communication also means that different groups need different levels of detail. Employees need instructions for continuing work safely, including whether they may use personal email, personal devices, or unapproved collaboration tools. Customers need a plain account of unavailable services, any deadline or transaction implications, and legitimate support routes. Technical partners may need indicators, interface status, maintenance windows, and a coordination contact. Regulators and law enforcement may have reporting thresholds, deadlines, and confidentiality constraints that do not belong in a public statement.
The message should never ask users to improvise around security controls. If an organization disables conditional access, VPN, or federated authentication as part of containment, its notice must state the approved alternative workflow. Otherwise, users will predictably seek their own route around the outage—personal file-sharing accounts, unmanaged messaging apps, shadow remote-access tools, or recycled passwords—creating a second incident during the first.
Crisis ownership cannot stop at the NOC
The guide’s emphasis on accountability points to a governance gap common in service outages. Engineering may own repair, security may own containment, and communications may own a public statement, yet no one has authority to resolve a conflict between those functions in the first hour. The result is often status pages updated with vague language while frontline support staff give customers a different answer.
Service providers should assign incident communication roles before a crisis, including a technical fact owner, an incident commander, an executive decision-maker, customer-support lead, legal or privacy reviewer, and an external communications owner. The same person should not necessarily perform all of these jobs, but each role needs an identified deputy and a channel that remains usable if the corporate environment is partly inaccessible.
For managed service providers, the customer-contract dimension is especially important. An MSP may detect an interruption in its remote monitoring and management platform, a backup console, a tenant-management tool, or a security operations platform before it can determine which clients are affected. Its customers, meanwhile, may be seeing failed sign-ins or inaccessible endpoints. The provider’s initial notice should distinguish a provider-platform issue from confirmed customer impact, explain whether customers need to take action, and commit to an update schedule.
The advice also reaches organizations that consume services rather than provide them. CISA says critical-infrastructure owners and operators should understand the type of communications they can expect from their providers. Procurement teams should therefore treat outage communications as a contract and operational-resilience question, not a marketing preference. Service-level agreements that specify availability but say nothing about notice cadence, status channels, escalation contacts, or post-incident reporting leave customers with little leverage when an outage becomes chaotic.
A useful tabletop test for Windows and OT teams
CISA’s CI Fortify initiative is designed to help critical-infrastructure organizations isolate and recover vital OT systems during major cyber incidents. Isolation may deliberately make a service unavailable; the communications plan must make clear that this can be a protective action rather than evidence that recovery has failed.
A practical tabletop exercise should test an event such as this: suspicious activity forces an organization to isolate Windows jump servers used to reach an OT network, disable remote vendor access, and restrict some Entra ID-connected workflows. The technical team can still operate locally, but plant personnel, remote engineers, vendors, and customers start reporting lost access. The communications problem is then as real as the technical one.
Teams should be able to answer the following before an actual event:
- The organization can publish an externally accessible service notice even if its primary website, corporate email, and single-sign-on environment are unavailable.
- The incident commander knows who may approve a public statement and who may provide operational details to affected customers and partners.
- Customer-facing staff have a preapproved statement that describes verified impact and safe alternatives without speculating about cause or restoration time.
- The organization has a method to reach critical contacts when ordinary cellular, email, and collaboration channels are degraded.
- The recovery plan includes a decision point for announcing deliberate isolation, partial restoration, and the withdrawal of temporary workarounds.
The final item is often neglected. Temporary arrangements introduced during an outage—manual approvals, emergency accounts, bypassed integrations, alternate remote-access paths—can become security liabilities if no one communicates when they are no longer authorized. Recovery messaging should therefore include what has returned, what remains constrained, and which emergency processes must stop.
CISA’s guidance does not eliminate the hard judgment calls that accompany cyber and OT incidents. It does make the benchmark clearer: organizations should prepare communications with the same discipline applied to backup restoration, privileged access, and network segmentation. When the normal channels fail, the organization that can still issue a verified, usable instruction has preserved more than its reputation; it has reduced the chances that users, customers, and partners will make the outage worse.