Responsibility before estimation

Make the work visible.
Give it an owner.

A managed program reduces the need for your team to administer every raw submission. It still needs decisions and technical action from the people who know your systems. Validation, risk treatment and fixing software are different tasks, even when they concern the same report.

This matrix is a planning aid. Confirm the exact allocation, coverage and handoff for your engagement. In a small business, one person may hold more than one customer role.

Activity
Your decision owner
Your technical team
Hackrate, as agreed
Objectives and scope
Name the owner, confirm asset authority and approve boundaries and budget.
Identify environments, dependencies, exclusions and known limitations.
Help shape the operating model and agree included management activities.
Preparation and access
Approve policy, reporting rules, contacts and escalation expectations.
Provide appropriate accounts, documentation and a safe validation route.
Coordinate the agreed program setup and report-handling workflow.
Report clarification
Resolve ownership questions and supply business impact context.
Answer product-specific questions and provide relevant evidence or access.
Review scope and evidence, request clarification and validate within authorization.
Risk and reward decisions
Decide risk treatment and, for bounty programs, approve eligible rewards.
Explain affected components, practical impact and remediation options.
Provide assessment and coordinate communication under the program rules.
Remediation and verification
Assign priorities and owners, approve changes and track unresolved risk.
Implement fixes and provide the information needed for agreed verification.
Hand off validated findings and verify remediation where included and agreed.
Program review
Review effort, open decisions and whether the model still fits.
Review fix progress, repeated causes and access or workflow problems.
Review report handling and agree operational improvements with your team.

An external development or IT provider can fill a technical role if it has the required authority, access and capacity. Your organization retains its decisions and risk ownership.

Choose the right operating model

Similar handoffs.
Different preparation.

Managed bug bounty and managed VDP both need people who can act on a valid report. Their starting rules and activity patterns differ.

Managed bug bounty

Authorize research against defined assets. Agree private or public participation, access, testing restrictions and reward eligibility. Approve a reward pool separately from management or platform fees.

During operation, your team may need to answer access questions, add business context to a finding, approve rewards and prioritize fixes. Broader participation or a larger scope can change the workload, so review both against engineering capacity.

Explore managed bug bounty

Managed VDP

Establish a reporting policy, channel and process for incoming disclosures. Agree how submissions are assessed, how reporters receive clarification and how relevant findings reach your team.

A VDP does not automatically include active testing or bounty rewards. Your team still needs to explain product behavior, make risk decisions and arrange fixes. Effort depends on what is reported, rather than an assumed level of research activity.

Explore managed VDP

What changes the effort?

Scope and context matter
more than a headline number.

Use these factors to make an estimate meaningful during scoping, then compare the assumptions with actual activity after launch.

01

Access and ownership

Authenticated workflows, multiple asset owners and third-party dependencies can create preparation and clarification work. A usable test environment and named owners make the handoff clearer.

02

Report activity

Volume, completeness and demonstrated impact affect handling. Managed validation helps separate submissions from actionable findings; it cannot remove every need for customer context.

03

Remediation complexity

A configuration change and an architectural fix have different engineering costs. Plan remediation capacity separately from report administration, including change approval and verification.

ILLUSTRATIVE EXAMPLE / ROUTINE INVOLVEMENT

A report needs product context before a decision.

A researcher describes an account-access issue. Hackrate reviews the evidence within the agreed scope and asks whether two account roles should see the same resource. Your technical owner explains the intended permission model. The decision owner then uses the validated finding and business context to prioritize treatment. Engineers schedule the change, and any agreed verification follows.

The customer effort comes from the question, decision and fix. Counting a report alone would not describe that workload.

Routine work and urgent exceptions

Have a route for
the important interruption.

Routine reviews suit ordinary coordination. A potentially critical report needs a defined escalation path that can reach people authorized to act.

See the report validation process

Agree before the first report

  • The customer contact and backup for urgent escalation.
  • The agreed service coverage, contact channels and escalation triggers.
  • Who can investigate impact, authorize containment and coordinate changes.
  • How vulnerability handling connects to your incident response process.
  • How decisions and follow-up stay recorded with the report.

Managed reporting support does not automatically include round-the-clock incident response. Confirm availability and coverage in your engagement.

Prepare a useful scoping conversation.

Bring your asset list, likely technical owners, access requirements, existing disclosure channel and engineering workflow. Identify known constraints and current remediation capacity. We can then discuss which tasks need support and where your team must stay involved.

See how preparation fits into the first month

Frequently asked questions

The details worth agreeing.

Use these answers to prepare the conversation about your own scope and responsibilities.

Can you give us a fixed number of customer hours?

A credible estimate needs your scope, access requirements, ownership structure and existing workflows. Report activity and the complexity of any necessary fixes also affect the effort. Start with a task and responsibility map, then review actual involvement after launch. This guide does not promise a fixed number of hours.

Does every report go directly to our engineers?

In an agreed managed workflow, Hackrate can review incoming submissions, request clarification and validate findings before the engineering handoff. Some reports still need your product context during validation. Confirm the handoff rules and escalation exceptions for your engagement so important questions do not wait for a routine review.

Who should be our main contact?

Choose someone who can coordinate decisions across the relevant assets and technical owners. This may be a security lead, CTO, engineering lead or IT owner. Give them a technical counterpart and an escalation backup. A contact who cannot approve scope or reach a remediation owner will not resolve the practical ownership gap.

Is managed VDP less work than bug bounty?

The workflows differ, so compare tasks rather than assuming a fixed effort reduction. A VDP establishes a reporting policy and handles incoming disclosures; bug bounty also needs active research authorization and reward rules. Both need customer context, risk decisions and remediation when relevant findings arrive. A small number of serious disclosures can still require substantial engineering work.

Do we need to be available around the clock?

Agree service coverage, customer contact availability, backups and escalation expectations explicitly. A managed program does not by itself establish a round-the-clock incident response service. Your organization should decide how an urgent finding received outside normal working hours reaches the appropriate decision-maker.

Can we change scope if the workload grows?

Discuss changes through the program's agreed process. Options can include narrowing future authorized testing, changing invitation strategy or improving the handoff. Changes should be communicated clearly and do not remove responsibility for reports already received or known vulnerabilities. Review engineering capacity alongside new research activity.

PLAN YOUR NEXT STEP

Practical guides. Clearer decisions.

Explore the people, preparation and choices behind a working researcher program.

Expert explanations

Expert Answers from Levente Molnár

Hackrate CTO Levente Molnár explains bug bounty and managed VDP decisions: team workload, researcher selection, critical reports and getting started.

Read the guide
Small-team readiness

Bug Bounty Without an Internal Security Team

Run a managed bug bounty without a dedicated security team. Understand customer ownership, engineering readiness, validation support and VDP alternatives.

Read the guide
Getting started

Your First Month with Hackrate

Explore an illustrative first month of managed bug bounty or VDP: objectives, scope, preparation, launch readiness, report handling and program review.

Read the guide

A practical next step

Build a realistic picture of your workload.

Bring your asset scope, team structure and current reporting process. We can map responsibilities and discuss where managed support would be useful.

Request a demo Explore managed bug bounty
Hackrate

Our platform helps companies to identify software vulnerabilities in a cost-efficient way. It provides a secure and centralized view of ethical hacking projects for your company.

US Patent Applied for HackGATE #63/645,845

Hackrate Status
Company
Products
From the Blog
Hackrate is ISO 27001 certified

Hackrate Ethical Hacking Platform |
2026 ©

CVE Program Numbering Authority