An outage is a signal, not an attribution

A service goes offline. Customers report failures. Someone posts that it must be a cyberattack.

At that point, an analyst has evidence of disruption. Whether the cause is malicious—and who is responsible—requires a separate assessment.

My proposed rule for the first briefing is to separate impact, cause and attribution. Each question has its own evidence requirements. Urgency should accelerate the work, not merge the answers.

What prompted this assessment

OV INT collected CISA’s description of “Communicating Under Pressure,” guidance developed with the FBI and international partners. It identifies cyber activity, human error, equipment failure and natural hazards as possible outage causes; warns about cascading disruption; and recommends planning for unreliable telecommunications and backup communication methods.

I take a threat-intelligence lesson from that guidance: a team needs to manage uncertainty about the incident and uncertainty about its own ability to observe and communicate. The workflow below is my analytical proposal, not a reconstruction of a specific attack.

Start with the impact you can establish

Record which service is affected, who observed the failure, when it was observed and what remains functional. Distinguish a direct technical observation from a customer report or an inference about the extent of disruption.

In a hypothetical incident affecting several organizations, I would ask whether the reports concern a shared provider, a shared dependency or separate systems. Simultaneous reports are a reason to investigate a relationship. They are not, on their own, proof of coordinated targeting.

An impact statement should be useful even if the explanation changes. “This function is unavailable to these users” is a narrower, more defensible starting point than an unverified account of who took it down.

Keep competing causes alive long enough to test them

I would maintain a short hypothesis record: malicious activity, an operational change, a component failure, and an upstream dependency problem. The list should reflect the actual environment rather than become a fixed template.

For each explanation, identify an observation that would strengthen it and one that would weaken it. A recent change record, a provider advisory or relevant telemetry might discriminate among hypotheses. None should be treated as decisive without considering its reliability and other plausible explanations.

The point is to direct the next collection step. A list of possibilities with no distinguishing evidence does little to reduce uncertainty.

Assess the observation channel too

If routine communications fail, an absence of reports becomes harder to interpret. It could reflect a quiet environment, a reporting delay or a broken reporting path.

I would therefore include a collection-health field in the briefing: which reporting routes are working, which are degraded, and what part of the picture may be missing. An alternative contact route is useful only if the relevant people know it exists and can actually use it.

This is a planning principle, not an instruction to expose operational details publicly. External updates and technical response channels have different audiences and information needs.

Communicate in layers

My proposed external update has four parts: the confirmed service impact, the limits of current knowledge, the available customer guidance, and the next update time. An internal assessment can carry the hypotheses and evidence behind it through the appropriate restricted channels.

A hypothetical public sentence might read: “We are investigating a service interruption. Its cause is not yet confirmed. Our next update will be issued at the stated time.” The specific wording should fit the incident, responsible authority and applicable obligations.

Make the decision threshold explicit

Some protective or continuity decisions may be warranted before attribution is resolved. That does not justify every intervention: the operational owner still needs to weigh the consequences of acting, delaying and being wrong.

The analyst’s contribution is to make those uncertainties visible. What is established? What is inferred? Which decision cannot wait? What new observation would change the assessment?

An outage deserves attention because of its impact. Calling it an attack requires evidence about its cause. Naming an actor requires a further evidential step.

Source and scope

CISA, “Communicating Under Pressure: Best Practices for Service Providers”.

This assessment uses the public guidance description stored in OV INT. The hypothesis record, collection-health field and hypothetical examples are my proposed applications. They are not claims about a current incident, a tested intervention or access to private incident telemetry.