Developers write far more legally consequential prose than they think, and almost none of it is code. It's the SECURITY.md in the repo root. It's the "Security" page someone in marketing asked you to fill in three years ago. It's the status page update typed at 2 a.m., and the sentence in a customer notice specifying exactly which data was affected. The research summarized in this overview of what the evidence shows about cyber incident disclosure treats post-breach communication as a measurable discipline with predictable failure modes — and the enforcement record of the last three years has quietly turned it into an engineering discipline too. In the most closely watched cybersecurity case of the decade, the only allegation that survived a motion to dismiss concerned a technical description of access controls posted on a website.
The claim that survived was written by engineers
On July 18, 2024, Judge Paul Engelmayer of the Southern District of New York issued a 107-page opinion in the SEC's case against SolarWinds and its CISO. Most of it was a defeat for the agency. Claims built on blog posts, press releases, and podcast appearances were dismissed as non-actionable corporate puffery — statements too general for any reasonable investor to lean on. The theory that cybersecurity controls fall under "internal accounting controls" was rejected outright. Post-incident 8-K disclosures were held to be reasonable given what was knowable at the time.
One thing lived: the company's "Security Statement," a technical page describing its practices to customers. The court let claims proceed specifically on its representations about access controls and password policy, because those were concrete enough to rely on and, as pled, contradicted by internal presentations, security assessments, and Slack messages. The SEC ultimately dismissed the whole action with prejudice in November 2025, so no liability was ever established — but the legal line drawn in 2024 didn't go anywhere. Vague marketing language is protected precisely because it says nothing. The specific, verifiable technical claim is the one with teeth.
Read that sentence again if you maintain a trust page. "We take security seriously" is legally inert. "All administrative access requires MFA" is a factual assertion about your infrastructure that someone will one day compare against your actual IAM configuration, your Jira backlog, and your team's Slack history.
A file-name review became a false public statement
The second case is more uncomfortable, because the mistake was a technical judgment call that any of us could make under pressure.
Blackbaud discovered a ransomware intrusion in May 2020. To scope it, technology staff reviewed the names of exfiltrated files rather than analyzing their contents. Based on that review, the company posted a notice in July 2020 telling customers the attacker had not accessed bank account information or Social Security numbers. Then customers began writing in — over a thousand messages — many pointing out that they had entered sensitive data into fields the software did not encrypt. Deeper analysis confirmed unencrypted bank account details and Social Security numbers had in fact been taken. That finding never reached the people responsible for the company's public disclosures, and the website statement stayed uncorrected while a later quarterly filing described data-exfiltration risk as hypothetical. The SEC's settled order imposed a $3 million penalty in March 2023, without alleging intentional misconduct.
There is no villain in that story. There is a scoping shortcut, a schema assumption ("that field holds notes, not SSNs"), and a missing edge in the org chart between the person who learned the truth and the person who had published the falsehood. All three are engineering artifacts.
It is not only a public-company problem
Anyone at a startup assuming this is a Fortune 500 concern should read the FTC's finalized order against GoDaddy from May 2025. The agency's theory was straightforward: the company advertised "award-winning security" while lacking multi-factor authentication, threat monitoring, and secure connections for customer data. Section 5 of the FTC Act reaches any company making deceptive claims, private or public, seed-stage or not. The remedy reads like a backlog someone else wrote for you — mandatory MFA including at least one method that doesn't require a phone number, HTTPS on APIs handling covered information, an update-management program, biennial third-party assessments, and incident reporting to the Commission within ten days.
Why silence is not the safe default
The instinct after reading all this is to say nothing about security anywhere, ever. The empirical record argues the opposite. In a study published in the Review of Accounting Studies, Amir, Levi, and Livne compared attacks companies disclosed themselves against attacks that were concealed and later surfaced by outsiders. Withheld incidents were associated with roughly a 3.6% decline in equity value in the month of discovery; disclosed incidents, around 0.7%. Their model also suggested managers tend to speak only once outsiders already suspect an attack with about 40% probability — meaning the incidents that stay hidden skew toward the severe ones, and the "breaches don't really hurt stock prices" folk wisdom is built largely on the mild cases that got announced.
So the goal is not silence. It is writing things that stay true under adversarial reading:
- Describe controls that are enforced, not intended. If MFA is required for 94% of admin accounts, the honest sentence names the exception. A published claim your own audit log contradicts is the exact shape of every case above.
-
Version your security page like code. Keep it in the repo, require review, and let
git logprove when each claim was accurate. An undated marketing page is a permanent unqualified assertion. - Never scope a breach by metadata alone. File names, table names, and bucket paths describe intent, not contents. Users put card numbers in "comments" fields. Verify before publishing a negative.
- Prefer "we have confirmed X" over "Y did not happen." Negative claims require exhaustive verification; positive claims about confirmed findings age gracefully as the investigation continues.
- Make correction a defined path, not a favor. Whoever discovers the earlier statement was wrong needs a named recipient and an obligation to use it. Blackbaud's penalty rests substantially on that link being absent.
- Assume Slack is exhibit A. Internal messages contradicting public claims were central to the surviving SolarWinds allegation. Write internally as though it will be read aloud, not because you're hiding anything, but because accurate internal writing is what makes accurate public writing possible.
The uncomfortable summary
Nothing in the enforcement record punishes being breached. Courts and regulators accept that competent organizations get compromised. What draws liability is the delta between what a company published about itself and what its own engineers knew — a gap authored, almost always, by people writing documentation rather than exploits.
The fix isn't legal review of everything. It's treating security documentation as a claim about a system, with the same expectation of verification you'd apply to any other assertion about production. If you can't point to the control that makes a sentence true, delete the sentence.
Top comments (0)