Vulnerability disclosure program (VDP) starter kit

This is practical guidance, not legal advice. Check the legal references against the official text of Regulation (EU) 2024/2847 before you rely on them, and involve counsel for anything that touches liability.

Why you need this, in three sentences

The CRA expects every manufacturer of a product with digital elements to have a way for outsiders to report security flaws, and a process inside the company for acting on what they report. This is the vulnerability-handling side of the regulation (Annex I, Part II), and it is separate from the incident-reporting clocks that start on 11 September 2026. A VDP is the front door: without it, a researcher who finds a flaw in your product has nowhere to send it, and the first you hear of the problem may be when it is already being exploited.

You do not need a bug-bounty budget or a security team to satisfy this. You need a published policy, a monitored contact address, and a written procedure for what happens when a report arrives. That is what this kit gives you.

What a VDP actually is

A vulnerability disclosure program is a public promise and a private process. The public promise tells researchers where to send a report, what you will do with it, and that you will not take legal action against someone who reports in good faith. That safe-harbour part matters more than it looks: researchers avoid companies that might sue them, so it is what makes the front door usable.

The private process is who reads the reports, how fast you respond, how you decide whether a report is real and how serious it is, and how you coordinate a fix and a disclosure with the person who found it. A VDP is not a bug bounty. A bounty pays for findings and attracts volume you may not be ready for. Start with a VDP; add a bounty later only if you want one.

Part A: the public disclosure policy (template)

Publish this at a stable URL, for example yourcompany.example/security. Replace every bracketed field. Keep it short: researchers reward pages they can read in a minute.

Security vulnerability disclosure policy

[COMPANY NAME] takes the security of [PRODUCT NAME(S)] seriously. If you have
found a security vulnerability in one of our products, we want to hear from you.

How to report
Email [security@yourcompany.example] with a description of the issue. If you can,
include the affected product and version, the steps to reproduce it, and what an
attacker could do with it.

What we promise
We will acknowledge your report within [3] business days. We will share our
assessment, including whether we consider it a valid vulnerability, within [10]
business days. We will keep you updated while we work on a fix, and tell you when
it ships.

Safe harbour
If you make a good-faith effort to follow this policy, we will not pursue or
support legal action against you for your research. Good faith means you do not
access more data than you need to demonstrate the problem, you do not degrade our
service for other users, you do not exploit the issue beyond a proof of concept,
and you give us reasonable time to fix it before telling anyone else.

Coordinated disclosure
Please keep the details private until we have released a fix or agreed a date with
you. Our default coordination window is [90] days from the day you report.

Out of scope
[List anything you do not want reports on. Keep it short and honest.]

Thanks
With your permission, we will credit you when we publish the fix.

Last updated: [DATE].

Part B: security.txt (template)

security.txt tells researchers and automated tools where to report. Put it at exactly this path so it can be found: https://yourcompany.example/.well-known/security.txt. It takes 20 minutes and is the cheapest credibility signal you can publish.

Contact: mailto:security@yourcompany.example
Policy: https://yourcompany.example/security
Preferred-Languages: en
Expires: [DATE ~12 MONTHS FROM NOW, ISO 8601, e.g. 2027-07-27T00:00:00.000Z]

The Expires date must be in the future, or scanners treat the file as stale, so set a yearly reminder to renew it. If you offer a PGP key, add an Encryption line pointing to it.

Part C: the internal handling procedure

This is what happens after a report lands in the inbox, and it is the half most teams skip. Write down who does each step by name, not by role, because the security team is nobody when you are small. If one person holds every role, say so, and name a backup.

Step 1: someone reads the inbox

The security address must reach a human every working day. Route it to a shared mailbox or a ticket, not one person's private email, so a report does not sit unread while someone is away.

Step 2: acknowledge within your promised window

Reply within the time your policy promised. A short human reply is fine: you received it, you are looking, you will come back with an assessment by a date. Silence is how you lose a researcher's goodwill and push them toward publishing early.

Step 3: triage, which means answer two questions

First, is it real? Reproduce it, or ask the reporter for the steps you need. A report you cannot reproduce is not yet a vulnerability; keep talking rather than closing it. Second, how bad is it? Ask what an attacker can actually do, how hard it is, and how many users are exposed. A rough band (critical, high, medium, low) is enough to start; CVSS is the common scale if you want one later.

Triage is also where a vulnerability can become a reporting obligation. If the flaw is being actively exploited in the wild, the CRA reporting clock (see the reporting playbook) may start, and that clock is measured in hours, not business days. Know the difference before you are in it.

Step 4: fix, and decide who else needs to know

Build the fix. While you do, decide two things. Do your users need a warning or a workaround before the fix is ready? And does this meet the CRA reporting threshold? If it does, the reporting timeline runs in parallel with your engineering work; you cannot wait for the fix before you start reporting.

Step 5: release, disclose, and credit

Ship the fix. Tell the reporter. Credit them if you agreed to. If the issue was serious, publish a short advisory so users know to update, and remember the CRA expects you to inform affected users of the vulnerability and any mitigations, where appropriate in a machine-readable format.

Step 6: write down what happened

Keep a one-line record of every report: when it came in, who handled it, what you decided, when it closed. This log is your evidence that the VDP works, and the CRA expects you to show your process, not just describe it. A spreadsheet is fine.

The mistakes that cause trouble

• The report address goes to one person who then changes jobs, and the mailbox dies with them. Route it to something shared.
• The out-of-scope list is a page long and reads as a way to avoid fixing things. Keep it short and honest.
• Nobody wrote down the internal procedure, so when a report arrives, three people argue about who owns it while the clock runs.
• The team treats a VDP report and a CRA reporting obligation as the same thing. They are not: one is a business-day courtesy, the other is a legal duty on a 24-hour clock.

Your 90-minute setup checklist

• Create or route a monitored security address that reaches a human every working day.
• Fill in and publish the disclosure policy at a stable URL.
• Publish security.txt at /.well-known/security.txt with a future Expires date and a renewal reminder.
• Name the person and the backup for reading the inbox, triaging, and coordinating.
• Start the one-line report log.
• Read the reporting playbook so you know when a vulnerability becomes a reporting obligation.
• Have your assessor or counsel sanity-check the safe-harbour wording and the legal references before you rely on them.