Writing a CRA coordinated vulnerability disclosure policy

Most guidance on this requirement quietly invents a list of mandatory sections. There isn't one. What there is, once you read the surrounding requirements, is a set of decisions the policy has to settle in order for the rest of Part II to be satisfiable at all.

What the regulation actually says

Three provisions of Annex I Part II bear on this, and it is worth seeing how little the first one says compared with how much weight it carries.

So: point 5 wants a policy, point 6 wants a way in, point 4 wants a way out. A policy that does not address the way in and the way out is not wrong, exactly — it is just not doing the job the other two requirements need it to do.

Note also what point 6 covers. The duty extends to vulnerabilities in third-party components contained in your product. Your policy therefore has to say something about what happens when a report concerns a dependency you did not write — which is where most reports about modern software actually land.

The two words most policies fail on

“and enforce”.

Point 5 is a two-verb requirement, and the second verb is the one with consequences. A published policy promising a response within three working days, in a company where the mailbox is checked when somebody remembers, fails point 5 — not because the policy is bad but because it is not enforced. In that situation the company would have been better off promising ten working days and meeting it.

This has a direct drafting consequence, and it is the single most useful thing on this page: every timeline you publish is a commitment you will be measured against. Write the numbers you can actually hit on a bad week, in the middle of a release, while somebody is on leave. A policy that is generous to you and honest with reporters beats an aspirational one, in both directions at once.

The seven decisions a policy has to settle

None of these is mandated by name. All of them have to be resolved for the policy to function, and each is a question a reporter or an assessor will ask.

1. Where reports go. A monitored address, and one that survives staff changes — security@ rather than a person. Point 6 requires the address; a /.well-known/security.txt file is the cheapest way to make it findable, and costs an afternoon.
2. What is in scope. Which products, which versions, and what you do about reports in third-party components. Being explicit that in-scope includes dependencies, and explaining that you will coordinate upstream, saves the argument later.
3. What you promise back, and when. Acknowledgement, triage, and a decision. Three separate commitments with three different realistic timelines.
4. How severity is assessed. Naming a scheme — CVSS, or your own documented scale — makes your remediation targets meaningful rather than rhetorical.
5. Your remediation targets by severity. These are the numbers that show up in your technical documentation and that point 2 of Part II will be assessed against.
6. The disclosure window, and who publishes. How long before you publish, whether the reporter may publish, and what happens if you disagree.
7. What you ask of the reporter, and what you will not do to them. See safe harbour below.

Choosing your timelines

The regulation gives you no numbers for any of this. Point 2 of Part II says remediate “without delay”; point 4 ties publication to update availability. Nothing states a window.

Ninety days from report to publication is the widely used convention, and there is nothing in the CRA either requiring or preferring it. What matters more than the number is that the policy is internally coherent: a ninety-day disclosure window alongside a stated target of remediating critical vulnerabilities within fourteen days is coherent; a thirty-day window alongside a ninety-day remediation target is a policy that guarantees you will breach one of your own statements.

Where your policy collides with the 24-hour clock

This is the part that is almost always missing, and it is the part that can actually hurt.

Your disclosure policy operates on a scale of days and weeks. Article 14 operates on a scale of hours, and it has applied since 11 September 2026 — more than a year before Annex I does. If a vulnerability in your product is being actively exploited, you owe an early warning to the CSIRT designated as coordinator, submitted via ENISA's platform, within 24 hours of becoming aware of it. Your ninety-day coordination window is irrelevant to that duty.

So the policy needs an internal branch that most published policies do not have: a triage question that asks whether there is evidence of exploitation in the wild, and a path that escalates immediately rather than entering the normal queue. Getting this wrong is not a drafting blemish; it is how a company misses a 24-hour statutory deadline while diligently following its own process.

Two further interactions are worth knowing:

• Coordinated disclosure can delay dissemination, but not your report. Article 16(6) allows the CSIRT that receives your notification to delay passing it to other CSIRTs where it has been made aware of a coordinated vulnerability disclosure procedure under Article 12(1) of Directive (EU) 2022/2555, for no longer than strictly necessary and until the parties consent to disclosure. That is a decision for the CSIRT, after you have reported — it is not a reason not to report.
• You cannot keep ENISA out. Article 14(7) requires the notification to be submitted via the endpoint of your coordinating CSIRT and to be simultaneously accessible to ENISA. In narrowly defined exceptional cases Article 16(2) limits what ENISA sees initially to the fact of the notification and some general information — but the decision is the CSIRT's, not yours. Our guide to reporting on ENISA's platform sets this out properly, because it is very widely misstated.

Safe harbour, and why it is not a regulatory question

Researchers will look for a statement that you will not pursue them for good-faith research conducted within your policy. The CRA does not require one, and cannot give you one — computer-misuse law is national, and a promise in your policy is a commitment by you, not immunity from anyone else.

It is still worth including, for a practical reason rather than a compliance one. Point 6 requires you to facilitate information sharing about potential vulnerabilities. A policy that reads as legally hostile discourages exactly the reports the requirement is trying to attract, and a manufacturer who receives no reports has no evidence that its point 6 measures work.

Keep the wording modest and honest: what you will not do, the conditions, and a plain acknowledgement that you cannot speak for third parties or for any authority.

The standards nobody told you about

Two ISO/IEC standards cover this ground and are the common reference points in the industry: ISO/IEC 29147 on vulnerability disclosure, and ISO/IEC 30111 on vulnerability handling processes. Between them they map almost exactly onto Part II points 4, 5 and 6.

If you want to write the policy against something, write it against the two standards' structure and cite Annex I Part II points 4, 5 and 6 for the obligations. That is the honest pairing: the regulation for what is required, the standards for how it is conventionally done.