NIS2 Bug Bounty Programmes: The One Clause They Evidence, and the Two Duties They Don’t

The word “bounty” does not appear in the NIS2 Directive. It does not appear in Commission Implementing Regulation (EU) 2024/2690 either. It appears exactly once in ENISA’s 170-page Technical Implementation Guidance, inside a bracketed list of nine things you might consider [3].

So the useful question is not whether NIS2 requires a bug bounty programme. It doesn’t, and every vendor blog on the subject has already told you that. The useful question is what a bounty actually proves when a supervisory authority asks for evidence, and which duties it quietly leaves open while you assume it covered them. This guide is written for entities that have already decided to run one. If you are still writing the underlying policy, start with our guide to writing a NIS2 vulnerability disclosure policy instead.

Where a Bug Bounty Sits in the NIS2 Stack

In plain terms: a bug bounty is a way of buying security testing from strangers, and NIS2 treats it as one testing option among many. It is never the foundation of anything — it sits on top of a disclosure policy you have to write regardless.

The obligation everything hangs from is Article 21(2)(e), which requires measures covering “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” [1]. That single limb is implemented by two separate chapters of the CIR 2024/2690 Annex: point 6.5, security testing, and point 6.10, vulnerability handling [2]. A bounty is a testing method that generates handling work. It is scored under 6.5 and creates obligations under 6.10 — which is why treating it as a single compliance line item is where most programmes go wrong. For the wider picture, see our complete guide to Article 21.

The EU’s own vocabulary makes the hierarchy explicit. The NIS Cooperation Group’s 2023 guidelines define a reward programme as “an optional element of a CVD policy which can offer different types of rewards for submitting a valid vulnerability report, such as a vulnerability reward programme — also known as a ‘bug bounty’ — or a recognition/gift programme” [4]. Optional element. Of a policy. Not a substitute for one.

If your entity is…	The binding text is…	What that means for your bounty
One of the 11 provider types named in Article 21(5) — DNS providers, TLD registries, cloud, data centres, CDNs, MSPs, MSSPs, online marketplaces, search engines, social platforms, trust service providers	The CIR 2024/2690 Annex, directly	Points 6.5.2 and 6.10.2 are the exact clauses your evidence will be read against
Any other essential or important entity	Your Member State’s transposition of Article 21	The CIR Annex does not bind you, but it is the most detailed published statement of what Article 21(2)(e) means — auditors and supervisors use it as the benchmark anyway

The Four-Limb Test Every Bounty Has to Pass

Run your programme against CIR point 6.5.2 before you run it against anything else. It is the only clause a bug bounty can directly evidence, and it has four limbs — a bounty is strong on two of them and structurally weak on the other two.

Note what the binding text does not do: point 6.5.2 names no test type at all. Pen testing, red teaming and bug bounties appear only in ENISA’s guidance layer, which states of itself that it “is not legally binding and is only recommendations” and that entities “may choose alternative methods to fulfil a requirement” [3]. The choice of method is yours. The four limbs are not.

Limb of 6.5.2	What it demands	How a bug bounty scores	How to close the gap
(a)	Establish the need, scope, frequency and type of tests, based on the risk assessment	Partial. A bounty is continuous and inbound — it has no “frequency” in the sense the clause assumes	Document the cadence you do control: programme review and scope refresh. Record the risk-assessment reasoning that led you to crowdsource testing for these specific assets
(b)	Test according to a documented methodology, “covering the components identified as relevant for secure operation in a risk analysis”	Weakest. Researchers choose what they look at. You cannot guarantee coverage of the components your own risk analysis flagged	Keep a coverage map: risk-relevant components down one axis, valid submissions received in the period down the other. Commission a scheduled test for whatever the crowd never touched
(c)	Document type, scope, time and results, including criticality and mitigating actions per finding	Strongest. Platforms generate exactly this natively	Export it into your own records. Evidence that lives only inside a vendor portal is evidence you can lose at contract termination
(d)	Apply mitigating actions in case of critical findings	Strong — but this is your remediation pipeline, not the researcher’s	Point 6.10.2(c) sets the standard: critical vulnerabilities are addressed “without undue delay”

Limb (b) is the one that decides whether your programme is testing or theatre. ENISA reinforces it twice in the same guidance block: results must be documented “in a manner that is comprehensible to an expert third party”, and “entity-wide scoped tests should be carried out at planned intervals” [3]. A bounty cannot be entity-wide-scoped on a schedule — which is the sourced argument for pairing it with commissioned penetration testing rather than replacing that testing with it.

The Two Duties a Bounty Does Not Discharge

Both sit in point 6.10, and both are routinely assumed to be covered by an active programme. They aren’t.

First, point 6.10.2(e): entities shall “lay down a procedure for disclosing vulnerabilities in accordance with the applicable national coordinated vulnerability disclosure policy” [2]. That is a published policy and a documented process — the thing the reward is attached to. Paying for bugs does not write it. Our vulnerability and patch management guide covers the handling side that sits behind it.

Second, point 6.10.2(b): entities shall “perform, where appropriate, vulnerability scans, and record evidence of the results of the scans, at planned intervals” [2]. Inbound submissions are not scans, and unpredictable arrival is not a planned interval.

There is a sharper signal underneath both. ENISA’s guidance to point 6.10.2 lists ten examples of evidence: logs for critical vulnerabilities, scanner licences, scanner configuration files, vulnerability-management tool logs, scan reports, SIEM and EDR/XDR logs, third-party assessment or penetration test reports, proof that critical findings were addressed, records of disclosures made under the national CVD policy, and an interview with the supplier point of contact [3]. Not one of them is an inbound report from an external finder. The evidence model behind the CIR is scanner-and-vendor shaped, and your platform export has to be filed into it deliberately, because nothing in the framework will recognise it by default. Point 6.10.4 gives you the filing cabinet: entities must review the channels they use for monitoring vulnerability information at planned intervals, and ENISA’s guidance adds that the information those channels produce should be reviewed at least biannually [3]. Your programme belongs on that channel list.

Then there is Article 12 — the provision this topic is usually filed under, and the one that imposes nothing on you at all. Article 12(1) obliges each Member State to designate a CSIRT as CVD coordinator, and to “ensure that natural or legal persons are able to report, anonymously where they so request, a vulnerability” to it, with the coordinator required to preserve that anonymity [1]. The practical consequence for programme design: a researcher can bypass your platform entirely and take your vulnerability to the national CSIRT, and your programme terms have no purchase on that route. The five-agency joint guidance published on 15 July 2026 by CISA, NSA, JPCERT/CC, NCSC-NL and NCSC-UK makes the same point from the other side, warning entities to check that their platform’s policies avoid “prohibiting CVD through mechanisms like an NDA” [5]. Terms that try to buy silence are drafting against a statutory channel.

Your Bug Bounty Platform Is a Supplier Under Article 21(2)(d)

This is the compliance consequence nobody in the bounty market mentions: the moment you engage HackerOne, Intigriti, Bugcrowd, YesWeHack or any managed alternative, you have taken on an ICT service provider — and Article 21(2)(d) plus CIR point 5.1.4 govern that relationship [1][2]. The platform also holds something unusually sensitive: a live register of your unremediated vulnerabilities, complete with working proof-of-concept exploits.

CIR 5.1.4 contract limb	What to write into a bounty platform contract
(d) Incident notification without undue delay	Covers a compromise of the platform itself — where your unpatched-vulnerability register lives
(e) Right to audit or to receive audit reports	Triager competence and vetting, plus segregation of your submission data
(f) Obligation to handle vulnerabilities affecting you	Applies to flaws in the platform itself, not just the ones reported through it
(g) Subcontracting requirements	Managed triage is frequently subcontracted; the NIS Cooperation Group also advises informing subcontractors of your CVD policy and adapting contracts accordingly [4]
(h) Retrieval and disposal of information at termination	The clause that matters most here — exploit code and open findings must come back, and must not persist on the platform

One further platform rule comes straight from the NIS Cooperation Group: “If a vulnerability rewards programme is introduced via a bug bounty platform, the full content of the CVD policy must also be included on that platform” [4]. A short scope blurb on a vendor page is not the policy. Our supply chain security guide covers the wider selection and contracting duties.

The Triage SLA That Is Not a Compliance Clock

The joint guidance recommends acknowledging a researcher “within a specified time frame, such as two to three business days”, and keeping disclosure and triage off your customer support channels [5]. Sensible programme hygiene — and slower than NIS2’s own clocks, which start earlier than most triage runbooks assume.

NIS2’s own clocks reach you through your Member State’s transposition, and both start earlier than most triage runbooks assume. Article 23(4)(a) sets an early warning within 24 hours “of becoming aware of the significant incident”, and Article 21(4) covers an entity that “finds that it does not comply” with its Article 21(2) measures, which must then take corrective measures without undue delay [1]. Neither clock waits for validation. A submission is not automatically an incident — most are findings, not compromises — but a report containing evidence of active exploitation can be the moment of becoming aware, and whether it is turns on the facts and on national guidance. That is precisely why it should be a documented decision with a named owner rather than an improvisation at 6pm on a Friday.

In practice: put a reportability gate before the acknowledgement SLA in the runbook. First reader asks one question — does this describe something that has already happened, or something that could? — and escalates on the first answer. See our incident reporting guide for what follows if the answer is the former.

Reward Terms: Where the Line Sits Between a Report and Extortion

Publish the reward table before you receive the first report. The NIS Cooperation Group is unusually blunt about why: “It is essential that the responsible vendor or system owner clearly states the nature of this reward in advance in its policy. Any request for a reward outside the conditions set by the CVD policy can then be equated with an illegal attempt at extortion” [4]. Your published terms are what separates a security report from a demand — which makes them a legal instrument, not a marketing page.

Money is also not the only option on the table. The same guidelines describe three reward types: a financial vulnerability reward programme, a recognition programme — of which they note that “no notable resources or budget are needed” — and a gift programme [4]. For a smaller entity with an Article 21 budget already under strain, a recognition-only programme delivers most of the 6.5.2 and 6.10.2(e) benefit at close to zero cost, and removes the payment, tax and sanctions-screening overhead that comes with paying strangers across borders. One further caution from the same source: a CVD policy “constitutes a form of accession agreement that binds the researcher”, so the parties’ data-protection obligations have to be specified in writing.

Settle the third-party question in the policy too, because researchers testing your estate will find flaws in components you merely licensed. The Dutch NCSC’s own model CVD policy answers it in one line: “Should you find a vulnerability in third party software that we use and that vulnerability is covered by a bug bounty program, we will not try to claim this bounty; you should” [7]. Adopting that position costs nothing, avoids a fight over a reward you did not fund, and keeps the finding moving toward the vendor who can actually patch it.

A NIS2-Ready Bug Bounty Checklist

1. [Compliance] Publish the CVD policy first; attach the reward schedule to it, not the reverse (6.10.2(e)).
2. [Compliance] Reproduce the full policy text on the platform, not a summary (NIS Cooperation Group).
3. [CISO] Record the risk-assessment reasoning for choosing crowdsourced testing on these assets (6.5.2(a)).
4. [CISO] Maintain a coverage map of risk-relevant components against valid submissions received (6.5.2(b)).
5. [CISO] Keep scheduled scanning and commissioned testing running alongside the programme (6.10.2(b)).
6. [CISO] Export platform findings into your own records each period, in a form an expert third party can follow (6.5.2(c)).
7. [Compliance] Add the programme to your vulnerability-monitoring channel list and its review cycle (6.10.4).
8. [Legal] Put the platform through supplier contracting, with the 5.1.4(d) to (h) limbs written in.
9. [Legal] Draft safe-harbour language with counsel for your jurisdiction, and remove any term that blocks reporting to the national CSIRT.
10. [Board] Set the reportability gate and name its owner before launch, not after the first serious submission.

Frequently Asked Questions

Does running a bug bounty satisfy the NIS2 security-testing requirement on its own?
No. Point 6.5.2 requires testing that covers the components your risk analysis identified as relevant, according to a documented methodology. A programme where external researchers choose the targets cannot demonstrate that coverage by itself. It evidences limbs (c) and (d) well; limbs (a) and (b) need something scheduled alongside it.

Do we have to register bug bounty findings in the European vulnerability database?
No. Article 12(2) tasks ENISA with maintaining the database and describes registration by entities as being “on a voluntary basis”, open to organisations “regardless of whether they fall within the scope of this Directive” [1]. The EUVD went live on 13 May 2025 [6]. Voluntary registration is most relevant if the vulnerability is in a product or service you supply to others.

Are researchers legally protected if they test our systems?
Not by NIS2 itself. Recital 60 encourages Member States to adopt guidelines on non-prosecution of security researchers and civil liability exemptions, but a recital is a non-binding interpretive aid, and protection therefore depends on national law [1]. The joint agency guidance publishes sample safe-harbour wording as a starting point and recommends developing it with legal counsel for your jurisdiction [5].

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. Directive (EU) 2022/2555 (NIS2) — EUR-Lex. Articles 12, 21 and 23.
2. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex. Annex points 5.1.4, 6.5, 6.10 and 12.4.
3. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 (June 2025) — ENISA. Non-binding guidance.
4. Guidelines on Implementing National Coordinated Vulnerability Disclosure Policies (2023) — NIS Cooperation Group.
5. Establishing a Coordinated Vulnerability Disclosure Program to Work With Security Researchers (15 July 2026) — joint guidance from CISA, NSA, JPCERT/CC, NCSC-NL and NCSC-UK, published at cisa.gov. Not linked here because the host blocks automated requests; search the exact title to retrieve the PDF.
6. Vulnerability Disclosure and the European Vulnerability Database — ENISA.
7. Coordinated Vulnerability Disclosure: the Guideline — Nationaal Cyber Security Centrum (NCSC-NL), including its model CVD policy text.