Disclosing a Vulnerability Without Losing the Room

A security company can meet vulnerability disclosure from two opposite sides.

Vulnerability disclosure means telling the organization that can fix a security flaw, its users or the public about it. In coordinated disclosure, the finder reports privately first and works with the vendor on the fix and on when details go public, often under a stated deadline. If you're a security vendor and you found something in someone else's product, disclosure is a reputational opportunity that can easily turn into a fight. If you found something in your own, it's an exercise in limiting damage you can't avoid.

In my experience, both go wrong for communications reasons more often than technical ones.

Key takeaways

• In October 2024 the SEC fined four companies, including the security vendors Check Point and Mimecast, over disclosures it found had minimized intrusions linked to the SolarWinds attack.
• Under Item 1.05 of Form 8-K, a US public company generally has four business days to disclose a material cybersecurity incident, counted from its decision that the incident is material, not from discovery.
• Coordinated disclosure windows differ by policy: CERT/CC normally publishes 45 days after the initial report, and Google Project Zero gives vendors 90 days to patch, or seven if the flaw is already being exploited.

How should a company disclose a vulnerability in its own product?

When a flaw is in a company's own product, its disclosure is judged on speed and on how plainly it tells customers what happened and what to do.

Speed beats polish, within reason. Have the customer advisory ready when the fix ships, not after. Google's Project Zero says attackers study security patches to work out the flaw behind them, so a patch can reveal the problem before you announce it. Wait too long and someone else describes it first, usually less accurately and less charitably.

Say what happened plainly. Security practitioners spot hedged language quickly, and I've seen hedging turn a technical problem into a trust problem. "An authentication bypass affected accounts using X between these dates" is better than any sentence containing "may have been potentially impacted." Being clear about what you don't know yet is a different thing: say what's confirmed, what's still under investigation, and when the next update is coming.

Hedging can also become the regulator's story. In October 2024 the SEC fined four companies, including the security vendors Check Point and Mimecast, over disclosures it found had minimized intrusions linked to the SolarWinds attack. In Unisys's case, the SEC said the company described its cyber risks as hypothetical after it knew of two intrusions in which gigabytes of data were taken. The companies settled without admitting or denying the findings, and two commissioners dissented.

Publish the timeline. When you learned, when you fixed, when you notified. In my experience, an honest slow timeline does less damage than a concealed one.

Say what customers must do. Lead with what the reader needs to do, not with the context around it.

Don't thank yourself. Language congratulating your own responsiveness reads badly next to a flaw in your product. The tone that works is factual and unadorned.

Credit the finder. If an external researcher reported it, name them if they consent. It costs nothing and signals a functioning relationship with the research community, which is watching how you behave.

When the clock isn't yours

Disclosure timing is not always a company's own choice. If the flaw was exploited, customer data was exposed or an incident disrupted operations, a rule may choose it for you. Some of the main clocks as of November 2026, in plain terms and not a complete list:

• SEC, US public companies. Item 1.05 of Form 8-K generally requires disclosure of a material cybersecurity incident within four business days of the company deciding it is material, and that decision has to be made without unreasonable delay. The clock starts at the materiality decision, not at discovery. Delay is allowed only in narrow cases, such as when the US Attorney General finds disclosure would put national security or public safety at substantial risk. Foreign private issuers follow Form 6-K rules instead.
• US state breach laws. All 50 states require notice to people whose personal information was breached, with different triggers and deadlines. Since January 1, 2026, California's law has generally required notice within 30 calendar days of discovering or being notified of a breach, with delays allowed for law enforcement needs or to determine the breach's scope and restore the system.
• EU, NIS2. Organizations the directive covers generally owe their national CSIRT or authority an early warning without undue delay and within 24 hours of becoming aware of a significant incident, a fuller notification without undue delay and within 72 hours (24 for significant incidents affecting trust services), and a final report within a month of that notification. If the incident is still going on then, a progress report is due instead, and the final report follows within a month of the incident being handled. It applies through national laws, and in July 2026 the European Commission took four member states to court for not finishing theirs.
• EU, GDPR. When personal data is breached, the controller (the organization that decides how the data is used) must notify its data protection authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to put people's rights at risk. A processor handling the data for someone else notifies that controller without undue delay instead. If the risk to people is high, the controller generally must also tell them without undue delay, with some exceptions, such as when the data was encrypted.
• EU, Cyber Resilience Act. Since September 11, 2026, manufacturers of products the Act covers (software and connected hardware sold in the EU, with some sectors excluded) must report actively exploited vulnerabilities in them: an early warning without undue delay and within 24 hours of becoming aware, a notification without undue delay and within 72 hours of becoming aware, and a final report within 14 days of a fix or mitigation being available. They must also tell affected users, and if they don't do it in time, the national CSIRT may tell those users itself.
• CIRCIA, US critical infrastructure. Once CISA's final rule takes effect, covered organizations will owe CISA a report within 72 hours of reasonably believing a covered incident occurred, and within 24 hours of paying a ransom. CISA's own page says no reporting is required until then, and the rule had not been published as of early November 2026.

Which of these apply to you is a question for your lawyers, not for this post. The communications point is narrower. An 8-K is public the moment it's filed, so for a public company the first public account of an incident may be a securities filing. The facts in that filing, your customer notice and anything you publish have to match. Each has its own audience and deadline, so I'd draft the public version alongside the filing rather than after it, and never hold a required notice for a blog post.

How should you handle coordinated vulnerability disclosure in someone else's product?

In my experience, research on another company's product is where security vendors most often damage themselves, because the incentives push toward publicity and the norms push the other way.

Follow coordinated disclosure and be able to show it. Contact the vendor privately, give a reasonable remediation window and a publication date, and write down every exchange. Aim to agree on the timing, and record it if the vendor disagrees or doesn't answer. Well-known policies differ. CERT/CC normally publishes 45 days after the initial report, with exceptions. Google's Project Zero gives vendors 90 days to patch, or seven if the flaw is already being exploited, then usually waits 30 more days after a timely patch before publishing details; since 2025 it has also trialed listing the vendor, product and deadline of open reports, without technical details. In my experience, when the timeline is documented the story is your research. When it isn't, the story becomes your conduct.

Don't publish to a news cycle. Timing a disclosure for maximum attention rather than for user safety is visible to practitioners, and it costs you standing with the exact audience you're trying to impress.

Separate the finding from the marketing. A research write-up that pivots into a product pitch undermines the research. If your product would have caught it, that belongs in a single line at the end, if anywhere.

Proportion the severity honestly. Inflated severity ratings get corrected publicly by other researchers, and that correction is more memorable than the original finding.

Expect the vendor to be unhappy and be fine with that. A vendor that disputes your finding is normal. A researcher who overstated it and gets caught is not recoverable in the same way.

Why the research community's opinion matters commercially

Security buyers ask practitioners what they think of vendors. Practitioners talk to each other. A company known for grandstanding disclosures or for handling its own vulnerabilities badly accumulates a reputation that I've rarely seen a marketing budget correct.

This is the specific reason security PR can't be run purely as promotion. The audience overlaps heavily with the community that evaluates your technical conduct, and those practitioners influence purchases.

What should a company have ready before it needs to disclose?

A company should have its disclosure basics in place before it ever needs them. A disclosure policy published on your own site, with a contact route and a stated response commitment. A security.txt file, the format set out in the IETF's RFC 9116, puts that contact where researchers' tools look for it. A drafted template for your own vulnerability and incident notices, approved by legal before you need it. A named person who speaks for the company on security matters, technical enough to answer follow-ups. A short list, agreed with counsel, of which reporting clocks apply to you, who owns each one and when to check it again. The rules move: CIRCIA's final rule is still pending, and industry groups petitioned the SEC in 2025 to rescind the Item 1.05 requirement. My rule for our own research is the same: a fact gets a source and a date to check it again, and it is renewed only with fresh proof, never because it sounds right.

Most of the crises I've dealt with came up suddenly, not from a plan sitting in a drawer. Sometimes the lawyers override everyone and the only thing you can say is no comment, because anything more creates liability. Beyond the disclosure basics, what I recommend having ready is simple: an email you can copy and send to employees, the few things you're asking them not to do, like posting about it, and talking points the executive team follows until there's further guidance.

Companies that assemble these during an incident lose days they don't have, and I think the delay is what turns a manageable event into a story about the delay. The outside crisis help you might want is also easier to choose before you need it.

Common questions

What is vulnerability disclosure? Vulnerability disclosure means communicating a security flaw to the organization that can fix it, to affected users or to the public. It covers a company announcing a flaw in its own product and a researcher reporting one in someone else's. Not every model ends in publication. In coordinated disclosure, also called responsible disclosure, the first report is private and details come out after a fix or a stated deadline.

What is coordinated vulnerability disclosure? The practice of reporting a vulnerability privately to the affected vendor, sometimes through a coordinator, allowing time for a fix or mitigation, and publishing on a schedule, ideally an agreed one. Timing varies: CERT/CC normally publishes after 45 days, and Google Project Zero allows 90 days to patch, then usually 30 more before publishing details. Whatever policy you follow, document it and explain any exception; in my experience an unexplained deviation becomes the story.

How quickly should a company disclose a vulnerability in its own product? As soon as customers can act, whether on a patch or a mitigation; if a flaw is being actively exploited, that can mean before a fix exists. I'd put speed ahead of polish. Reports to regulators and notices to customers have their own triggers and deadlines, such as the SEC's four-business-day rule or the EU's 24-hour early warnings, and they don't have to coincide with publishing technical details.

What should a vulnerability disclosure say? What happened, who is affected, over what period, what action the reader must take, and a timeline of discovery and remediation. Plain language, clear about what's confirmed and what's still under investigation, action item first.

Should security vendors publish research on other companies' products? Yes, following coordinated disclosure with a documented timeline, honest severity assessment, and the research separated from product promotion. Done badly, it damages a vendor's standing with the practitioners whose opinions reach security buyers.

Why does the security research community matter for marketing? Because the security research community overlaps with the practitioners buyers consult before purchasing. Reputation for technical conduct in that community affects sales in ways I don't think advertising can easily offset.

Sources

• U.S. Securities and Exchange Commission, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure: Small Entity Compliance Guide, SEC, updated September 10, 2024
• U.S. Securities and Exchange Commission, SEC Charges Four Companies With Misleading Cyber Disclosures, SEC, October 22, 2024
• Hester M. Peirce and Mark T. Uyeda, Statement Regarding Administrative Proceedings Against SolarWinds Customers, SEC, October 22, 2024
• U.S. Securities and Exchange Commission, Joint Petition for Rulemaking to Amend the SEC Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure Rule (File No. 4-856), SEC, May 22, 2025
• National Conference of State Legislatures, Security Breach Notification Laws, NCSL, updated January 17, 2022
• California Legislature, SB 446, Data breaches: customer notification (Chapter 319, Statutes of 2025), approved October 3, 2025
• European Parliament and Council, Directive (EU) 2022/2555 (NIS2 Directive), Article 23, EUR-Lex, December 14, 2022
• European Commission, Commission refers Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose the rules on cybersecurity, July 8, 2026
• European Commission, Cyber Resilience Act: Reporting obligations, updated September 11, 2026; Regulation (EU) 2024/2847, Article 14, EUR-Lex
• Cybersecurity and Infrastructure Security Agency, Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA), CISA, accessed November 8, 2026
• CERT Coordination Center, Vulnerability Disclosure Policy, Carnegie Mellon University
• Google Project Zero, Vulnerability Disclosure Policy, Google; Reporting Transparency, updated November 3, 2026
• OWASP Foundation, Vulnerability Disclosure Cheat Sheet, OWASP Cheat Sheet Series
• European Parliament and Council, Regulation (EU) 2016/679 (GDPR), Articles 33 and 34, EUR-Lex, April 27, 2016
• E. Foudil and Y. Shafranovich, RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, IETF, April 2022

Salient PR works with security companies on disclosure communications, research publication and incident readiness. Reporting deadlines are summarized from the regulators' and standards bodies' own pages as of November 2026 and are not legal advice.