In order to help your program run successfully, we’ve outlined some helpful tips to guide you in managing your program according to Industry Best Practices.

Industry Best Practices are recommendations & requirements for how you can run an excellent security program with the goal of increasing positive outcomes that benefit both you and hackers. Adopting best practices is an important step in an organization’s journey toward program maturity.

Set your response targets to fall between the recommended and standard response times. The faster your response times, the higher the likelihood of hackers engaging with your program as they’ll see that you’re actively responding to reports. Consistently fast response times impact program leveling as your bug bounty program matures. Providing predictable and efficient rewards for hacker contributions (i.e.: reward upon Triage wherever possible) while engaging in consistent dialogue on reports is crucial to enabling a positive experience for both your team and hackers in the long term. If you know your organization will take a while to fix a vulnerability, avoid leaving a hacker waiting to be paid for their work and opt to award a bounty on Triage instead of leaving a hacker waiting for it to be resolved. Keep in mind that most jobs (in all industries) are paid on a weekly, bimonthly, or monthly cadence. Hacking is not an exception!

It’s best practice to actively communicate with your hackers by commenting on reports, answering any questions or concerns they have in a timely manner, and letting them know of any updates or changes to your program by using the message hackers feature. Swift responsiveness on reports where your input is required can help support engagement with the hacking community as you build a reputation for efficiency. Keep in mind that the HackerOne community is international, meaning that English is not the first language of many hackers using the platform. Cultural differences in communication exist - Assume positive intent and avoid being adversarial in interactions with hackers wherever possible.

Be transparent. If something a hacker reports is an accepted risk or a duplicate, take some time to provide detailed and verbose insight into the specifics of why, especially if a fix has been implemented internally. If a duplicate report is submitted, best practice is to link the submission to the aforementioned duplicate report. If it is a known vulnerability not within the HackerOne application, screenshots of internal tickets with timestamps are encouraged. Transparency builds trust and loyalty with the hackers on your program. It is also increasingly expected by regulators, customers, and other agencies.

Own your mistakes. If you accidentally award a hacker with a bounty for a medium severity finding rather than a low severity finding, be transparent with the hacker that you’ve made a mistake. Embrace the error and allow the hacker to keep the bounty as a bonus to build loyalty.

Set up specific bounty tables as they help hackers to see how much is rewarded based on the severity level of the vulnerability. It is important to let hackers know at the point of joining a program what they can expect as rewards for their submissions. A bounty table, paired with an incredibly specific scope will decrease the possibility of disagreement. Set your bounties to fair amounts that don’t underpay hackers and stick to your bounty table.

Make sure all helpful and important information is written on your policy and that you follow the best practices for good policies. Update your policy often - Hackers have visibility of your policy changelog. If a policy has not been updated in years, hackers may assume that your program is stale. There are a lot of other factors that can affect the success of your program such as the types of assets, the bounty amounts, response time, time to bounty, your program’s reputation, etc. Your scope should map out what you would like hackers to focus on. That being said, there may come a time when a hacker discovers a vulnerability in scope that you have not explicitly highlighted. If a hacker has provided something of value to your program, you should consider awarding in line with the impact and your bounty table to show your appreciation and encourage the hacker to continue hacking on your program. When listing things that you do and do not want hackers spending time on, be transparent about why you are requesting them to avoid testing on that particular item. For example, is it hazardous to test something? Is it owned by a different company? Is it potentially unstable under load? Being transparent with hackers about what may happen if they test on something they are requested to avoid will help hackers understand why they should be cautious while testing You can work with your Customer Success Manager (CSM) to write a fantastic program policy.

Once your policy is written out and viewable to hackers, it is vital that you honor it. If a hacker reports something that is considered in scope one day, and it is taken out shortly after, the hacker should be acknowledged and awarded accordingly. For example, if a bounty table states a number for a certain severity level, and then is changed, any reports submitted before that date should be awarded to the previous bounty table. Honor the published policy at the time of the report always.

Often, your biggest breach risks are found in areas you weren’t expecting. Obviously, you would want to learn about these risks even if they are in areas outside of your highlighted scope - to turn a blind eye to these would be ill-advised. We encourage you to consider remaining open-minded to accepting all vulnerabilities from hackers, whether or not something is considered within your specified scope. Knowledge is a powerful tool to ensure your program stays safe. BBPs are effective in narrowing down the focus to a select scope, but should never restrict. Encouraging hackers to report everything they find to your program without fear of being penalized will empower hackers to default to HackerOne as a way to disclose vulnerabilities to you over publicizing their findings via other methods such as social media.

Assess each report based on the value it brought to your organization. Pay hackers for value, including in cases where a hacker may have tested on assets you may not have highlighted, but may have provided something that has provided valuable information to your program. If a hacker makes you aware of a vulnerability that is not explicitly highlighted in your policy but being made aware of the vulnerability is helping your organization be more secure, reward the hacker for their effort and time. Reward for anything that causes you to take any form of action, or accelerate an action to remediate a vulnerability.

There are many upsides and no downsides. This is an excellent signal of your company's security maturity and will be a good look to hackers, customers, and regulators alike. As more organizations enable this -- including your competitors -- it's important to stay ahead of the curve. Program Levels improve the experience for both hackers and programs on the HackerOne platform. Levels also promote one of our most important values: transparency. Hackers have more information up-front to make participation decisions and manage their expectations, while programs can signal in advance how they will handle certain reports and situations without adding more language to their program policy. Both hackers and programs benefit from increased consistency. Program Levels are a public commitment to running a program according to these best practices, which will help increase hacker trust, especially when engaging with programs for the first time, and help us keep each other accountable. Additionally, these commitments will streamline the Mediation and Triage processes, because Program Levels clearly define how to handle these edge cases. This eliminates the back-and-forth that’s necessary to resolve rare issues. Consider volunteering to opt in and start your journey towards program maturity to Program Level 1 by contacting your assigned CSM.

Programs that engage in disclosure find themselves having higher engagement with hackers as it gives the hackers a better idea of what vulnerabilities have been found thus far. There are many reasons why a hacker may want to post about their finding, whether it’s spreading awareness of a methodology to increase tribal knowledge in the hacking community or celebrating a bounty. Giving hackers the option to request mutual disclosure also signals trust, which is crucial for the success of the bug bounty industry. Keep in mind that while HackerOne Mediation will always review recommendations submitted regarding violations of the Code of Conduct, in relation to disclosure or disclosure threats, we are not always able to prevent unauthorized disclosures from occurring