Incident Disclosure 101: How to Tell Your Customers You’ve Been Hacked

Or publish this blog post. Or sit on a call reading a statement that starts with, “We recently identified unauthorized access…”

But if you handle customer data, run a SaaS product, sell anything online, or basically exist on the internet long enough, the odds of dealing with a security incident are not zero. Not even close.

And here’s the thing people miss. Customers don’t usually judge you on whether you got hit. They judge you on what you did next. How fast you told them. How honest you were. Whether you tried to hide behind vague language. Whether you gave them anything useful to do.

So this is Incident Disclosure 101. The practical version. Not the compliance checklist written by someone who never has to actually send the message.

First, what “disclosure” actually means (and what it doesn’t)

Disclosure is you telling impacted people, in plain language, what happened, what it means for them, and what you are doing about it.

It is not:

• a press release full of nothing
• a legal essay
• “out of an abundance of caution” copy pasted six times
• waiting until you know every detail (you won’t)
• a promise that it will “never happen again” (please don’t)

Also, disclosure does not mean you share every forensic detail you have. You can and should avoid publishing info that helps the attacker or compromises an ongoing investigation. But you still need to be specific enough that a customer can understand their risk.

That’s the balance.

The moment you suspect a breach, the clock starts

The worst disclosure mistakes are usually time related, not writing related.

People wait because:

• “We’re still investigating”
• “We don’t want to scare people”
• “We need leadership approval”
• “Legal is reviewing”
• “We need certainty”

And then it’s been 10 days and customers find out from a journalist, or a paste site, or their own logs. At that point you have already lost the story. Now you are “the company that hid it”.

Practically, you should plan for two disclosures:

1. Initial notice: early, honest, limited facts, clear guidance.
2. Follow up update(s): what you learned, what changed, what customers should do now.

If you do only one message, you’ll either be too vague (because it’s early) or too late (because you waited).

Before you write a single word, get alignment on these 8 facts

You can draft while the investigation is ongoing, but you need a baseline set of statements everyone agrees are true right now.

Write these down internally, bullet style:

1. What happened (one sentence, no euphemisms)
2. When it started (or when you first detected suspicious activity)
3. When you contained it (if contained)
4. Which systems were affected (product, database, support tool, S3 bucket, whatever)
5. What data types were involved (not guesses, categories)
6. Who is impacted (all customers, subset, specific region, specific plan, etc)
7. What you have done (containment steps)
8. What customers should do now (password reset, rotate API keys, watch for phishing, freeze credit, etc)

If you cannot answer one of these, that’s okay. Say you cannot answer it yet. But don’t skip the question.

The core rule: be clear about impact, not drama

Customers don’t need theatrics. They need clarity.

The best disclosures are kind of boring, honestly. In a good way.

They say what happened, what data was accessed, what the customer should do, and how you’ll support them.

Avoid:

• “We take security very seriously” (everyone says this)
• “Sophisticated actor” (maybe, but it reads like excuse making)
• “No evidence at this time” if you actually have limited visibility (say that instead)
• “May have been accessed” when you know it was accessed (just say it)

Try to be precise with language:

• Accessed means someone got into it.
• Exfiltrated means they took it out.
• Encrypted means ransomware, typically.
• Unavailable is downtime.
• Integrity impacted means someone changed data.

Don’t use these terms if you don’t understand them. But also don’t hide behind “incident” if you mean “someone broke in.”

How to structure the customer message (the template that works)

If you only take one thing from this article, take this structure. It’s the one that keeps you honest and keeps the reader oriented.

1) Start with the headline sentence

One or two lines. Direct.

Examples:

• “We’re writing to let you know that we detected unauthorized access to our customer support system.”
• “On April 3, we identified suspicious activity in our production environment and confirmed unauthorized access.”

Don’t start with background. Don’t start with values. Start with the event.

2) What happened and when

A short timeline. Dates matter.

• When you detected it
• When it started (if known)
• When you contained it (if contained)

Even if you’re uncertain, you can say “We currently believe the activity began on or around…”

3) What information was involved

Use categories. Then, if you can, tell customers whether their specific data was affected.

Good:

• Name, email address, billing address
• Hashed passwords (and what hashing standard, if you’re comfortable stating it)
• Partial payment card info (last 4, expiration)
• Support tickets and attachments
• API keys
• Government ID (if yes, you say it plainly)

Bad:

• “Some personal information”
• “Certain customer data”
• “Limited information”

If data was not involved, be careful. Only exclude things you have high confidence were not accessed.

4) What you have done

Containment and remediation steps, not promises.

Examples:

• Disabled the compromised account / token
• Rotated keys
• Forced password resets
• Added additional logging
• Engaged an external incident response firm
• Notified law enforcement (only if true)
• Implemented additional controls (MFA, conditional access, network segmentation)

5) What the customer should do now

This is the part most companies mess up. They give customers nothing concrete, so customers are left with anxiety and Google.

Give a checklist. Make it specific.

Examples:

• Reset password (and do not reuse old passwords)
• Enable MFA
• Rotate API keys in your dashboard
• Review audit logs for unusual logins
• Be cautious of phishing emails referencing your company
• If SSNs or financial data involved, recommend credit monitoring steps

If you are offering support like credit monitoring, explain how to enroll. Make it simple.

6) Where to get updates, and how to contact you

Provide:

• a status page link or a dedicated incident page
• a support email with priority routing
• optional phone number for enterprise customers
• a Q and A section for common questions

Also. Set expectations.

“We will provide our next update by [date/time] even if the investigation is ongoing.”

That line builds trust. Because silence is what freaks people out.

Channel strategy: email is not enough

Depending on the situation, you’ll need multiple channels. Not because you want to spam people. Because people miss email. Or your email lands in promotions. Or the attacker compromised email.

Common options:

• Direct email to impacted users
• In app banner or modal
• Status page incident post
• Blog post or newsroom update (public)
• Customer success outreach for high value accounts
• Press statement (if it’s going to be covered anyway)

One note here. Keep messaging consistent across channels. Nothing destroys trust faster than a vague public post and a specific private email that later leaks. Assume anything you send could become public.

What to say when you don’t know everything yet

This is where people get weird. They either go silent, or they overstate certainty.

You can say:

• “The investigation is ongoing.”
• “We do not yet have evidence of X, but our visibility is still improving and this may change.”
• “We will update you as we learn more.”

The key is you don’t use uncertainty as a reason to be non committal on customer guidance. Even with limited facts, you can still tell people to reset passwords, be alert for phishing, and contact support.

Also, avoid “we have no evidence” as a blanket phrase. Sometimes you truly don’t. But often it just means “we have not found evidence yet.” Those are different.

Legal, compliance, and timing (the stuff nobody wants, but you need)

This article isn’t legal advice. Still, you need to know the general landscape:

• Many laws require notification within a certain timeframe once you determine a breach involving certain types of data.
• Contracts, especially enterprise agreements, often require notification within X hours or days.
• Regulators may have their own reporting deadlines.
• Cyber insurance policies may require you to use approved incident response vendors and notify the carrier quickly.

So yes, loop in legal early. But don’t let disclosure get trapped in legal purgatory. The job is to reduce harm. Not to write the most defensible paragraph.

If you’re stuck, aim for this: communicate what you know, what you don’t, and what customers can do right now. Then follow up.

The tone that works (and the tone that backfires)

You’re aiming for: calm, direct, human.

Acknowledge the seriousness without being melodramatic. And don’t try to sound like a bank brochure.

This line is fine, sometimes necessary:

“We’re sorry this happened.”

But don’t overdo the apologies. Customers want action. Too much “we regret” starts to sound like PR.

Also, do not blame customers. Not even subtly. Not even with “we recommend good password hygiene” as the lead. Save that for the action section and frame it as support, not blame.

The biggest mistakes I see in breach disclosures

Here’s the highlight reel of what not to do.

1) Waiting for perfect information

You won’t get it. Move.

2) Hiding behind vague language

“An incident occurred” tells customers nothing.

3) Focusing on your security philosophy instead of customer impact

The customer is thinking: “What about my data?” Not “Tell me about your commitment.”

4) Burying the lede

If the first paragraph is fluff, people assume the worst.

5) Over promising

“Never again” is not believable and will haunt you later.

6) No customer actions

If customers cannot do anything, say that explicitly and explain why. Otherwise give them a list.

7) Inconsistent statements across channels

One truth. One timeline. One source of updates.

A simple disclosure template you can copy and adapt

Use this as a starting point. Keep it short. You can add a Q and A below it.

Subject line options:

• “Security incident notice”
• “Important notice about your [Company] account”
• “Notice of unauthorized access to [system]”

Body:

Hello [Name],

We’re writing to let you know that on [date] we detected unauthorized access to [system/product]. We contained the activity on [date] and immediately began an investigation with support from [internal team / external incident response firm].

What happened

On [date/time], we identified [brief description]. Our current investigation indicates the unauthorized access occurred between [date] and [date]. We will update this timeline if it changes.

What information was involved

Based on our investigation to date, the affected data may include:

• [data type 1]
• [data type 2]
• [data type 3]

It did not include:

• [only list exclusions you are confident about]

What we have done

We took the following steps:

• [containment step]
• [remediation step]
• [security improvement]

What you can do

We recommend that you take these steps now:

• [customer action 1]
• [customer action 2]
• [customer action 3]

Please also be alert for phishing messages that reference [Company] or this incident. We will not ask for your password via email.

More information and support

We will post updates at [link] and provide our next update by [date/time]. If you have questions, contact us at [support email] and include the subject line “Security incident.”

We’re sorry for the disruption and concern this may cause. Protecting your information is important to us, and we will continue to share updates as we learn more.

Sincerely,

[Name]

[Title]

[Company]

The follow up update: what to include 24 to 72 hours later

Your second message matters. It’s where trust is rebuilt or destroyed.

Include:

• Updated timeline, even if it’s just narrowing a window
• Confirmed scope (how many accounts, which customers)
• Clear statement on data access vs exfiltration if you can support it
• Any additional actions customers should take
• What security changes were made immediately (MFA enforced, tokens rotated, etc)
• What you’re doing longer term (audit, pen test, architecture changes)
• If applicable, what you’re offering (credit monitoring, dedicated support)

Keep it readable. Customers should not need a security background to understand what changed.

Internally, decide who owns the narrative (before the incident)

Small aside, but important. The easiest time to plan disclosure is before you need it.

At minimum, define:

• Who approves the customer message (one person, not a committee)
• Who writes the first draft
• Who owns the status page
• Who briefs customer success
• Who handles press inquiries
• Who is the technical spokesperson if needed

Because during an incident, your company will be stressed, tired, and reactive. If you don’t have an owner, disclosure becomes a group project. And group projects move slowly.

Wrapping up, this is the point

Incident disclosure is not about sounding perfect. It’s about reducing harm and earning trust in a moment where trust is fragile.

Tell customers quickly. Tell them plainly. Tell them what it means for them, not just what it means for you. Give them steps they can take today. Then keep showing up with updates until the situation is truly closed.

If you do that, even if the incident itself is bad, customers will remember the part where you treated them like adults. That part matters more than most companies think.

FAQs (Frequently Asked Questions)

What does ‘incident disclosure’ mean in the context of a security breach?

Incident disclosure means informing impacted customers in plain language about what happened, what it means for them, and what actions are being taken. It is not a vague press release, legal essay, or overused cautionary statements. The goal is to provide clear, specific information without compromising ongoing investigations or aiding attackers.

Why is timely disclosure important after detecting a security breach?

Timely disclosure is crucial because delays often lead to customers learning about the breach from external sources like journalists or logs, damaging trust. Prompt communication—starting as soon as a breach is suspected—demonstrates honesty and helps control the narrative before misinformation spreads.

What are the key facts that should be aligned internally before communicating with customers?

Before sending any message, teams should agree on eight facts: 1) What happened; 2) When it started or was detected; 3) When it was contained (if applicable); 4) Which systems were affected; 5) What types of data were involved; 6) Who is impacted; 7) What containment steps have been taken; and 8) What customers should do now (e.g., reset passwords). If some details are unknown, state that clearly.

How should companies communicate the impact of a breach without using unnecessary drama?

Companies should focus on clarity and precision rather than theatrics. Use straightforward language describing what data was accessed, what customers need to do, and how support will be provided. Avoid vague phrases like ‘sophisticated actor’ or empty reassurances. Be precise with terms like ‘accessed,’ ‘exfiltrated,’ or ‘encrypted’ only if fully understood.

What structure should a customer notification message follow during a security incident?

A clear customer message typically follows this template: 1) Start with a direct headline stating the event; 2) Provide a brief timeline including detection and containment dates; 3) Detail what information was involved using specific categories; 4) Explain who is impacted and what they should do next. This approach keeps communication honest and reader-oriented.

What common mistakes should be avoided when disclosing a security incident to customers?

Common mistakes include waiting too long to disclose due to ongoing investigations or legal reviews, using vague or overly cautious language that confuses customers, failing to provide actionable guidance, and hiding behind generic statements instead of being transparent about the breach’s nature and impact.