CVD policy: what belongs in it
The coordinated vulnerability disclosure (CVD) policy tells reporters what they can expect and what you expect from them. The Policy field in your security.txt points to it. BSI TR-03183-3 sets out its minimum content in section 4.4.
Why a policy?
Anyone who finds a flaw wants to know whether reporting it is safe: whether they risk a complaint, whether anyone will reply and when the flaw becomes public. A clear policy answers this up front. It lowers the barrier for a proper report and helps prevent flaws from being published unannounced.
Under the TR the policy is mandatory (4.4, 4.5.2) and needs its own web page, reachable without JavaScript and without login (4.5.2); the security.txt points to it in the Policy field (4.2.7). For manufacturers under the Cyber Resilience Act (CRA), from 11 December 2027 the regulation requires a coordinated vulnerability disclosure policy (Annex I, Part II, point 5).
Checklist under TR-03183-3 section 4.4
| Content | Level | TR |
|---|---|---|
| Date of last change visible, policy clearly attributable to the manufacturer, reviewed yearly | Required | 4.4.1 |
| Notify the national CSIRT without undue delay for actively exploited vulnerabilities (in Germany CERT-Bund) | Required | 4.4.2 |
| PSIRT and CSIRT role mailboxes with keys and fingerprints | Required | 4.4.3 |
| Confidentiality, no disclosure of personal data without consent, no criminal charges if the policy is followed, no NDA, response within the committed times, availability throughout the process, recommendation of encrypted and signed e-mail | Required | 4.4.4 |
| Listing in a hall of fame on request | Recommended | 4.4.4 f |
| What counts as a valid vulnerability | Required | 4.4.5 |
| Code of conduct for reporters and consequences of non-compliance; reports are still handled | optional (if published: handling despite non-compliance required) | 4.4.6 |
| Accept e-mail and phone as reporters' contact; no report closed by a single analyst | Required | 4.4.7 |
| Personal reply within 5 working days, detailed feedback within 10 working days | Required | 4.4.8 |
| Easy-to-find anonymous reporting option with a note on limited processing | Required | 4.4.9 |
| Publication of confirmed vulnerabilities within 90 days, at least in ENISA's EUVD | Required | 4.4.10 |
| Conditions for closing the process | Required | 4.4.11 |
The TR also recommends a reward programme (bug bounty). Since March 2026 you can state in your security.txt whether you offer one, using the Bug-Bounty field. If you do not offer one, say so explicitly in the policy; it is the simplest measure against beg bounty emails.
The draft from the generator
Below the generator you can create a draft as a Markdown file with all required items of the checklist and your addresses and keys from the form, in English or German. Open items are in square brackets: manufacturer name, scope, fingerprints, competent national CSIRT, privacy policy address and a note on civil action; if addresses or keys are missing from the form, these too.
The draft is a starting point, not legal advice. Check every commitment for whether you can keep it during holidays and with a deputy, and clarify open questions, such as waiving civil action, with your legal counsel. Our own policy shows what a finished one looks like: security-txt.eu/security-policy/.
Where the policy belongs
- On its own page of your website, for example
/security-policy, readable without login and without JavaScript (TR 4.5.2). - Linked from your reporting page and in the
Policyfield of your security.txt. - In a language users and market surveillance authorities understand (TR 4.1.1 c); an English version is advisable, as the TR requires you to accept reports in English (4.3.1 n) and to offer the reporting form in English (4.3.3 d).
Sources
- BSI TR-03183-3 Vulnerability Reports and Notifications, version 1.0.0, 20 August 2025, sections 4.4 and 4.5.
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I, Part II.
- IANA registry: security.txt Fields.