A security team reports suspicious account activity. Operations wants to know whether to disconnect a system. The CEO wants to know whether customers are affected. The board wants to understand the potential business exposure. Everyone is discussing the same event, but each needs a different answer.
This is where risk communication succeeds or fails. A technically accurate explanation can still leave people confused about what matters, what remains uncertain, and what they should do.
The purpose of risk communication is to support a decision—not simply to distribute information. Whether you are presenting a risk assessment, requesting investment, or managing an incident, your message should connect evidence to business consequences and a feasible next step.
A useful risk message answers three questions: What does this mean for me? What should I do? When will I know more?
The Foundation: Accuracy, Relevance, and Trust
NIST’s incident-response guidance provides the cybersecurity foundation: designated stakeholders, coordinated reporting, notification obligations, and recovery communications.
Public-health guidance offers complementary lessons. The CDC’s risk-communication principles address uncertainty, empathy, numerical clarity, and information gaps. WHO’s guidance emphasizes listening, trust, and helping people make informed decisions.
The checklist below is a practical synthesis, not an official agency checklist. It adapts those public-health principles to business and cybersecurity communication. Use it for both routine risk discussions and incident updates, adjusting the urgency and detail to the situation.
Before You Communicate: Establish the Decision and the Facts
-
☐ 1. Identify the audience and the decision.
Before preparing slides or drafting an email, complete this sentence: “After receiving this message, this audience should be able to decide or do ______.”
A board may need to approve resources or evaluate residual risk. An operations leader may need to authorize downtime. Employees may need to stop using an application. Give each audience the detail needed for its decision, while keeping the underlying facts consistent. For a risk assessment, identify who has authority to accept the risk—not just who receives the report.
-
☐ 2. Separate confirmed facts from unknowns.
Prepare three short lists: what is verified, what remains uncertain, and what the team is doing to resolve the uncertainty. Record the information cutoff so readers know how current the assessment is.
“We have not confirmed data theft” does not mean “We have confirmed that no data was stolen.” If evidence is incomplete because logs are unavailable or the investigation covers only part of the environment, say so. Acknowledge the limitation without speculating about the outcome.
-
☐ 3. Assign communication ownership.
Identify who verifies technical facts, approves external statements, delivers each message, and serves as backup. Establish a shared source of approved information so executives, support teams, and account managers do not improvise conflicting explanations.
During an incident, use established escalation and approval procedures. Build a fast path for urgent messages: a slow approval chain can leave employees without necessary instructions. Coordinate with legal, privacy, operations, and communications teams without turning every update into an open-ended editing exercise.
In the Message: Translate Risk into Action
-
☐ 4. Lead with practical impact.
Start with the consequence for the audience, not the technical mechanism. “The customer portal is unavailable while we investigate suspicious activity” is more useful to customers than a description of an authentication exploit.
For an investment decision, explain the business process at risk, the plausible disruption, and the tradeoff among mitigation options. Then provide technical detail where it supports the decision. Acknowledge inconvenience or concern directly; empathy does not require making promises you cannot substantiate.
-
☐ 5. Explain numbers honestly.
Every risk figure needs context: what is being counted, out of what population, over what period, and with what limitations. Distinguish affected systems from systems reviewed, suspicious events from confirmed compromises, and estimated losses from realized losses.
When comparing risks, use consistent denominators and absolute figures rather than relying only on relative statements such as “twice as likely.” Do not assign a probability merely because a slide needs one. If the evidence supports only a qualitative assessment, explain the basis and uncertainty. Define labels such as “high risk” so they are not mistaken for precise measurements.
-
☐ 6. Give a feasible next step.
Specify who should act, what they should do, when they should do it, and where they can get help. “Remain vigilant” is not an operational instruction.
In a hypothetical account-security incident, useful guidance might direct affected employees to reset credentials through an established company channel and contact the service desk if access fails. First verify that the reset process works and support is available. WHO’s guidance cautions against recommending actions people cannot perform because services are inaccessible. The same principle applies to security controls and incident instructions.
-
☐ 7. Say what happens next.
Describe response or mitigation actions that are actually underway. Avoid presenting planned work as completed work. Give a specific next update time, including the time zone and communication channel—even if the next update may simply confirm that the investigation continues.
For routine assessments, identify the decision date, action owner, and review point. During recovery, report restoration progress and verified measures to reduce recurrence. Restored service does not, by itself, establish that every security question has been resolved.
Before and After Release: Check Delivery, Obligations, and Understanding
-
☐ 8. Check access and trusted channels.
Can recipients receive, understand, and act on the message? Consider language, accessibility, shift patterns, technology access, and trust in the messenger. WHO recommends understandable information delivered through channels people use and trust.
Do not make a potentially affected system your only communication channel. If employees cannot access corporate email, an email-only instruction will fail. For urgent actions, tell recipients how to verify that the message is authentic without following an unfamiliar link.
-
☐ 9. Coordinate required notifications.
Have the appropriate specialists verify applicable legal, regulatory, and contractual duties, including recipients, content, delivery methods, and deadlines. These requirements depend on the circumstances and jurisdiction; a generic incident timetable is not a substitute for that analysis.
A public status update does not automatically satisfy a customer notice, regulatory report, or contractual obligation. Coordinate these communications while limiting unnecessary disclosure of personal information, sensitive evidence, or technical details that could help an attacker.
-
☐ 10. Listen, correct, and continue updating.
Collect questions from support teams, managers, customers, and other stakeholders. Repeated questions often reveal a communication gap rather than an inattentive audience.
When evidence changes, explain what changed and why. If an earlier statement was wrong, correct it explicitly rather than quietly replacing it. Keep a record of updates and decisions. Afterward, review whether people understood the message and completed the requested actions—not merely whether the message was delivered.
A Hypothetical Example: From Technical Update to Decision
Consider this hypothetical internal update: “We detected anomalous authentication activity and are investigating potential credential compromise.” It names a technical concern but leaves the business decision unclear.
A decision-focused version would explain that suspicious sign-ins were confirmed for the affected accounts, that unauthorized data access remains unconfirmed, and that account containment is underway. It would identify which employees must act, provide a verified support route, and state when the next update will arrive.
If leadership must choose whether to suspend a connected application, the message should also explain the tradeoff: the exposure suspension could reduce, the business disruption it would cause, and the limitations of continuing with additional monitoring. The communicator’s job is to make that decision understandable—not to hide the tradeoff behind a risk rating.
A Reusable Risk Communication Template
Complete this drafting aid with verified information. If something is unknown, label it unknown rather than filling the gap with reassurance.
As of [date, time, time zone]: We have confirmed [facts].
What this means for you: [Specific impact and relevant decision.]
What remains uncertain: [Unknowns, evidence limitations, and how they are being investigated.]
What we are doing: [Verified response or mitigation actions.]
What you should do: [Action, timing, and accessible support channel.]
Next update: [Date, time, time zone, and channel.]
Make Communication Part of Risk Management
Risk communication is not a final layer added after the technical work. It connects that work to decisions, resources, and behavior.
Start with your next assessment or incident exercise. Assign communication ownership, use this checklist, and ask someone outside the security team to explain the message back to you. If they cannot identify the impact, the uncertainty, and their next step, revise it.
The standard is not whether your message sounds authoritative. It is whether people can use it to make a better decision.