Transparency Commitment

As an open-source company, Rocket.Chat champions transparency as a foundational value. This principle is embraced not only by our engineering teams but across the entire organization, including our Security team. We strive to operate a transparent security program - sharing our practices, documentation, and decision-making wherever it serves the community, our customers, and our mission.

However, true transparency requires thoughtful boundaries. To maintain trust, safety, and privacy, we must safeguard certain information. As such, our security documentation and activities are categorized based on their appropriate level of visibility, guided by the principle of being public by default unless there is a compelling reason for restriction.

Visibility Levels

✅ Public by Default

These documents or data are openly available to the public, typically via our external Security Handbook. They represent our commitment to transparency and aim to provide meaningful value to users, contributors, and customers without exposing sensitive information.

Examples:

• Rocket.Chat Security Policies

• Security practices and standards

• Guidelines for responsible disclosure

• Remediated vulnerability reports (case-by-case)

• Concluded incident reports (case-by-case, post-review)

• Roadmap items or initiatives without sensitive operational detail

🤝 Open to Rocket.Chat, Partners, or Customers

This information is shared with specific external stakeholders (e.g., customers or partners) due to contractual obligations or its sensitive nature. Public disclosure could introduce undue risk but restricted sharing adds value.

Examples:

• RFP and security questionnaire responses

• 3rd party audit reports or certifications

• Penetration test summaries

• Security roadmap documents with partner/customer relevance

🔒 Internal Only

Documentation and data in this category are restricted to Rocket.Chat team members due to confidentiality, operational security, or privacy concerns. Public availability could expose systems, individuals, or customers to harm.

Examples:

• Vulnerabilities that are unremediated

• Internal runbooks, procedures, and workflows (e.g., Okta, AWS access reviews)

• Detailed audit evidence and reports

• Security KPIs and internal metrics

• SIEM configurations, alert rules, and detection tuning

• Incident reports not yet fully resolved

• Risk assessments and gap analyses

🚫 Restricted: Security Only or By Legal Requirement

This content contains highly sensitive, personal, or legally protected information. It is tightly controlled and access is limited to specific roles (e.g., Security, Legal, Support) or subject to legal restrictions.

Examples:

• Customer contracts involving security terms

• Security incident data with Materially Non-Public Information

• HackerOne submissions prior to triage

• Work communications involving sensitive investigations

Decision Framework: “Should This Be Public?”

When creating or updating security content, we should always ask:

• Does this serve the public good without compromising our defenses or privacy obligations?

If the answer is unclear, consider these filters:

1. Is it relevant to our external stakeholders?
   If not, it should remain internal to avoid clutter and confusion.

2. Does it contain confidential, personal, or operational security information?
   If yes, it must remain restricted until (and if) explicitly approved for release.

3. Is the risk of disclosure mitigated (e.g., vulnerability fully remediated, incident fully resolved)?
   If so, and it adds value or clarity, it may be approved for public release by the Head of Security and/or the CTO.

Final Word

We believe that openness builds trust. By being transparent by default, and responsible by design, we strive to set a high standard for security transparency in open-source software - empowering our community while protecting what matters most.

Any exceptions to the aforementioned definitions should be approved by the Head of Security and/or the CTO.