How to Write a Responsible Disclosure Email in English

Responsible disclosure means privately reporting a security vulnerability to the affected organisation and giving them reasonable time to fix it before any public discussion. Unlike a bug bounty submission through a formal platform, a responsible disclosure email to a company with no established process requires you to establish trust, explain your intent, and set expectations — all in your first message, often to someone who has never received a report like this before.

Opening the Email

Your first paragraph needs to do three things: identify yourself, explain what you found, and make clear your intentions are good faith.

• “My name is [Name], and I’m a security researcher. While reviewing your public-facing application, I identified a vulnerability that I believe puts user data at risk. I’m reaching out privately, before any public disclosure, to give your team the opportunity to address it.”
• “I’m writing to report a security issue I discovered in [product/service]. I have not shared these details publicly and don’t intend to until we’ve agreed on a reasonable disclosure timeline.”
• “I want to be upfront: I’m not looking for compensation. I found this issue while using your product and want to make sure it gets fixed before it’s exploited.”

Describing the Vulnerability Clearly

• “The vulnerability allows an unauthenticated attacker to access another user’s account settings by modifying a single parameter in the request URL.”
• “I’ve kept technical detail to a minimum in this initial email for safety, but I’m happy to provide a full proof of concept and reproduction steps once we have a secure channel to communicate.”
• “This affects the production environment at [domain], specifically the /api/v1/profile endpoint.”

Proposing a Disclosure Timeline

• “Industry-standard practice is typically 90 days from initial report to public disclosure — I’m happy to extend that if your team needs more time and communicates progress along the way.”
• “I’d like to propose the following timeline: an acknowledgment within 5 business days, a status update within 30 days, and disclosure coordinated once a fix is deployed or after 90 days, whichever comes first.”
• “If there’s already a security contact or disclosure policy I should have used instead, please point me to it and I’ll follow that process going forward.”

Handling a Slow or No Response

• “I’m following up on my message from two weeks ago regarding a security vulnerability in [product]. I haven’t received a response yet — could someone confirm this has been received?”
• “This is my third attempt to reach your security team through this channel. If there’s a better contact for vulnerability reports, I’d appreciate being redirected.”
• “Given the lack of response after 45 days, I want to be transparent that I’m considering escalating through [CERT/CC or a similar coordinating body] to ensure this reaches the right team.”

Professional Tips

1. Never threaten public disclosure as leverage in the first message. State your intended timeline calmly and factually — framing it as a threat damages trust and can escalate the situation unnecessarily.
2. Offer a secure channel for full technical details. PGP encryption or a dedicated disclosure form protects both you and the vulnerability details from being intercepted in transit.
3. Document every message and timestamp. If the process becomes contentious later, a clear paper trail of good-faith, timely communication protects your credibility.
4. Avoid legal-sounding language unless you mean it. Phrases like “I reserve all rights” can read as adversarial even when not intended that way — keep the tone collaborative unless the situation genuinely requires otherwise.

Handling Pushback or Denial

• “I understand this may not match your team’s initial assessment, but I’d be glad to walk through the reproduction steps together on a call to clarify any misunderstanding.”
• “I want to make sure we’re evaluating the same scenario — to confirm, the impact I’m describing occurs when [specific condition], not under normal expected usage.”
• “If your team’s position is that this isn’t a valid finding, I’d appreciate understanding the reasoning so I can decide how to proceed responsibly.”

Practice Exercise

1. Write the opening two sentences of a responsible disclosure email for a vulnerability you found in a company’s password reset flow.
2. Draft a polite follow-up email for a report that has received no response after three weeks.
3. Write one sentence proposing a 90-day disclosure timeline, including what happens if the company needs more time.

Related Resources

• How to Write a Bug Bounty Report in English
• How to Communicate a Data Breach to Customers in English
• Security Architecture Vocabulary

Expanding Your Vocabulary: Crafting Clarity for International Teams

Writing a responsible disclosure email isn’t just about stating the problem; it’s about communicating effectively – and that includes ensuring your message is clear, precise, and resonates with colleagues who may be developing their professional English skills. For non-native speakers, particularly those new to the nuances of technical writing and workplace communication, the subtleties can feel overwhelming. Let’s look at some common areas where expanded vocabulary and phrasing can make a significant difference.

One frequent hurdle is using precise verbs. Instead of simply saying “I found a vulnerability,” consider alternatives like “I identified an exploitable weakness” or “I observed a potential security flaw.” These phrases demonstrate a more formal understanding of the issue and avoid potentially ambiguous language. Similarly, when describing the impact, moving beyond “it’s bad” is crucial. Replace it with “this could lead to unauthorized data access,” “the system is susceptible to [specific attack type],” or “a successful exploit could result in significant service disruption.” These phrases immediately convey the severity and potential consequences, demonstrating a deeper level of technical understanding valued by most teams.

Furthermore, pay attention to sentence structure. Long, convoluted sentences are easily misinterpreted. Aim for shorter, clearer statements. For example, instead of: “Due to the fact that there is an unauthenticated access vector present in the application’s user authentication module, it’s necessary to implement immediate mitigation strategies,” try: “An unauthenticated access vector exists within the user authentication module requiring immediate mitigation.” This revised sentence is more direct and easier to understand. It’s also worth noting the importance of consistent terminology; using the same terms throughout your email will reduce confusion.

Finally, remember that professional emails often benefit from a slightly more formal tone than casual Slack conversations. Phrases like “I respectfully submit” or “I would appreciate your prompt attention to this matter” are perfectly acceptable and demonstrate professionalism. Consider how you’d phrase something in a code review comment – aiming for clarity and constructive criticism is key, just as it is with vulnerability reporting. The goal isn’t simply to report the issue; it’s to facilitate a collaborative resolution.