How do we set up vulnerability handling and a way for outside researchers to report to us?

Start

An outsider may find a flaw and need somewhere to report it

Vulnerability handling inside the company is well covered by the usual triage. This question is about the door from outside: where a researcher, a customer or a supplier sends a report, who reads it, and how it joins your normal process. NIS2 names vulnerability handling and disclosure as part of one of its ten measures. The Directive does not itself require a published policy.

• Then: Do outsiders have a published, monitored way to report a flaw?

Decision

Do outsiders have a published, monitored way to report a flaw?

A published way means an address or form that anyone can find, such as a security contact page and a security.txt file (a small standard file, RFC 9116, that lists contacts and your policy). Monitored means someone reads it every working day. If it exists but nobody reads it, answer no.

• Yes: Has Legal agreed the wording on how you treat good-faith reporters?
• No, or not known: Decide what reports you welcome and what is out of bounds

Step

Decide what reports you welcome and what is out of bounds

List the systems in scope and the kinds of testing you accept. Say what is out: attacks on staff, denial of service, reading or changing other people's data beyond what proves the flaw. Have someone senior agree the scope, because it decides what outsiders may try on your systems.

• Then: Has Legal agreed the wording on how you treat good-faith reporters?

Decision

Has Legal agreed the wording on how you treat good-faith reporters?

Researchers look for a clear promise not to pursue those who follow your rules. What you can promise depends on law that varies by country, and on your contracts with customers and hosts. A promise that Legal has not agreed is worse than none, because you may not be able to keep it.

• Yes: Publish the contact, the rules and what a reporter can expect
• No, or not known: Agree the wording with Legal before you publish

Step

Agree the wording with Legal before you publish

Ask Legal for wording that fits the law where you operate and does not promise more than you can honour. Keep it short and plain. Do not copy another company's safe harbour text without checking it against your own position.

• Then: Publish the contact, the rules and what a reporter can expect

Decision

Has Legal agreed the wording on how you treat good-faith reporters?

Your route already exists. Check that what it says to good-faith reporters is still wording Legal has agreed. What you can promise depends on law that varies by country, and on your contracts with customers and hosts. A promise that Legal has not agreed is worse than none.

• Yes: Does the contact reach a named owner, with a deputy?
• No, or not known: Agree the wording with Legal and update the published page

Step

Agree the wording with Legal and update the published page

Ask Legal for wording that fits the law where you operate and does not promise more than you can honour. Change the published page to match. Do not leave older wording live.

• Then: Does the contact reach a named owner, with a deputy?

Step

Publish the contact, the rules and what a reporter can expect

Put the contact and the rules where people look: a security page and the security.txt file. Say what the reporter will get back, such as an acknowledgement and updates, and whether you credit reporters. Do not state response times that your team cannot meet; choose figures you can keep.

• Then: Does the contact reach a named owner, with a deputy?

Decision

Does the contact reach a named owner, with a deputy?

Reports arrive on any day. The pack's incident routes say every report passes on at once, and that reports from customers and the public land at the service desk, passed on by whoever received them. Name an owner and a deputy for the vulnerability inbox, and make the mailbox a shared one so a holiday does not leave it unread.

• Yes: Acknowledge the report and say what happens next
• No, or not known: Name an owner and a deputy and route the mailbox to them

Step

Name an owner and a deputy and route the mailbox to them

Choose people who can judge a report and reach the system owners. Agree who may reply on behalf of the company: outside the company, only the communications lead speaks about an incident, from approved text, so route any press or public contact there.

• Then: Acknowledge the report and say what happens next

Step

Acknowledge the report and say what happens next

Thank the reporter and say you are looking at it. Do not say whether there is an incident and do not promise a fix date yet. Keep the thread in one place so the facts are in one record.

• Then: Is it a real vulnerability in something we run?

Decision

Is it a real vulnerability in something we run?

Reproduce it before you decide. Many reports are scanner output with no proof of impact, or concern something you do not own. Say so politely. If you cannot tell whether it is real, treat it as real until someone who can judge says otherwise.

• Yes, or not known: Is the flaw in a third party's product or service we use?
• No: Reply with your reasons and close the report

Step

Reply with your reasons and close the report

Explain why it is not a vulnerability in your systems, or who owns the affected system. Keep the report and the answer, so that a repeat report is quick to deal with.

• Then: Confirm the fix, thank the reporter and record the outcome

Decision

Is the flaw in a third party's product or service we use?

If a supplier's product is affected, the supplier has to fix it, and you and the reporter may have to wait. Tell the reporter you are passing it on and ask for their consent before you share their details.

• Yes: Pass it to the vendor and protect yourself meanwhile
• No: Enter it as a finding and rate it like any other

Step

Pass it to the vendor and protect yourself meanwhile

Use the vendor's own disclosure route. Where there is none or it does not respond, each Member State has a national security team that can act as a go-between for reporter and vendor, if either asks. Meanwhile reduce your exposure with a setting, a block or an isolation, and record it.

• Then: Is there any sign it has already been used against us?

Step

Enter it as a finding and rate it like any other

Put it into the normal vulnerability process, with the date of the report as the date of detection, or the vendor's release date of a fix if that is earlier. Priority follows the usual rules: an exploited flaw on an internet-facing or Critical system, or public exploit code (or not known) for a High or Critical flaw on an internet-facing system, is the top priority and treated as a potential incident.

• Then: Is there any sign it has already been used against us?

Decision

Is there any sign it has already been used against us?

Look in your logs for the behaviour the reporter described. If you cannot tell, take the cautious answer and look harder. A researcher's report can be the first sign of an attacker who found the same thing.

• Yes, or not known: Declare an incident and take it through the incident route
• No: Fix or mitigate by the deadline and keep the reporter informed

Outcome

Declare an incident and take it through the incident route

Use the incident route to contain, investigate and decide on any reporting duty. Keep the reporter informed only as far as the communications lead allows. The vulnerability fix continues in parallel: once the incident route allows, go back to fixing the flaw and closing the report.

Step

Fix or mitigate by the deadline and keep the reporter informed

Work to the deadline for the priority, with a compensating control if the fix cannot arrive in time. Tell the reporter when it is fixed. If the deadline is missed, use the exception route and tell the reporter the new date.

• Then: Do we make or sell products with digital elements?

Decision

Do we make or sell products with digital elements?

A separate EU law, the Cyber Resilience Act, sets duties for makers of products with digital elements. Its reporting duty in Article 14 has applied since 11 September 2026: a maker must notify an actively exploited vulnerability in its product, and a severe incident affecting the product's security, with an early warning within 24 hours of becoming aware. Most of the rest, including the duty to handle vulnerabilities, applies from 11 December 2027. It is not part of NIS2 and needs its own advice.

• Yes: Check your product duties with counsel
• No: Confirm the fix, thank the reporter and record the outcome

Step

Check your product duties with counsel

If you are the manufacturer, ask counsel what the Cyber Resilience Act requires of you and from when. Since 11 September 2026 a maker must report an actively exploited vulnerability in its product to the designated CSIRT and ENISA, as well as fix it. This flow does not cover those duties.

• Then: Confirm the fix, thank the reporter and record the outcome

Step

Confirm the fix, thank the reporter and record the outcome

If there was a fix, check it by testing the same way the reporter did, then tell them. If the report was not valid, make sure the reply has gone out. Agree whether you credit them or publish an advisory. Record the report, the decision and the dates for the file.

• Then: Review reports and response times at planned intervals

Step

Review reports and response times at planned intervals

Look at how many reports came in, how fast you answered, which were valid and where the process slowed. Update the scope, the contact and the owner when people change. Keep the policy page and security.txt current, since stale contact details defeat the purpose.

• Then: Outsiders can report; each report becomes a finding or an answer

Outcome

Outsiders can report; each report becomes a finding or an answer

Keep the policy, the owner list and a log of reports with their outcomes. Do not state that you pay rewards, offer legal protection beyond what Legal agreed, or have no vulnerabilities. Say what you do.