# A coordinated vulnerability disclosure policy: what it must contain (with a template) Canonical: https://craguard.eu/blog/coordinated-vulnerability-disclosure-policy-template Language: en Last updated: 2026-09-02 - [CRAguard](https://craguard.eu/)/ - [Blog](https://craguard.eu/blog)/ - A coordinated vulnerability disclosure policy: what it must contain (with a template) 22 Aug 2026 · CRAguard Summary Annex I Part II of Regulation (EU) 2024/2847 requires a coordinated vulnerability disclosure (CVD) policy. It's a short public page that tells a reporter where to write, what to expect from you, and within what timeframes. We walk through the eight points it consists of, including a \"safe harbour\" statement and time to fix — as a skeleton to adapt, not as legal text. Once you have a [reporting channel and security.txt](https://craguard.eu/blog/security-txt-and-vulnerability-channel), 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: - **Scope.** Which products and services the policy covers (and what it does not). - **Contact and method.** Where and how to report (security@ email, a form), and what information to include (version, reproduction steps, impact). - **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. - **Your timeframes.** An indicative time to assess and remediate — and that it depends on severity. No need to promise the impossible, just be predictable. - **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. - **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. - **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. - **Recognition (optional).** Whether and how you'll credit the reporter in an advisory or acknowledgement. Scope-checker ### Find out whether the CRA applies to you Six questions, two minutes, no account. Get your product class and first steps. [Start the scope-checker](https://craguard.eu/checker) ## 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: - **Day 0 — a report arrives** at `security@` or via the form. The reporter described the problem and the version. - **Within 3 working days — acknowledgement.** You reply that you have the report and are starting to assess it (exactly what the policy promises). - **Assessment.** You verify whether it applies, how severe it is and which versions it affects — the finding gets an "assessed" status. - **Fix.** You ship a fixed version; with the reporter you agree when it may be disclosed. - **Advisory.** Once the fix is available you publish an [advisory](https://craguard.eu/blog/security-advisories-when-and-how) 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](https://craguard.eu/blog/security-advisories-when-and-how). ## FAQ - **Must a CVD policy be long?** Quite the opposite — short and readable. A long document nobody reads deters as much as none. - **Do we need a bug bounty?** No. A CVD policy isn't a reward programme; rewards are a separate, optional matter. - **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. - **Where to publish the policy?** On a public page that the `Policy:` field in [security.txt](https://craguard.eu/blog/security-txt-and-vulnerability-channel) 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](https://craguard.eu/checker), or [join the waitlist](https://craguard.eu/#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).* Scope-checker ### Find out whether the CRA applies to you Six questions, two minutes, no account. Get your product class and first steps. [Start the scope-checker](https://craguard.eu/checker) ## Sources - [EUR-Lex — Regulation (EU) 2024/2847 (Cyber Resilience Act)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) - [ENISA — Single Reporting Platform](https://www.enisa.europa.eu/) --- Source: CRAguard — https://craguard.eu