TL;DR

Prime Big Deal Days · Oct 6–7Offer from Amazon

Get privacy and security gear delivered free — and shop member deals

• Fast, free delivery on millions of items
• Access to Prime Big Deal Days deals on October 6–7
• Prime Video, Amazon Music and more included

Start your free Prime trial →Free trial for eligible customers · Cancel anytime

As an affiliate, we earn on qualifying purchases.Hide

During a security event, share confirmed impact, say what remains under investigation, give affected people practical steps, and name a time and place for the next update. Coordinate public messages with response, legal, privacy, and support teams, but keep approvals from delaying urgent guidance. Correct mistakes clearly and keep updating even when the investigation has not produced a major change.

A login page goes blank, support requests pile up, and screenshots of the error start circulating before your team has a clear explanation. A security event can quickly become a communications crisis when people have to guess what happened or whether they need to act.

You do not need every answer before you send a useful first message. You do need to separate confirmed facts from open questions, explain any immediate steps people can take, and tell them where to find the next update. That approach helps customers, staff, and partners make decisions without turning uncertainty into rumor.

This guide shows you how to prepare your team, write an honest first notice, choose channels people can reach, protect sensitive details, and keep communicating as the facts change. For example, if your usual account system is offline, an update posted only behind that login will not help people who cannot get in.

Start with what people need to know right now

During a security event, your first message should state the confirmed issue, its known impact, any immediate action people should take, and when you will update them again. You can do that before you know the cause or the full scope. A short, accurate notice beats a polished paragraph that leaves people without a next step.

Those details answer the decisions readers are trying to make: Is the service I use affected? Do I need to do something now? When can I expect better information? If one answer is unknown, label it as unknown rather than leaving a gap readers may fill with speculation. For example: “We are investigating an issue affecting sign-in to our customer portal. We have not confirmed whether customer information was affected. If you received an unexpected password reset message, do not use its link; visit our support page directly. We will post another update by 3 p.m. UTC.” Each sentence supports a decision or sets an expectation.

Do not turn an event into a claim of data theft unless the evidence supports it. An outage, suspicious activity, and confirmed access to personal information are different findings, and they call for different responses. Saying too much too soon can needlessly alarm people and damage trust; saying too little can leave them exposed to a risk they could have reduced. If your investigation has not established whether data was affected, say so and explain what the team is checking at a broad level.

“We are investigating” becomes more useful when you add what the team is doing. Say whether you are reviewing system activity, restoring a service, or checking which users may be affected—at a broad level that does not expose sensitive details. Explain the practical implication of the disruption too. If a payment portal is unavailable, for instance, tell customers whether to retry later, use another supported route, or avoid sending duplicate payments. Without that guidance, people may create a second problem while trying to solve the first.

Think of the first notice as a street sign in heavy rain. It cannot explain the whole storm, but it can point people away from danger and toward the next update. Date and time-stamp each notice so readers can judge whether it is current, especially when details may change. If you later correct an error, make the correction visible and explain what changed; silently replacing old wording can leave people acting on screenshots or copies that still circulate.

Coordinate your team without slowing urgent updates

During a security event, a shared set of verified facts and clear approval roles helps every team give people the same accurate answer. Security responders may understand the technical investigation, while support staff hear what customers are experiencing. Legal and privacy teams can flag notification duties and sensitive information; communications staff can turn those details into clear public language. Each perspective matters because a message can be technically accurate yet confusing, or easy to understand yet misleading about the evidence.

Before an incident, agree who can approve a holding statement, who speaks for the organization, and who updates the status page. Keep the list short enough to work under pressure. A small review group can catch errors and prevent contradictory claims, but a long chain of approvals can delay guidance while people face an active risk. Define which urgent messages a named incident lead can approve quickly and which claims need broader review, such as statements about personal data or legal obligations.

For example, imagine a cloud provider reports an issue that may affect your service, but your team has not confirmed customer impact. The response lead can check internal signals, support can collect reports, and communications can prepare a brief notice marked for review. One named approver checks that the message matches current facts; the team then publishes it and sets a time to reassess. This keeps the statement appropriately limited while the organization investigates whether the provider’s report has practical consequences for its own users.

Give customer support the same current facts as public-facing teams, plus a way to escalate new reports. A support agent should not have to rely on a week-old help article when a customer asks whether a sign-in alert is genuine. Provide a short internal briefing with approved language, known limitations, the next update time, and a route for urgent or unusual cases. Support conversations can reveal patterns the incident team has not yet seen, so an escalation route helps the organization learn as well as respond consistently.

Coordination works when it creates one dependable picture, not one more gate. Use a shared incident log or briefing that records what is confirmed, what remains open, who owns each action, and when the facts were last checked. That record helps teams distinguish a new finding from an old assumption and reduces the chance that an outdated answer will be repeated. If a new report changes the picture, every team should see that change before it reaches a customer conversation.

Give people clear steps while the facts are still developing

During a security event, tell people what they can safely do now, even when the investigation has not answered every question. Useful steps depend on the event; they might include changing a password through the official website, watching for unexpected messages, contacting support, or checking a service-status page. The value of an instruction is whether it reduces a plausible risk. Avoid blanket instructions that add work without reducing a real risk, since unnecessary resets or support calls can distract people and slow response to those most affected.

1. Name who may be affected. If you know the issue affects users of one service or region, say that. If you do not yet know, say the scope is under investigation. This helps people assess relevance without implying that everyone is equally exposed.
2. Give one direct action at a time. Point people to a trusted route, such as typing your known web address into a browser, rather than clicking a link in a message they may not trust. A simple route is easier to follow under stress and less likely to send people into a phishing trap.
3. Explain what to watch for. Describe relevant signs in everyday language, such as an unexpected sign-in alert or a request for a one-time code. Concrete examples help people recognize suspicious activity without requiring them to interpret technical terms.
4. Tell people where to get help. Name the support route and the next public update time. That gives readers a way to resolve individual problems and a place to check for shared developments.
5. Review the advice as evidence changes. Remove or revise steps that no longer apply, and explain meaningful changes. Leaving obsolete instructions in place can create avoidable work or undermine confidence in later guidance.

Say a subscription service discovers suspicious activity on an account system, but has not established whether attackers viewed customer records. A measured notice can advise people to ignore unexpected password reset links and sign in through the service’s normal address while the team investigates. That precaution is tied to a plausible way attackers might exploit uncertainty. If later evidence supports a password reset, the organization can send targeted instructions to the users who need them, reducing unnecessary effort for others while reaching the affected group directly.

Useful guidance is specific without pretending the risk is settled. “Your account is safe” can mislead if the investigation is still open, because readers may treat it as a final finding. “We have not confirmed that account information was accessed; we are reviewing the activity and will update you by noon” gives a more honest picture and a clear point for reassessment. People may feel unsettled by uncertainty, but they can make better choices when the organization draws a clear boundary between evidence and what remains unknown.

Choose channels people can still reach

During a security event, publish through channels your affected audience can access, including at least one route that does not depend on the system under investigation. A message inside an app is of little use if the app will not load. An email may help some customers, while a public status page gives others a link they can share without signing in. The channel is part of the guidance: if people cannot reach it, even accurate instructions cannot help them act.

Choose the channel to match the audience and the kind of action required. A service-status page can carry ongoing operational updates; direct email may be appropriate for people who need an individual notice; a support page can answer common questions. Each channel has tradeoffs: a public page is easy to share but may not reach a specific person directly, while direct messages can be targeted but may be delayed or mistaken for phishing. Keep each route consistent, and point people toward the current update rather than letting old screenshots circulate without context.

Consider a workplace identity provider outage. Employees may not be able to sign in to email or internal chat, so a company intranet announcement will miss the people who need it most. A preselected external status page, a phone tree for essential staff, or another approved independent route can carry the basic update while normal access is restored. Planning that route ahead of time matters: during an incident, teams may not be able to safely create or verify a new channel quickly.

Make updates easy to read, find, and share. Put the time and date near the top, use descriptive headings, and avoid relying on color alone to signal severity. If people use screen readers or mobile phones, a simple text update is often more useful than an image of a statement. Clear formatting also helps support staff and customers distinguish the current update from copied or outdated versions. Give support staff the same public link so they can direct customers to one current account.

Social media and messaging platforms can spread reports before your team has verified them. Monitor relevant public channels, but treat claims as leads to check—not proof. If a rumor is materially wrong, correct it with a concise statement that gives the verified fact and points to the official update. Repeating every false claim can give it a larger audience, so address the practical misunderstanding without amplifying unnecessary detail. This balances the need to correct confusion with the risk of drawing attention to claims that would otherwise have limited reach.

Protect people without exposing sensitive details

During a security event, share enough detail for people to understand their risk and act, while withholding personal information and sensitive technical details. A public update should explain customer impact and protective steps. It usually does not need to publish system configurations, security gaps, or information that could help someone interfere with the response. Too little detail can prevent people from judging their risk; too much can expose individuals or make the incident harder to contain. Review details against both needs before publishing.

Picture a notice that lists a customer’s email address, account number, and support ticket to prove the organization is investigating. That detail may identify the person to strangers and create a fresh problem. Use grouped descriptions instead, such as “a limited number of accounts in the affected service,” when evidence supports that wording and the description does not conceal information people need. Be as specific as the evidence and privacy considerations allow: vague reassurance may protect confidentiality but leave affected people unable to tell whether they should act.

Do not describe a suspected weakness as a confirmed cause before the investigation establishes it. A technical theory can change as responders inspect logs and compare reports. Presenting an early theory as fact can send customers and staff toward the wrong explanation, and corrections may not reach everyone who saw the first claim. Share the customer-facing effect in ordinary language, and have security and privacy specialists review details that could expose individuals or compromise the investigation.

Security communication also has legal and contractual dimensions. Notification duties vary by jurisdiction, sector, contract, and incident; some rules set specific deadlines or require notices to particular groups. Work with legal and privacy specialists early to identify which notices apply. This review helps distinguish a general public update from a notice that must reach a defined audience through a specific process. A public status update does not necessarily replace a required notice to a regulator, customer, partner, or employee.

For example, a supplier incident may affect a service your organization provides, but the supplier may still be determining which customers or operations are involved. Tell your audience what your own team has confirmed, what it is checking with the supplier, and when it will return with more information. This is more useful than repeating the supplier’s uncertainty without context, and it avoids claiming there is no impact simply because the supplier has not yet given you a complete answer.

Keep a steady update rhythm, even when there is no breakthrough

During a security event, set a realistic update time and meet it, even if the main news is that the investigation continues. Silence leaves people to fill the gap with guesses, repeated support requests, and screenshots from unofficial accounts. A short check-in can show that the organization is still working and give readers a reliable place to return. The promise also creates a discipline for the team: it must reassess what is known at a set point rather than waiting for a complete answer that may take much longer.

For example, promise an update by 4 p.m. and discover at 3:50 that analysis is still under way. Publish a brief note at the promised time: “We are still reviewing system activity. We have no confirmed change to the impact described in our earlier notice. Our next update will be here by 8 p.m.” That says less than a full report, but it respects the promise and keeps uncertainty visible. If the investigation is taking longer than expected, readers can plan around the next check-in instead of repeatedly looking for news.

Increase the pace when people need to change their behavior. If the team identifies an immediate step, such as avoiding a particular message or using a different payment route, communicate that promptly through reachable channels. Waiting for the normal update time can leave people exposed to a known risk. When the facts are stable and no new action is needed, a slower, clearly stated cadence may be more useful than a stream of minor notes, which can overwhelm readers and make meaningful changes harder to spot.

Use a visible update history so readers can track what changed. Put a timestamp on every entry, preserve earlier statements when feasible, and label corrections plainly. This lets people compare new guidance with what they may already have read or shared. If an earlier notice suggested that a group was unaffected and later evidence shows otherwise, state the correction, explain the updated scope in clear terms, and describe what affected people should do now. A direct correction may be uncomfortable, but leaving the earlier statement unaddressed can prolong harm and erode trust.

After the event, offer a follow-up that covers confirmed impact, response actions, available remedies, and changes the organization can reasonably describe. A follow-up closes the loop for people who acted on earlier notices and helps them understand what the organization learned. Do not promise that an incident can never happen again. Trust grows through follow-through: people can see what happened, what the team did, and what it learned, even when some investigative details must remain private.

Frequently Asked Questions

What should our first message say?

State that you are investigating, describe the confirmed service or customer impact, share any urgent steps people should take, and give the place and time of your next update. If you do not know whether information was affected, say that the investigation has not confirmed it. Avoid guessing about the cause.

How quickly should we communicate?

Send a useful notice as soon as you have verified information, especially when people may need to protect an account, avoid a scam, or use another service route. Coordinate timing with incident responders and legal or privacy specialists, since notification duties vary by jurisdiction and incident. Do not wait for a complete investigation if a credible risk calls for an early, careful warning.

What if we do not know whether personal data was exposed?

Say plainly that the investigation is ongoing and that you have not confirmed whether personal data was affected. Describe what you are checking and give a time for another update. Do not suggest either exposure or safety without evidence.

Should we notify customers before the investigation is complete?

Early communication can help when a credible risk gives customers a useful action to take. Coordinate the message with response, legal, and privacy teams, and separate confirmed facts from questions that remain open. For example, you can advise customers to use your known website address while you investigate suspicious reset messages.

Which details should we leave out of a public update?

Leave out personal information, unverified claims, and technical details that could compromise the investigation or expose a weakness. Give people enough to understand the known impact and take practical steps. A clear description of an affected service is usually more useful than a detailed map of internal systems.

How often should we post updates?

Choose a cadence your team can meet and state when the next update will appear. Keep that appointment even if the investigation has not found a major change. Post sooner when new evidence changes the risk or people need to act differently.

How should we respond to rumors?

Check a claim against internal evidence before responding, and correct material misinformation with a concise, factual update. Point people to the current official notice. Avoid repeating unverified details that do not help readers understand the risk or decide what to do.

What should we communicate after the event?

Share a clear account of confirmed impact, the response, available remedies, and improvements you can describe accurately. Explain what changed if earlier updates needed correction. Then review how messages moved between teams and update your plan so the next incident has a clear channel, owner, and update rhythm.

Conclusion

Send the clearest useful message you can support with evidence, then keep your promise to update it. You do not need a complete investigation to tell people what service is affected, what remains unknown, and where to find help. You do need to make the limits of your knowledge plain.

When a service falters, people look for a steady light in the noise. Give them one: a practical next step, a trustworthy channel, and a time to check back.