Safeguard
Industry Analysis•

How to disclose past security incidents during due diligence

How to tell a buyer or investor about a past breach: what to include, how to stay accurate, and why public company rules make precision matter.

Safeguard Security Team
3 min read

Tell buyers about past incidents early, in writing, with facts: what happened, when, what data and systems were involved, how you responded and what changed. Do not minimise, speculate or guess at numbers. Have counsel review the text before it leaves the building.

Why early disclosure wins

Buyers run their own scans and talk to customers. An incident they find themselves looks like concealment even if it was minor. An incident you present, with fixes, looks like a team that operates.

What to include

A one page incident summary per event:

  • Dates of occurrence, detection and containment.
  • Systems and data categories affected.
  • Whether customers or regulators were notified, and when.
  • Root cause in plain words.
  • Fixes shipped and how you verified them.
  • Anything still open.

Keep to what you can document. If a number is unknown, write that it is unknown.

The public company angle

If the seller or buyer is a US public company, disclosure carries legal weight. The SEC's final rules require a Form 8-K Item 1.05 filing generally within four business days after a registrant determines a cybersecurity incident is material. Annual reports must describe processes for managing material cybersecurity risks and the material effects of prior incidents. Smaller reporting companies had extra time to comply with the 8-K requirement.

Private targets are not bound by these filings, but an acquirer that is public will care how the target's history affects its own disclosures.

Common mistakes

  • Calling an event "minor" without defining it.
  • Mixing confirmed facts with suspicion.
  • Giving different versions to different parties.
  • Sharing forensic reports without a privilege review.
  • Omitting incidents at vendors that touched your data.

After disclosure

Expect follow up questions and a request for the forensic report. Answer them through one owner and keep a log of what was shared with whom.

Writing the incident summary

Write the summary for a reader who was not there. Start with a one sentence description, then a short timeline with dates and times in one time zone. Describe affected systems by function, not by internal nickname.

Be careful with causation. Write what you know and how you know it, for example that logs showed a credential used from an unfamiliar address. Do not write what you suspect as if it were established. If forensic work is ongoing, say so.

Finish with changes made, each with a date and an owner. Buyers read the final section most closely, because it shows whether the organization learned something.

Keep a single master copy and number its versions. Every number that appears in later conversations should match it.

Quick check

Should we disclose near misses?

Mention significant ones briefly, especially if they led to control changes. Use judgment and counsel.

Is this legal advice?

No. Disclosure obligations vary by jurisdiction and contract, so involve counsel.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.