Skip to main content
All CollectionsResearchersSubmission management
How to write your submission's 'Impact'
How to write your submission's 'Impact'
L
Written by Lise
Updated over a year ago

The 'Impact' field in a submission serves as a comprehensive yet concise way to share the potential consequences of the identified vulnerability to the company running the bug bounty or hybrid program. It is one of the most critical components of your report. A well-defined 'Impact' field helps the triage team and program owner understand the severity of the issue, its potential ramifications, and the urgency with which it needs to be addressed.

What to Include

When filling out the 'Impact' field, it's essential to provide a clear and detailed assessment of the vulnerability's potential impact. Here are the key elements you should include:

  1. Technical Impact: Describe how the vulnerability could affect the technical aspects of the target asset. This may involve data breaches, unauthorized access, privilege escalation, or data manipulation. Be specific about the technical consequences.

  2. User Impact: Detail how the vulnerability affects end-users or customers. This could include compromised user data, loss of trust, or potential harm to individuals.

  3. (If applicable) Compliance Impact: Discuss how the vulnerability may lead to non-compliance with industry regulations or legal requirements (e.g. GDPR). Failure to meet compliance standards can result in fines and legal actions.

  4. (Optional) Business Impact: Explain how the vulnerability can impact the business operations of the organization. This could involve financial losses, reputational damage, operational disruptions, or legal consequences. Please include any evidence that supports your claims with your explanation.

Do's and Don'ts

To avoid common mistakes when filling out the 'Impact' field, consider the following do's and don'ts:

Do:

  • Be specific and detailed in your descriptions.

  • Make the most of markdown formatting.

  • Use quantifiable terms when possible (e.g., number of affected users).

  • Provide evidence or reasoning to support your assessment.

Don't:

  • Underestimate the potential impact. Take all factors into account.

  • Provide vague or overly generic descriptions.

  • Neglect to mention potential attack vectors or time sensitivity.

  • Assume that the impact is limited without proper analysis.

Did this answer your question?