A coordinated vulnerability disclosure policy: what it must contain (with a template)

Once you have a reporting channel and security.txt, one thing is still missing: a policy that says what happens to a report. The Cyber Resilience Act requires it in Annex I, Part II as a coordinated vulnerability disclosure (CVD) policy. It sounds grand, but it's a short public page. Let's go through what it consists of.

What a CVD policy is for

A CVD policy is an agreement between you and whoever wants to report a hole. It answers three questions for the reporter: where to send it, what happens next, and whether you'll sue them for reporting responsibly. Without one, researchers often stay silent (afraid of the reaction) or publish the vulnerability outright — which is worse for you than being told directly.

The eight building blocks

The following skeleton covers what a good CVD policy contains. Treat it as a structure of points to adapt, not as finished legal wording:

1. Scope. Which products and services the policy covers (and what it does not).
2. Contact and method. Where and how to report (security@ email, a form), and what information to include (version, reproduction steps, impact).
3. What the reporter can expect. That you'll acknowledge receipt within a defined time (e.g. 3 working days) and keep them informed of progress.
4. Your timeframes. An indicative time to assess and remediate — and that it depends on severity. No need to promise the impossible, just be predictable.
5. Coordinated disclosure. That you'll publish the vulnerability only after a fix is available (or after an agreed time), and that you'll do it together, not against each other.
6. A "safe harbour" statement. An assurance that you won't take legal action against a reporter who acts in good faith and follows the rules (doesn't exfiltrate data, doesn't disrupt operations). This is the single most important point for researchers.
7. What you expect from the reporter. Don't disclose before the fix, don't test on other people's data, don't harm availability — fair rules of the game.
8. Recognition (optional). Whether and how you'll credit the reporter in an advisory or acknowledgement.

What doesn't belong in it

Knowing what to leave out matters just as much. A CVD policy is not a place for reporters' personal data, for internal security details of your infrastructure, or for reward promises you can't keep (a bug bounty is a separate thing). And it's not a contract — it's a public, readable statement of intent. Keep it short; a long policy nobody reads deters as much as none.

Example: how a report can move through the process

So the points aren't just abstract, picture one report's journey:

1. Day 0 — a report arrives at security@ or via the form. The reporter described the problem and the version.
2. Within 3 working days — acknowledgement. You reply that you have the report and are starting to assess it (exactly what the policy promises).
3. Assessment. You verify whether it applies, how severe it is and which versions it affects — the finding gets an "assessed" status.
4. Fix. You ship a fixed version; with the reporter you agree when it may be disclosed.
5. Advisory. Once the fix is available you publish an advisory and, if agreed, credit the reporter.

The policy outwardly promises steps 2 and 5 and safe harbour; the internal procedure (who does which step) you keep to yourself. What matters is that promise and reality match — a policy you don't keep in practice is worse than a more modest one you do.

Wiring it to a process

A policy is only a promise — it earns its keep when a real procedure stands behind it. A received report should have a clear lifecycle: new → assessed → fixed → advisory published. Who does which step and within what time you set internally (one page suffices), and externally you communicate only what belongs in the policy. The last step — publishing the fixed vulnerability — is covered in the advisories article.

FAQ

1. Must a CVD policy be long? Quite the opposite — short and readable. A long document nobody reads deters as much as none.
2. Do we need a bug bounty? No. A CVD policy isn't a reward programme; rewards are a separate, optional matter.
3. Why is safe harbour so important? Without assurance they won't face legal action, many researchers stay silent or publish the hole directly — which is worse for you.
4. Where to publish the policy? On a public page that the Policy: field in security.txt links to.

Why it's worth getting right

A CVD policy is cheap insurance: an hour of work that turns a random, scared or angry report into an orderly process. It gives the researcher certainty, you predictability, and a customer a signal that you take security seriously. And since it's part of the vulnerability-handling process (Annex I Part II), you need it in the technical documentation too — so you don't write it "extra", but as part of what the CRA asks of you anyway.

Key point

A CVD policy is a short public page that tells a reporter where to write, what happens next, and that you won't sue them for a good-faith report. Annex I, Part II requires it as a coordinated vulnerability disclosure policy. A good policy covers eight points — scope, contact and method, what the reporter can expect, your indicative timelines, coordinated disclosure, a safe-harbour statement, what you expect from the reporter, and optional recognition. Safe harbour is the most important for researchers: without assurance they won't face legal action, they'd rather stay silent or disclose the hole directly. Keep the policy short and readable, and back it with a real procedure (new → triaged → fixed → advisory). Since it's part of the vulnerability-handling process, you also need it in the technical documentation — so you're not writing it "extra", but as part of what the CRA requires anyway.

How CRAguard helps

CRAguard provides a CVD policy as part of the hosted reporting channel: a public page with your policy (including the safe-harbour text and the acknowledgement time), wired to the form and to the finding's lifecycle, so from receiving a report to an advisory it's one flow with an audit trail. Find out whether the CRA applies to you, or join the waitlist.

This article is informational and not legal advice. It is based on Regulation (EU) 2024/2847 (Annex I Part II) and the European Commission's guidance of 27 July 2026. The skeleton above is a structure of points, not approved legal wording — consult a professional on the exact formulations (especially safe harbour).