Transparency Schmarency: Security Disclosures Should Be Honest and Helpful

Organizations often default to promising "transparency" in their incident communications. But transparency alone is insufficient – and sometimes counterproductive. What we really need are disclosures that are both honest and helpful.

The Problem with "Transparency"

Transparency is often misinterpreted as merely revealing an incident. It should mean a comprehensive and clear communication that provides the necessary context and actionable information. This approach treats disclosures not as confessions, but as resources that empower stakeholders.

Many organizations approach security disclosures as a legal obligation, minimizing the information they reveal to only what is required by contracts or regulations, or what they believe will limit their liability. However, this defensive stance overlooks the opportunity to build trust and enhance security outcomes (the lawsuits are coming no matter what; you might as well extract some value from the experience). 

As we discussed in a previous blog post, it’s helpful to develop your strategy by first asking “what could go right?” so you can reverse-engineer that outcome.

When organizations are genuinely helpful in their disclosures, they:

• Build credibility for future communications
• Contribute to the broader security community's understanding of threats
• Enable faster, more effective responses from affected parties
• Demonstrate that they view security with shared accountability

The Honest and Helpful Alternative

Being honest and helpful means shifting from a defensive, liability-focused mindset to one that prioritizes empowering those affected to take action because no one knows your environment better than you, so it’s your responsibility to ensure disclosures serve a practical purpose beyond legal compliance. My friend and colleague Leona Laurie often says that every communication has a job to do – and in the case of security disclosures, we need specific objectives for every asset we create. 

What "Honest" Means

Honesty in security disclosure goes beyond acknowledging that an incident occurred. It means:

• Clarity about scope: Which systems, data types, and timeframes were affected?
• Admission of unknowns: Being explicit about what you don't yet know rather than hiding behind vague language.
• Context about severity: Helping people understand the actual risk level.
• Accepting responsibility: Taking ownership without deflecting or minimizing.

What "Helpful" Means

Helpful disclosures provide actionable intelligence such as:

• Specific indicators: What should people look for to detect if they've been affected?
• Immediate actions: What steps can individuals or organizations take right now to protect themselves?
• Timeline guidance: When should people expect more information, and what should they do in the meantime?
• Resource provision: Links to tools, guides, or services that can help with response and recovery.

Structure and Format Matter

The way information is organized and presented directly impacts its usefulness and effectiveness. A helpful disclosure isn't just about vomiting out internal information – it's about making that information accessible and understandable.

Lead with Impact and Actions

Traditional disclosures often bury the most important information in legal language or lengthy chronological narratives. Helpful disclosures front-load what people need to know:

• Impact summary first: What data was affected, and who needs to act?
• Immediate actions second: What should people do right now?
• Technical details third: How did the incident happen, and what's being done about it?

Use Scannable Formatting

Well-structured information presented in a scannable format allows people to easily find what they need without having to wade through irrelevant details or search online for other sources that may or may not be accurate. This not only saves time but also reduces stress, making the disclosure more effective.

Helpful formatting also includes:

• Clear section headers that let people jump to relevant information, for example:
  • Executive summary for quick understanding
  • Detailed findings for those who need specifics
  • Technical appendix for security professionals
  • FAQ to address common concerns
• Bulleted action items rather than buried recommendations in paragraphs (see what I did there?) 
• Timeline tables that show what happened when and what comes next
• Risk level indicators that help people prioritize their response

For open source projects, GitHub's Security Advisory feature demonstrates this approach well. Their standardized template includes severity ratings upfront, clearly lists affected products, provides specific remediation steps, outlines disclosure timelines, and acknowledges the contributions of researchers where appropriate. This format helps developers quickly assess the impact and take action, exactly what a helpful resource should do.

Separate but Overlapping Audiences

Different stakeholders require different types of information, and various organizations serve different sets of stakeholders. The industry, market, and geographies where you operate all impact how your stakeholders best receive and consume information. A single wall of text or generic media statement serves no one well. Consider organizing disclosures with distinct, but consistent details for:

• Individual users: Personal protective actions and account security steps
• Business customers: Enterprise-level implications and B2B considerations
• Technical community: Indicators of compromise and technical prevention measures

If the incident is high-profile enough to generate media interest, don’t be afraid to use these assets in your engagements with journalists. They’re extremely valuable in driving consistent and accurate reporting based on your investigation (rather than an ambulance chaser’s), while demonstrating that you’re providing everyone with the information they need.  

Making the Shift

Moving from transparency to honest helpfulness requires changing how we think about our relationship with those affected by security incidents. Instead of treating disclosure as damage control, we should view it as an opportunity to provide a valuable service.

What does this look like in practice? 

1. Preparing helpful frameworks in advance: Don't wait until an incident occurs to figure out how to communicate effectively. Call us, this is what we do! 
2. Investing in investigation capabilities: You can't be helpful if you don't understand what happened.
3. Prioritizing usefulness over perfection: Sometimes it’s better to share actionable preliminary information than to wait for a complete picture, especially when people are at risk.
4. Measuring success by outcomes: Did your disclosure help people protect themselves, strengthen trust in your organization, or just check a legal box?

Security incidents will continue. When they do, we have a choice: we can be transparent in name only, or we can be genuinely helpful and become a trusted source of information and support. The organizations that choose the latter don’t just meet their obligations – they'll contribute to a more secure ecosystem for everyone while building credibility and resilience for their brand.