How to Set Up a Vulnerability Disclosure Program at a Small Company

What a VDP is, and what it is not

A vulnerability disclosure program (VDP) is a public promise: "If you find a security problem in our systems, here is how to tell us, here is what we ask of you, and here is how we will treat you."

It is not a payment program, and it does not invite anyone to attack you. It simply turns an awkward, unplanned email into a process you have already thought through.

For a small company, a VDP can be a few hundred words of policy, one text file and a shared inbox. The work is in deciding the rules ahead of time.

Step 1: Publish security.txt (RFC 9116)

RFC 9116 defines a standard file that tells researchers where to send security reports. Place it at /.well-known/security.txt on your website, serve it over HTTPS, and keep it as plain text.

Two fields are required:

• Contact: where to send reports, such as a mailto link to a security inbox or a link to a web form.
• Expires: a date after which the file should be considered stale. The standard recommends setting it less than a year ahead, so put a renewal reminder on your calendar.

Useful optional fields include:

• Policy: a link to your disclosure policy.
• Encryption: a link to a public key, if you want encrypted reports.
• Acknowledgments: a link to a page thanking researchers.
• Preferred-Languages and Canonical: the languages you read and the official URL of the file.

An expired or abandoned security.txt is worse than none, because it tells researchers no one is paying attention.

Step 2: Write a short disclosure policy

Your policy should be readable in a few minutes. Cover:

1. Scope: which domains, apps or services are covered. Be specific.
2. Out of scope: third-party services you do not control, and test types you do not allow.
3. Rules of engagement: for example, no denial-of-service testing, no social engineering of staff, no physical access attempts, access or change only the minimum data needed to show the problem, and stop and report if personal data is exposed.
4. How to report: where to send it and what to include (affected URL or system, steps to reproduce, potential impact).
5. What you commit to: acknowledging reports, keeping the researcher informed and not taking legal action against good-faith research that follows the policy.
6. Disclosure timing: ask researchers to give you reasonable time to fix an issue before publishing, and say you will coordinate with them.

CISA publishes a vulnerability disclosure policy template for federal agencies that is a helpful model, even though your situation is simpler. You can find it at cisa.gov.

Safe harbor language: the idea

Safe harbor wording tells researchers that if they act in good faith and follow your rules, you will treat their work as authorized and will not pursue legal action against them for it. Without it, careful researchers may decide reporting to you is not worth the risk.

A simple version of the idea: "If you make a good-faith effort to follow this policy, we will consider your research authorized, we will work with you to understand and resolve the issue, and we will not initiate legal action against you related to that research."

Treat that as a starting point for discussion, not finished language. Safe harbor wording has legal consequences, and only your own attorney can tell you what fits your business and contracts.

Step 3: Set up intake

• Use a shared address such as security@yourcompany, not one person's mailbox. Reports should not disappear when someone is on vacation.
• Make sure at least two people see incoming reports.
• Turn on spam filtering carefully. Real reports sometimes look odd.
• Track each report somewhere simple: a ticket, a spreadsheet row, a shared folder. Record the date received, who owns it and its status.
• Prepare an acknowledgment template so the first reply goes out quickly.

Step 4: Triage, with example timelines

Triage means confirming whether a report is real, how serious it is and who needs to fix it. Decide your timelines based on what your team can actually keep. Some examples a small company might choose:

• Acknowledge receipt within 3 business days.
• Share an initial assessment within 10 business days.
• Send status updates at least every 30 days until resolved.

These are illustrations, not standards. Publishing a short timeline you cannot meet damages trust faster than publishing a modest one you consistently beat.

For severity, a simple high, medium, low scale is fine. Focus on what an attacker could actually do: read customer data, take over accounts, change records, or something minor.

Step 5: Legal and insurance review

Before publishing, have your attorney review the policy and safe harbor wording. It is also worth telling your cyber insurer you are launching a VDP, since some policies have notice requirements for security incidents. If a report reveals that personal data was exposed, you may have notification duties, and that is a question for counsel. This guide is not legal advice.

VDP vs bug bounty

A VDP gives researchers a safe way to report issues. It usually offers thanks or public acknowledgment, not money.

A bug bounty pays for valid findings. It tends to attract many more reports, including low-quality ones, and requires staff time to sort through them.

Most small companies should start with a VDP. Consider a bounty later, once you can handle the volume and have budget set aside.

What happens when a researcher emails you

1. Acknowledge. Thank them and confirm you received the report. Do not argue or threaten.
2. Do not publicly deny it. Investigate first.
3. Reproduce. Have someone qualified confirm the issue in a safe way.
4. Assess severity and assign an owner to fix it.
5. Keep the researcher updated, even if the update is "still working on it."
6. Fix and confirm. Ask the researcher if they can confirm the fix, if appropriate.
7. Close out. Thank them, offer acknowledgment if they want it, and agree on any disclosure timing.

If a report includes a demand for payment in exchange for not publishing, that is not a normal disclosure. Stop and talk to your attorney.

How Keith Systems helps

Jacob Keith reports vulnerabilities through coordinated disclosure, including HackerOne (@cratitoes) and the Microsoft Security Response Center (MSRC), so he has seen this process from the researcher's side. Keith Systems helps small companies draft security.txt, a plain-language policy for attorney review, intake routing and a triage process. See vulnerability disclosure program setup, or book a free security consult. You can also call (805) 800-8163.