A Vulnerability Disclosure Policy for a Ten-Person Company

Somebody finds a page on your site that returns another customer's invoice when they change a number in the address. They are not a criminal and they are not a client. They want to tell you, and the only address they can find is the general office mailbox. They send a careful email, get an automatic reply, and hear nothing for three weeks. A person holding a real finding and no channel then either gives up or posts it somewhere public. A vulnerability disclosure policy prevents that, and for a company of ten it is one page and one small file.

A disclosure policy is not a bug bounty

A bug bounty is a payment programme. It needs someone to triage reports quickly, a legal review of the terms, a way to pay people across borders, and a public scope that stays accurate as the site changes. A disclosure policy promises a route and a response, not money. The difference matters because most small companies read about bounties, decide the whole subject is out of reach, and publish nothing at all.

The NCSC's Vulnerability Disclosure Toolkit is written for exactly that situation: organisations with no process. It names three components, a contact route, a policy and a security.txt file, and points to ISO/IEC 29147:2018 as the standard behind them. All three fit in an afternoon.

The risk you are covering is not the report. It is the silence after it. A researcher who cannot find a channel has two options that cost you more than a fix: publish, or sell.

Publish the file and the page

Two artefacts for two audiences. The file is read by tools and by researchers who check it first. The page is read by a person deciding whether to trust you with a finding.

security.txt lives at /.well-known/security.txt on the domain root, served as text/plain with UTF-8. RFC 9116 requires two fields, Contact and Expires, and defines Policy, Preferred-Languages, Canonical and Encryption as optional. It recommends an expiry less than a year ahead. A minimal file looks like this:

Contact: mailto:security@yourcompany.ro

Expires: 2027-06-01T00:00:00.000Z

Policy: https://yourcompany.ro/en/security

Preferred-Languages: ro, en

Three practical notes. The address has to be one a person reads, not a shared inbox nobody owns; a report that lands in office@ and waits is the failure this article is about. The expiry date is the part everyone forgets, so put a calendar reminder next to it. And if your site redirects every path to a language prefix, check with curl that the root file still answers, because a redirect to a 404 is worse than no file.

The page is the policy in sentences: what you want, what you promise, what is out of scope. Link it from the footer as well as from the file. Most researchers will never look for security.txt; they will look for a security link near the contact page.

What to promise, and what to leave out

A promise you can keep is worth more than a complete one. Four sentences carry the useful part.

• An acknowledgement. Give a number: within three working days, for example. The NCSC's example policy uses five working days to respond and ten to triage, with a request not to chase more than once every fourteen days. Pick numbers you can hold on a bad week.
• A decision. Say that you will tell them whether you consider it a vulnerability, even when the answer is no.
• Updates while it is open. One line each time the state changes is enough.
• Credit, if they want it. Ask before naming anyone.

Then the safe-harbour sentence, which is the most important line on the page: if you report in good faith and stay inside the scope below, we will not take legal action against you or report you to the authorities for the testing you describe in your report. Write it as a promise about your own behaviour, not as a claim about the law.

Do not promise a fix deadline you cannot control or confidentiality you cannot enforce, and do not offer a reward unless you intend to pay it. The NCSC's example policy says plainly that no monetary rewards are offered. A researcher who expects money and gets a thank-you email becomes a researcher who publishes.

Scope is what gives permission an edge

Authorisation is only as wide as the sentence that grants it, and everything outside that sentence remains unauthorised access. A scope that says "our website" and nothing else is not a scope. It leaves the researcher guessing, and guessing is how someone ends up testing your payment provider.

A workable scope for a small company:

• Your public site and its API, on production, read-only.
• No modification of data, no deletion, no uploads except a harmless test file if you allow one.
• No denial of service and no high-volume automated scanning.
• No accounts that are not the researcher's own, and no attempts to reach other customers' data beyond proving that it is reachable.
• No social engineering, no phishing of staff, no physical access.
• No third-party services you use, such as the payment provider or the hosting panel; those go to the vendor.
• Anything not listed is out of scope.

The toolkit's example policy has a longer list of prohibitions; borrow its shape and cut what does not apply. If you have a staging copy, say so and say whether it is in scope: a researcher who can break a copy without touching customers will take that option. If you do not, keep production in scope but narrow and read-only.

For a specific test, such as a scheduled review by a known person, send a written authorisation with the hosts, the dates and the person's name. Do not widen the public page for one researcher, because the next person will read the same page and assume the same latitude.

Add a data rule. Ask the reporter to delete anything retrieved during testing as soon as it is no longer needed, and within a month of the fix. That is the wording the NCSC uses. Do not make a non-disclosure agreement a condition of reading the report; the toolkit advises against it, because the person is trying to get a bug fixed, not to become a supplier.

Triaging a report when nobody on the team does security

The report arrives as an email from a stranger, possibly with links and attachments. Treat it as untrusted. Do not open the links in a session where you are signed in as an administrator, and open attachments on a machine you would not mind rebuilding. A security report is a good pretext for phishing.

Then work in this order.

• Acknowledge the same day. One paragraph: received, we will look at it by Thursday, here is the reference number.
• Write it in one sheet. Date, asset, reporter, claim, state, owner, next action. Use the states the toolkit lists: new, triaged, fixed, duplicate, informative, out of scope.
• Reproduce it on a copy, or with an account you create for the purpose. If you cannot reproduce it, ask for the exact request, not for more access.
• Judge by asset, not by score. Ask what an anonymous visitor could do, whose data it reaches, and what it would cost to fix. A script injected into the admin panel and the same script on a blog archive are different problems with the same name.
• Say when. "This week" or "the next maintenance window" is a decision the reporter can plan around. No answer is not.

Two classes cover most of what you receive. The NCSC says cross-site scripting and subdomain takeover are the most frequent submissions to its reporting service. The second is often a five-minute fix: a CNAME record still pointing at a service you cancelled, which anyone can now claim.

Closing the loop with the reporter

Tell them when it is fixed, and invite them to retest. If they ask to publish, agree a date instead of refusing: the toolkit's example policy welcomes disclosure requests and asks to coordinate the release so that users hear one consistent story. If the report is real but you decide not to fix it, say so and say why. A closed report with a reason ends the thread; silence restarts it in public.

Credit is free. Ask whether they want their name, a handle, or nothing at all, and put them on a short thank-you list on the policy page if they agree. The toolkit suggests exactly this, and it is the only reward most finders of small bugs will get from you. It is also the reason they will report the next one to you rather than to a mailing list.

The Romanian part

Romanian criminal law treats unauthorised access to a computer system as an offence. The Criminal Code, Law 286/2009, has a separate chapter on offences against the safety and integrity of computer systems and data, alongside the chapters on computer fraud and on payment instruments. What matters for a disclosure policy is the idea the offence is built on: access without right, not access with bad intentions. A careful researcher who stays inside a system they were never authorised to enter is in the same legal position as a careless one.

Read that twice, because it changes what the policy is for. It is not a shield. It cannot bind a prosecutor, and publishing it does not turn an offence into a permitted act. What it does is document, in advance and in writing, which hosts you authorised and for what. If a report ever becomes a dispute, that dated page is the clearest evidence of where your consent began and ended. It also makes the honest researcher's decision easy: they can point at a page instead of guessing.

Two local details follow. A report may contain personal data, so the deletion rule is the data protection rule you would apply to any other unsolicited file. And publish the page in Romanian as well as English, with ro first in Preferred-Languages. The person who finds the bug on a Romanian site is often a student or a junior developer who will read the Romanian version more carefully.

What to ship this week

• A /.well-known/security.txt with a monitored contact address and a real expiry date.
• A security page in both languages: what you want, four promises, a scope list, the safe-harbour sentence.
• A mailbox or form that reaches one named person, with a reference number in the first reply.
• One sheet for reports, with the six states, kept where the team can see it.
• A staging copy, or a read-only production scope that says so.
• A calendar reminder to review the page and the expiry date once a year.

None of this is a security programme. It is the difference between a researcher who tells you about a bug and a researcher who tells the internet. For a small company that difference is most of the risk. If you want the wider set of habits around it, our guide to cybersecurity for small business covers the ten that matter, and when we want to see how other programmes word the same promises we look at the research index we keep at Bounty Atlas. If you would rather have someone read your draft policy before you publish it, book a free intro call.