CVD, Bug Bounty and Penetration Testing Are Not the Same Thing

Coordinated Vulnerability Disclosure is primarily about moving vulnerability information from discovery to the right parties, remediation and, where appropriate, public disclosure without increasing risk unnecessarily.

Article 12 of NIS2 requires each Member State to designate a CSIRT as its CVD coordinator. The coordinator acts as a trusted intermediary where needed, helps identify and contact affected entities, assists reporters, negotiates disclosure timelines and manages vulnerabilities affecting multiple entities.1

ISO/IEC 29147 similarly addresses receiving vulnerability reports, disclosure of remediation information, policy considerations and coordination.2

None of this makes CVD a particular exploitation technique.

A report can enter CVD after accidental discovery. A researcher may have identified a vulnerability before a coordinator became involved. One vulnerability may require multi-vendor coordination. A coordinator may be necessary precisely because the reporter cannot identify the correct owner.

CVD is the coordination layer.

A Vulnerability Disclosure Policy or Programme tells external researchers how an organisation wants vulnerability reports to be handled.

A mature VDP commonly covers:

• in-scope assets;
• reporting channels;
• permitted and prohibited testing;
• report content;
• expected response process;
• disclosure expectations;
• commitments made to researchers acting within the policy.

HackerOne's own distinction between a VDP and a bug bounty programme describes the VDP as the organisation's guidance for external finders and identifies scope, process, evaluation expectations and safe-harbour language as common components.3

A VDP is therefore not identical to CVD.

VDP is an organisation-level policy. CVD is a coordination process.

A VDP can participate in a wider CVD ecosystem. CVD can also function when the affected vendor has no mature public policy at all.

Latvia provides a concrete example: CERT.LV operates the national CVD platform while individual resource owners can create programme-specific scopes, requirements and restrictions on top of that coordination layer.4

A bug bounty typically uses many of the same building blocks as a VDP:

• scope;
• programme rules;
• submission channel;
• triage;
• impact or severity assessment;
• disclosure rules.

The distinguishing feature is the incentive structure: qualifying findings may receive monetary rewards.

That can change researcher participation and programme operations substantially.

It does not expand authority automatically.

A EUR 5,000 bounty for a critical vulnerability does not permit a researcher to cross scope, disrupt production or access real customer data simply to demonstrate greater impact.

The bounty table says what may be rewarded.

The scope and rules say what may be done.

Latvia's CERT.LV platform makes the distinction unusually explicit. Its 2026 terms state that monetary rewards are not part of the CVD process by default; a resource owner may include a Bug Bounty in its own programme, in which case reward eligibility applies only to reports handled under that programme.4

CVD and bug bounty can therefore overlap without being synonymous.

A penetration test has a different relationship model.

The organisation deliberately commissions testing. Before execution, the parties establish what may be tested, when testing may occur, what techniques are permitted, what needs escalation, who the contacts are and what deliverables are expected.

NIST SP 800-115 defines Rules of Engagement as detailed constraints and guidance established before the security test, giving the test team authority to perform the defined activities without seeking additional permission for every individual action.5

That creates a different starting point from independent research.

A penetration-testing engagement may expressly authorise:

• authenticated testing;
• privilege-escalation attempts;
• exploitation to a defined proof point;
• testing with multiple controlled identities;
• network pivoting inside a specified environment;
• limited social engineering where explicitly included.

The existence of a contract does not make the authority unlimited.

The Rules of Engagement are both permission and boundary.

Latvia is useful here because its current cybersecurity rules visibly separate these models.

Cabinet Regulation No. 397 regulates ielaušanās testi — penetration tests — and security scanning for entities within the National Cybersecurity Law framework. The Regulation defines who may conduct certain tests and adds specific requirements for ICT critical infrastructure.6

Those requirements should not be silently generalised to every independent security-research situation.

For example, the Regulation's 48-hour advance notice requirement in paragraph 138 applies to a specifically defined security-scanning arrangement involving ICT critical infrastructure. It is not a universal rule requiring every independent researcher to notify every website owner 48 hours before testing.6

Terminology matters because mixing categories creates false legal conclusions.

Red teams use many penetration-testing techniques, but the objective is different.

A conventional penetration test usually seeks reasonably systematic coverage of an agreed technical scope and reports the weaknesses found.

A red-team exercise is more likely to begin with an adversarial objective:

Can a controlled attacker achieve a defined critical effect through a realistic attack path?

That can combine applications, infrastructure, identity, users, suppliers and social engineering — if those elements are authorised.

The 2025 TIBER-EU framework is a strong European example. It defines threat-intelligence-led red teaming as controlled, bespoke testing of live production systems that mimics the tactics, techniques and procedures of real threat actors and examines people, processes and technology supporting critical or important functions.7

Under DORA, Threat-Led Penetration Testing is a regulated advanced-testing regime for designated financial entities, with separate requirements for scope and tester suitability.8

A bug bounty is not TLPT.

A pentest is not automatically a red team.

A red-team label does not create unlimited scope.

This is an operational comparison, not a legal classification formula.

Actual authority depends on applicable law, the asset, the organisation's rights over it and the specific programme or contractual terms.

A common management mistake is to launch a public bounty and treat scheduled penetration testing as redundant.

A bounty can provide something extremely valuable: many independent researchers, diverse hypotheses, a long testing window and incentives for unusual findings.

It does not guarantee coverage.

No individual bounty researcher is necessarily responsible for:

• testing every important workflow;
• covering a defined control matrix;
• exercising every privileged role;
• verifying all previous remediation;
• documenting areas in which no severe vulnerability was found;
• giving management one consolidated conclusion about the entire scope.

A bounty researcher looks for reportable, often reward-eligible findings.

A penetration-testing team can be contractually responsible for testing areas where it finds nothing critical and documenting that coverage anyway.

A useful distinction is:

bug bounty optimises the flow of independent findings; penetration testing optimises execution of an agreed assessment scope.

A mature organisation may need both.

The reverse simplification is equally weak.

A penetration tester is not paid only for critical findings.

A professionally useful assessment may produce:

• confirmation that particular controls resisted the agreed tests;
• medium-impact weaknesses;
• configuration issues;
• segmentation problems;
• evidence that previous remediation needs retesting;
• a conclusion that selected attack hypotheses did not succeed.

Those are still legitimate engagement outcomes.

In a bounty programme, “nothing new found” is normally not a payable vulnerability.

This difference matters when an organisation needs evidence of control coverage rather than a stream of novel findings.

Consider a broken object-level authorisation flaw.

The researcher changes an identifier and attempts to access an object belonging to another account.

Under a public VDP/CVD programme, the policy may allow testing only with researcher-controlled accounts and require the test to stop as soon as cross-account access is technically demonstrated.

A bug bounty programme may use the same restriction while adding reward and duplicate-handling rules.

A penetration test may provide several customer-created identities and expressly authorise systematic horizontal and vertical access-control testing.

In a red-team exercise, the authorisation flaw may be only one step toward a predefined objective such as simulating compromise of a critical business function.

The exploit primitive is the same.

The authority envelope is not.

Safe-harbour wording can reduce uncertainty for researchers who follow a programme's rules. It is best understood here as a policy layer attached to a defined scope, not as a fourth testing model and not as portable authority over third-party systems, people or data.

The broader question of what an organisation can authorise, where criminal-law boundaries remain, and why good faith is not a substitute for permission belongs to the dedicated Good-Faith Security Research in Europe analysis.

Across CVD/VDP, bug bounty and penetration testing, scope is the control that turns a generic label into an operational arrangement. It should identify the assets and identities covered, permitted methods and intensity, third-party boundaries, data-handling rules, stop conditions and disclosure rules.

CERT.LV's 2026 platform terms require researchers to re-check programme changes before each testing iteration and to keep testing methods and intensity proportionate to the tested resource.4 That is a useful operating principle: scope is not a domain list read once.

The deeper authorisation/stop-rule question belongs to Good-Faith Security Research in Europe; unexpected personal-data exposure is treated separately in When Vulnerability Research Exposes Personal Data.

A mature security programme should not choose one of these models as the winner.

It uses them for different jobs.

CVD / VDP: a front door for unplanned discoveries

If somebody finds a vulnerability, the organisation needs a safe, owned route for the report.

This is baseline security hygiene.

Bug bounty: broader independent researcher incentives

Bounties make sense when the organisation can triage at scale, respond quickly, remediate, handle duplicates and manage disputes over scope and rewards.

Otherwise the organisation may buy a flow of reports it cannot absorb.

Penetration testing: evidence of planned coverage

When the question is “was this defined scope systematically assessed?”, a commissioned engagement has a distinct function.

Red team: evidence about protection, detection and response

Red teaming becomes useful when the question is no longer only whether a technical weakness exists, but whether a realistic attacker can achieve an objective and how the organisation detects and responds.

These are complementary layers, not competing products.

Latvia's 2026 framework makes the distinctions visible.

Sections 39 and 40 of the National Cybersecurity Law regulate coordinated vulnerability disclosure and remediation for the Law's covered entities, including reporting through the competent cyber-incident prevention institution and the remediation process.9

CERT.LV's platform terms, effective from 1 August 2026, allow resource owners to publish programme-specific testable assets, requirements and restrictions. They also allow a programme to add Bug Bounty rewards while keeping monetary rewards separate from the default CVD process.4

Cabinet Regulation No. 397 separately regulates penetration testing and security scanning for entities within its scope.6

Even inside one national framework, the layers are therefore distinct:

coordination; programme-level testing rules; optional reward; commissioned penetration testing.

Collapsing them into “ethical hacking” would remove exactly the boundaries that make the system predictable.

If an organisation cannot answer these questions, changing the programme name will not solve the problem.

The operating model needs work.

CVD, VDPs, bug bounties, penetration tests and red teams use overlapping technical skills but are not interchangeable.

CVD creates a coordination route.

A VDP tells an external researcher how the organisation wants reports and testing to be handled.

Bug bounty adds a targeted incentive structure.

Penetration testing is pre-authorised assessment work with agreed coverage and deliverables.

Red teaming simulates an adversary to examine not just technical weaknesses but protection, detection and response.

The useful question is therefore not:

“Is this ethical hacking?”

It is:

“Which operating model are we in, where does its authority end, and what permits the next action?”

Sources were checked on 25 September 2026. The five-model comparison in this article is the author's practical classification and does not create new legal categories. Terminology differs by jurisdiction and programme.

This article analyses technical, operational and legal context. It is not individual legal advice.