How to Write a Vulnerability Disclosure Policy: A Step-by-Step Checklist

A vulnerability disclosure policy is a short published statement. It tells anyone who finds a security flaw in your systems how to report it, plus what you need from their report and what they can expect back from you. Writing one costs nothing, and publishing it takes an afternoon. What it closes off is one of the most avoidable ways a security problem turns into a public embarrassment: a researcher who couldn’t work out how to tell you quietly, so didn’t.

Below is a working checklist for building one properly, plus what’s changed legally in the UK over the past couple of years that makes this less optional than it used to be.

Step one: settle what belongs in your vulnerability disclosure policy

The UK’s National Cyber Security Centre maintains a Vulnerability Disclosure Toolkit for organisations starting from scratch. It narrows the essentials down to five points. Cover these and you have a vulnerability disclosure policy that works:

• Contact method. One clear route in. A monitored inbox is the minimum; a secure web form is better if reports might carry sensitive detail.
• Secure communication option. A way to send anything genuinely sensitive without it sitting unencrypted in an inbox.
• What a report should contain. Steps to reproduce, affected systems, and any supporting evidence, so triage doesn’t stall on back-and-forth questions.
• What the finder should expect. A rough timeline for acknowledgement and, ideally, for resolution.
• Scope. Which systems are fair game, which are off limits, and what kind of testing crosses a line, such as anything risking disruption to live services.

Notably, the NCSC’s guidance also tells you what to leave out. Don’t demand a signed non-disclosure agreement before you’ll even look at a report. Most people reporting a flaw are acting in good faith. Meeting that with legal paperwork tends to do more harm to the relationship than good.

Step two: check whether a vulnerability disclosure policy is mandatory for you

Some businesses no longer get a choice. If you make or sell internet-connected consumer products, this stopped being optional on 29 April 2024. That’s when the UK’s product security law came into force, under the Product Security and Telecommunications Infrastructure Act. Makers must now post clear details of how to report a flaw, without anyone having to ask for them. They must also say roughly how long a fix will take. A watchdog called the Office for Product Safety and Standards enforces this. Fines for serious breaches can reach into the millions.

Outside that specific regime, there’s no general legal mandate in the UK yet. But an international standard already covers this ground. ISO/IEC 29147 sets out how vendors should structure the process. It’s also increasingly what auditors, cyber insurers and enterprise customers expect to see referenced when they check your security posture during due diligence.

Step three: understand what this isn’t

Two mix-ups come up constantly, so settle both before you publish anything.

It isn’t a bug bounty programme. A vulnerability disclosure policy is a free reporting channel with no payment attached. A bug bounty adds financial rewards on top, typically run through a platform with payout tiers by severity. Get the policy and the internal triage process working first. Jumping straight to paid bounties without that groundwork tends to produce more noise than signal.

It isn’t a penetration test. A policy is reactive: you publish it and see who gets in touch. Your coverage depends entirely on who happens to be looking, and when. A scoped penetration test is proactive. A tester actively hunts for weaknesses across an agreed scope and testing window, found or not by anyone outside. The two work well together rather than as alternatives: an opportunistic channel alongside deliberate coverage from a firm that does this for a living.

Step four: publish your vulnerability disclosure policy somewhere researchers will find it

A policy buried three clicks deep in a legal terms page doesn’t get found. Two things fix that. First, put it on an obvious page, ideally linked from your footer or a security page. Second, add a security.txt file to your website. This is a plain text file at a fixed web address, set out in a standard called RFC 9116. It points both people and automated tools straight to your policy. The US Cybersecurity and Infrastructure Security Agency backs it as a small step with a real payoff.

Step five: work out who handles a report once it arrives

Publishing your vulnerability disclosure policy is the easy half. Decide before the first report lands, not after, who actually triages it. The NCSC’s guidance is direct here: acknowledge reports promptly, thank the finder, and send periodic updates rather than going silent while a fix is in progress. If a fix is going to take weeks, saying so is usually enough to keep a patient reporter patient.

In a small business this might land on whoever already owns IT or security, wearing another hat for the day. In a larger one it typically sits with the incident response function. Confirming a report is genuine, routing it to whoever can fix it, and closing the loop with the reporter all draw on skills that function already has.

Step six: know where you stand legally

Testing a system without permission can be a crime under the Computer Misuse Act. That’s why some firms are wary of inviting outside researchers in at all. A clearly published scope fixes most of that worry. By stating what’s allowed, and how, you’re giving standing permission within those limits. You also get a clear way to tell a good-faith reporter apart from someone acting to cause harm.

A vulnerability disclosure policy only handles the reports that come to you unprompted. If you’d rather find out where the weaknesses are before a stranger does, a scoped penetration test does that systematically. Aardwolf Security’s testers can talk through what a sensible scope looks like for your systems. Get in touch if that’s worth a conversation.

Frequently asked questions

Is a vulnerability disclosure policy legally required in the UK?

Only for manufacturers of consumer connectable products, under the product security regime in force since April 2024. Everyone else can treat it as voluntary, though it’s increasingly expected during supplier and insurer due diligence.

Does a vulnerability disclosure policy cost anything to set up?

Not really. A monitored contact address, a scope statement and a stated response time cover the basics. None of that requires a budget beyond the time to write it.

How is this different from a bug bounty programme?

A vulnerability disclosure policy carries no payment obligation; it’s purely a reporting channel. A bug bounty programme adds financial rewards for qualifying reports on top of that same channel.

Can we rely on this instead of a penetration test?

No. A policy only surfaces whatever a passer-by happens to find and chooses to report. A commissioned test actively searches an agreed scope for weaknesses, whether or not anyone else would have found them.

How quickly do we need to respond to a report?

There’s no fixed legal deadline outside the product security regime’s own rules. But the NCSC’s guidance is clear that long silences are what push a reporter toward going public. A quick initial acknowledgement, followed by periodic updates if a fix takes time, is the safer path.

Who inside the business should handle incoming reports?

Whoever already owns incident response is usually the natural fit. In a small business that might just be one person covering security alongside other duties. The task is the same either way: confirm the report is genuine, route it to whoever can fix it, and keep the finder updated until it’s closed.