Provetry
FRDEGet early access
Free check
Get early access

Provetry opens in November 2026. The free CRA check, the tools and the guides are available now.

Writing a coordinated vulnerability disclosure policy

8 min read

On this page
  1. Why the CRA requires one
  2. What the policy should say
  3. Publishing it
  4. Living with it
  5. How Provetry helps
  6. Sources

Sooner or later someone outside your company will find a vulnerability in your product: a security researcher, a customer’s security team, a student. A coordinated vulnerability disclosure (CVD) policy tells them how to report it, what you will do, and when the details may be made public. It turns a potentially hostile surprise into a cooperation with a known outcome.

Why the CRA requires one

Annex I, Part II, point 5 of the Cyber Resilience Act asks every manufacturer to put in place and enforce a policy on coordinated vulnerability disclosure, and to provide a contact address for reports. The policy must be in place when the product is placed on the market and for its whole support period. Open-source software stewards must also have a cybersecurity policy that encourages vulnerability reporting.

The CRA works together with the NIS2 Directive here: each Member State has a CSIRT that acts as coordinator for disclosure, and can mediate between a reporter and a manufacturer who do not agree. Your policy should be compatible with that.

What the policy should say

The international reference is ISO/IEC 29147 (vulnerability disclosure), with ISO/IEC 30111 for the internal handling process. In practice, a good policy fits on one page and covers:

Scope

Which products, versions and services the policy covers, and what is out of scope (for example, physical attacks on your offices, social engineering of staff, denial-of-service testing against production).

How to report

The address (a security@ mailbox or a form), an encryption key if you offer one, the languages you read, and what a useful report contains: affected product and version, steps to reproduce, impact, and how to contact the reporter.

What you commit to

Concrete timelines build trust:

  • an acknowledgement within a few working days;
  • a first assessment (confirmed or not, severity) within a couple of weeks;
  • regular updates until the fix;
  • the publication of an advisory once a fix is available, crediting the reporter if they wish.

Coordination and publication

When the details may become public. Many organisations use 90 days from the report as a default deadline, extended by agreement when a fix needs longer, and shortened when the vulnerability is already being exploited. The CRA also requires you to publish information about fixed vulnerabilities once a security update is available, with a possible delay in duly justified cases until users have been able to apply it.

Safe harbour

Whether you commit not to take legal action against people who research in good faith and respect the policy: no data exfiltration beyond what is needed to show the issue, no harm to users, prompt reporting, confidentiality until publication. This is a legal commitment, so have it reviewed by your lawyer, and remember that it cannot bind third parties or the authorities.

Rewards

Whether you offer a bug bounty or only thanks. Say it clearly; a policy without a bounty is perfectly normal for a small company.

Exploited vulnerabilities

What happens when a report shows active exploitation. Under the CRA, that can start your 24-hour reporting clock, so the people reading the security mailbox must know when to escalate.

Publishing it

  • Put it at a stable address on your website, such as /security/disclosure-policy.
  • Point to it from your security.txt file with the Policy field.
  • Link it from the product documentation and the support pages.
  • Keep it in your technical documentation as evidence for the CRA, with the date of each version.

Living with it

A policy is only useful if the process behind it works:

  1. Route the security mailbox to at least two people, with an automatic acknowledgement.
  2. Keep a log of each report: date received, status, decisions, publication.
  3. Link each confirmed vulnerability to the affected releases, the fix and the advisory.
  4. Review the policy once a year, and when your products or team change.

You can draft a first version with our free disclosure policy generator, in English, French or German.

How Provetry helps

On paid plans, Provetry writes your disclosure policy and security.txt from your answers, lists your products and their support periods in it, has a certified security expert review the draft, and publishes your advisories in CSAF once fixes are out. Each version of the policy is recorded in your evidence journal.

This guide is general information, not legal advice.

Sources