Skip to main content
Safe Harbor FAQ

Organizations: Commonly answered questions about safe harbor

Updated over a week ago

Good Faith security research empowers us all to build a safer internet, and those who ethically disclose the vulnerabilities they find and the organizations that responsibly act upon their research should do so without threat of legal action or regulatory sanction.

Unfortunately, many existing anti-hacking laws are outdated and overly broad, raising the possibility that even Good Faith Security Researchers engaging in ethical vulnerability disclosure could face legal liability. Further, uncertainty exists about what exactly constitutes a reportable “data breach” under some privacy laws.

This lack of clarity in the law makes it essential that any organization engaging the hacker community makes a clear, unambiguous statement that it considers Good Faith Security Research (see definition below) to be authorized activity that is protected from legal action by them. A comprehensive statement authorizing Good Faith Security Research may also help differentiate independent validation from data breaches under many privacy laws. This type of statement is often referred to as “safe harbor.”

As the leader in Attack Resistance Management and the host of the world’s largest community of ethical hackers, HackerOne provides a Gold Standard Safe Harbor statement and believes the inclusion of a safe harbor statement is a necessary first step for any vulnerability disclosure or bug bounty program.

What is safe harbor?

A “safe harbor” is a provision that offers protection from liability in certain situations, usually when certain conditions are met. In the context of security research and vulnerability disclosure, it is a statement from an organization that hackers engaged in Good Faith Security Research and ethical disclosure are authorized to conduct such activity and will not be subject to legal action from that organization.

What is Good Faith Security Research?

HackerOne considers Good Faith Security Research to be accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services. Those engaged in Good Faith Security Research are sometimes called “bona fide” security researchers or “white hat” or “ethical” hackers.

Security research not conducted in good faith is not covered by safe harbor. For example, research conducted for the purpose of extortion is not in good faith. To the extent possible, hackers should seek to clarify the status of conduct that is borderline or they think may be inconsistent with Good Faith Security Research or unaddressed in the program's policy before engaging in such conduct. If there is a disagreement over whether or not given research is in good faith, organizations and hackers should look to common security research best practices.

As of October 25, 2022, the GSSH, including the concept of Good Faith Security Research, is aligned with recent legal and regulatory developments and current best practices represented by (among others):

Why is safe harbor fundamental to security research and vulnerability disclosure?

Safe harbor is a baseline requirement to engage with hackers in good faith. Outdated and overly-broad anti-hacking laws create uncertainty. By creating a clear statement protecting Good Faith Security Research from legal action, organizations take the first step toward engaging with the ethical hacking community.

A short, broad, easily-understood safe harbor statement provides ethical hackers with assurance and a binding commitment that they will not face legal risk merely for making valuable contributions to an organization’s security.

Safe harbor is recommended by the U.S. Department of Justice in the Framework for a Vulnerability Disclosure Program for Online Systems and the Cybersecurity and Infrastructure Security Agency (CISA) in the Vulnerability Disclosure Policy Template for U.S. government agencies, championed by legal and infosec experts industry-wide in projects like the #legalbugbounty standardization project and disclose.io, and already provided by all top-tier security programs and generally most organizations running a vulnerability disclosure program. Examples of top-tier security programs across a variety of industries providing safe harbor include the UK Ministry of Defence, General Motors, John Deere, and the United States Postal Service.

Does safe harbor help protect organizations?

Yes! In addition to the general benefits of creating a more solid foundation for ethical hackers’ engagement with you, a clear, unambiguous authorization statement may help clarify the distinction between access during Good Faith Security Research and a reportable data breach under some privacy laws. Uncertainty exists about what exactly constitutes a reportable “data breach” under some privacy laws, and many privacy laws recognize a distinction between authorized and unauthorized activity. Activity not considered authorized may contribute to a determination by regulators that a data breach occurred under relevant privacy laws.

Beyond protection from legal action, what are additional important elements of a leading-edge, gold standard safe harbor statement?

First, safe harbor should apply by default to all Good Faith Security Research ethically disclosed to an organization. Tying safe harbor to acceptance of certain terms or policies (often at the time of vulnerability submission) can lead to uncertainty about the status of Good Faith Security Research undertaken prior to the submission of a vulnerability report. Influenced by guidance from the U.S. Department of Justice and other regulators, multinational organizations, and industry partners, a leading-edge safe harbor statement should unambiguously protect Good Faith Security Research, whenever such conditions are met.

Second, whether or not a particular action is inconsistent with Good Faith Security Research should not be unilaterally determined by an organization. Good Faith Security Research is a standard that should be applied as consistently as possible, and a hacker or an organization’s initial instinct about a particular action may not accurately reflect the standard. Organizations and hackers should seek to mutually agree on whether a particular action constitutes Good Faith Security Research. If the two parties are unable to agree, they should look to best practices.

Finally, safe harbor may not be removed retroactively. Once safe harbor applies to a particular instance of Good Faith Security Research, there should not be a threat that it might be removed if there is later a disagreement between the hacker and the organization. Obviously, this does not apply if there is clear evidence of bad faith activity--though, in that case, safe harbor would not have been applicable.

Why is the standardization of safe harbor statements an important goal?

Safe harbor is a baseline requirement to engage in good faith with the security research community. Similar to how standardization of licensing (e.g., Creative Commons and various open source licenses) contributes to the vibrancy and productivity of the creative and open source communities, standardization of safe harbor statements would have a number of benefits. First, standardization would help reduce the burden on the hacker community to parse numerous different policies and would increase confidence when engaging in ethical hacking and vulnerability disclosure. Second, adherence to industry standard safe harbor signals an organization’s collaborative approach, a strong indicator of cybersecurity maturity. Third, standardization reduces the barriers to entry for both ethical hackers and organizations. In particular, the legal and policy concerns of organizations engaging in vulnerability disclosure tend to be similar and largely addressed by standard safe harbor language, reducing initial drafting and other transactional costs. Finally, adopting a ready-made gold standard ensures consistency and clarity. Historically, some safe harbor statements have been confusing, contradictory, or potentially even in conflict with laws or regulations, which could risk invalidation of the statement and loss of the expected protections.

Is the adoption of the Gold Standard Safe Harbor statement a big change?

No. The updated language reflects new guidance from regulators and industry experts on Good Faith Security Research. It represents a renewed push to further standardize safe harbor for vulnerability disclosure programs, but we also believe that many programs' practices already align with the intention of the Gold Standard Safe Harbor.

What if we don’t want to adopt the Gold Standard Safe Harbor statement?

We strongly encourage the use of the Gold Standard Safe Harbor statement, and longer-term the Gold Standard Safe Harbor will become the default. Particularly as adoption becomes widespread, hackers, your customers, and potentially even regulators will come to expect the protections and cybersecurity maturity represented by the adoption of and adherence to a gold standard safe harbor statement. Hackers in particular may choose to be biased towards programs that offer industry best practice protections, represented on HackerOne by the program level badge on program pages.

Legal Disclaimer

This does not constitute legal advice. The materials available on this website are for informational purposes only and not for the purpose of providing legal advice, and the suitability of any of the information provided or the sample Gold Standard Safe Harbor statement may vary based on your or your organization’s circumstances. In accordance with the terms of use for HackerOne Services and Platform, your organization is wholly responsible for the contents of your organization’s Program Policy.

Did this answer your question?