An Absent Standard: Measuring Vulnerability Disclosure Intake Across the US Nonprofit Sector

At Harbor Project, we set out to find an answer to a simple question that we've been working toward solving: if a security researcher finds a vulnerability in a nonprofit's website, is there an obvious way for them to report it?

In answering this question, we examined 750 U.S. 501(c)(3) organizations, sampled across three revenue tiers. We both programmatically and manually scanned for the presence of common reporting pathways: security.txt, vulnerability disclosure policies, dedicated security contacts, and other published mechanisms for receiving vulnerability reports from users.

The result of these efforts, alarmingly enough, show that 10 of the polled organizations had published vulnerability disclosure channels: that's 1.3%.

The result was consistent across evaluated revenue tiers. We sampled 250 organizations from each of three bands by total annual revenue: large ($50 million and above), mid-sized ($5 million to $50 million), and small ($500,000 to $5 million). Six of 250 large organizations had a disclosure channel, three of 250 mid-sized organizations, and one of 250 small organizations. Of the 500 organizations below $50 million in revenue, we found no human-readable vulnerability disclosure policies at all. By human-readable we mean a page written for a person to read: a policy explaining what to report, where to send it, and what to expect in response, as opposed to a machine-readable file like security.txt that a scanner or a browser retrieves.

That is a strikingly low rate for a practice that has become an established part of security policy in other parts of the technology ecosystem.

Vulnerability disclosure: the front door

In the simplistic terms, a vulnerability disclosure program (VDP) is a way for people outside an organization to report security problems to system owners. That distinction is important. A VDP is not a sanctioned penetration test, and it is not necessarily a bug bounty program. A bug bounty pays researchers for qualifying reported vulnerabilities. A VDP can be as simple as a monitored security email address, a short policy describing how reports should be submitted, and a security.txt file pointing researchers toward that reporting pathway.

And the underlying idea that grounds things here is straightforward: organizations do not discover every security problem themselves. Regardless of revenue, tech stack, sophistication, security capabilities, or otherwise. A vulnerability, no matter how severe, will eventually bypass controls.

A security researcher (ethical hacker is often the coined term), a customer (technical, or just experiencing a hiccup in their site experience), or a curious member of the public may encounter a vulnerability before the organization does. Without a known reporting channel, that person has to determine who might receive the report. They may find a general contact form, an IT address, or in the most common case, nothing useful at all. A disclosure program removes that uncertainty. And it creates the opportunity for vulnerability mitigation before the flaw sits there for the wrong person to find.

The cost of establishing such a channel is negligible. The cost of a breach resulting from an unreported vulnerability is not. IBM's 2026 Cost of a Data Breach report puts the global average cost of a breach at $4.99 million, and the U.S. average at $11.5 million. Those figures do not necessarily establish that a VDP prevents breaches, but they provide useful context for the scale of the asymmetry between establishing a reporting mechanism and the potential consequences of an undiscovered vulnerability.

Federal vulnerability disclosure requirements reflect the same principle. The Cybersecurity and Infrastructure Security Agency (CISA) is the federal agency responsible for cybersecurity across civilian government networks. In September 2020, CISA issued Binding Operational Directive 20-01, which required every federal civilian agency to publish a vulnerability disclosure policy, with a compliance deadline of June 1, 2021. The reasoning was that members of the public would then have a defined mechanism for reporting vulnerabilities. Straightforward enough.

Of course, the nonprofit sector has no comparable requirement. Standards set by the federal government have a long history of moving outward into the broader economy without ever becoming law for the organizations that adopt them. The NIST Cybersecurity Framework was written for federal critical infrastructure and is now used voluntarily as a baseline by private companies across nearly every industry. CISA's Known Exploited Vulnerabilities catalog is binding only on federal agencies, yet private security teams treat it as a patching priority list. Our question then becomes whether vulnerability disclosure had followed the same path and become common practice on its own.

It has not.

What we found

We included two comparison populations because a number is hard to read on its own. The federal comparison is useful because it demonstrates what adoption looks like when vulnerability disclosure is treated as an organizational requirement rather than an optional practice. We found published intake at 65.9% of the federal civilian agencies in our comparison population, versus 1.3% among nonprofits.

The software-vendor comparison provides another interesting reference point. These are the companies selling donation processing, constituent management, case management, and fundraising software to nonprofits. Among 136 of them, approximately 10% had published intake.

The nonprofit rate is therefore not merely low relative to a highly regulated federal population, it is also substantially below the organizations that supply software and services to that sector.

This matters because of what nonprofits hold. Donor financial records. Client case files. Protected health information at community clinics and behavioral health providers. Immigration status at legal services organizations. In some subsectors, the physical addresses of people who are hiding from someone. The sensitivity of that data is not lower than what sits inside a federal agency or a software vendor, and in certain categories the consequences of exposure are considerably more immediate.

It is also worth noting how normal this practice has become elsewhere. Google, Microsoft, Apple, Meta, and Amazon all operate public vulnerability disclosure programs, most of them paired with paid bug bounties. So do the major payment processors, most large banks, and a substantial share of mid-market SaaS companies. Publishing a way to receive security reports is not an advanced security capability. It is a baseline expectation nearly everywhere except this sector.

We were not just looking for one file

It would be easy to interpret this as a measurement of security.txt adoption. It is not.

RFC 9116 is the published internet standard that defines security.txt: a plain text file placed at a fixed, predictable location on a website, listing where security reports should be sent. The value of a standard location is that a researcher, or an automated tool, knows exactly where to look without hunting through a site.

We checked the standardized security.txt locations defined by RFC 9116, but we also looked for human-readable disclosure policies, security reporting addresses, links to third-party coordination programs, a tab for vulnerability reporting, and other indications that an organization had deliberately established a reporting channel.

That distinction matters because an organization can have a vulnerability disclosure program without implementing the standard.

The question was not:

"Does this organization have a security.txt file?"

It was:

"Has this organization given someone outside it a clear way to report a security vulnerability?"

At 1.3%, the answer was rarely yes.

Some of the gap is technical

The data also revealed a limitation that is easy to miss when looking only at organizational behavior.

A portion of the smallest nonprofits use hosting platforms that do not provide a straightforward way to publish a file at the standardized security.txt location. Approximately one in eight organizations in the smallest revenue tier fell into this category.

The effect is not evenly distributed. The platforms imposing these constraints are often used by organizations with limited technical resources, and the same organizations least likely to have the staff or infrastructure to work around a platform limitation.

But this accounts for only part of the result.

For most organizations in the sample, there was no corresponding technical barrier to establishing a reporting address or publishing a disclosure policy. The absence of a disclosure channel therefore cannot be attributed entirely to hosting infrastructure.

The sector has simply not adopted the practice.

A sector-level gap

There is a temptation to interpret a result like this as a failure of individual organizations.

The data do not support that conclusion.

We did not test these organizations for vulnerabilities, and the presence or absence of a VDP is not a proxy for an organization's overall security posture. A nonprofit may have capable security staff, a security minded engineering team, strong controls, and a well-managed incident response process while having no public disclosure policy.

What the data does establish is narrower: public vulnerability disclosure is uncommon across the nonprofit sector.

And the size of the gap here is difficult to justify.

What closing the gap actually requires

The practical intervention is considerably smaller than the problem might suggest.

Not every nonprofit needs to launch a bug bounty program that rewards reports monetarily. They also do not need a dedicated security department.

But at minimum, they need somewhere for a researcher to send a report, someone who will see it, and enough published guidance to make clear that good-faith security research is welcome.

security.txt can make that information easier to discover.

A formal vulnerability disclosure policy can establish expectations around scope, reporting, and communication. It can also state which systems are in and out of bounds, roughly how quickly a reporter should expect to hear back, and, importantly, that the organization will not pursue legal action against someone who reports in good faith. That last commitment is often what determines whether a researcher files a report at all.

How did we actually measure this?

We constructed a sampling frame from IRS Form 990 filings and selected 750 501(c)(3) organizations across three revenue tiers. We evaluated their publicly accessible websites for security.txt, disclosure policies, security contacts, and third-party coordination mechanisms. The complete sampling methodology, detection logic, sampling frame, exclusions, comparison populations, and source data are published in the accompanying GitHub repository linked at the end of this post.

The gap is wider than the fix

Among 750 nonprofit websites in our sample, 10 had a published vulnerability disclosure channel.

That is 1.3%, against 65.9% of the federal agencies we checked and roughly 10% of the software vendors selling into the sector.

A security researcher who finds a vulnerability should not have to guess who to contact. For most organizations, giving that researcher a place to start is one of the least expensive security improvements available to them.

Most have not made it.