HACKRATE / Getting started
Your first month
with Hackrate.
Start by agreeing objectives, ownership and scope. Prepare the reporting and escalation process, launch when ready, then review what happened and what to improve. This first-month example explains the work for managed bug bounty and managed VDP; its timing depends on your readiness and agreed engagement.
From intention to a working process.
- 01 / Align objectives and owners
- 02 / Prepare policy, scope and access
- 03 / Launch when the setup is ready
- 04 / Review activity and next priorities
MANAGED BUG BOUNTY + MANAGED VDP
An illustrative first month
A sequence of decisions.
A process you can use.
The first month is a useful planning lens, not a promised delivery window. Phases can overlap, take longer or remain open while approvals and technical dependencies are resolved. Launch follows readiness and the agreed engagement.
Bug bounty and VDP share a need for ownership and report handling. The two tracks below show where active research authorization and bounty rules add work that a disclosure channel does not automatically include.
ALIGN
PHASE 01 / OBJECTIVES AND OWNERS
Agree what success should mean.
Start with the problem you want to solve: an unreliable disclosure inbox, research against a particular product or a clearer route from a report to engineering. Identify the customer decision owner, technical owners and backup contacts.
Your team
Describe goals, assets, ownership and constraints. Confirm who can authorize scope and arrange remediation, including any external technical provider.
Hackrate
Discuss the service model, management responsibilities and intended handoff. Identify information needed to scope the engagement and any open dependencies.
Discuss authorized research, private or public participation, proposed assets and who approves rewards.
Map existing disclosure routes, policy ownership and how incoming reports should reach the right people.
Planning outputA shared objective, a responsibility map and a list of decisions or information still needed.
PREPARE
PHASE 02 / POLICY, ACCESS AND WORKFLOW
Make the operating rules concrete.
Translate the agreed model into a usable setup. Define the reporting channel, handling workflow, validation boundaries and urgent escalation route. Check that the people receiving findings can reach the people who can fix them.
Your team
Approve policy and scope. Provide appropriate access, product context and contacts. Confirm technical ownership, change procedures and availability for escalation.
Hackrate
Coordinate the agreed setup and management workflow. Clarify intake, evidence review, communication and the customer handoff, including the limits of included support.
Finalize testing restrictions, accounts, participation and reward rules. Agree researcher selection and identity requirements where needed. The reward pool is separate from management or platform fees.
Prepare the disclosure policy and channel, reporter communication and escalation process. Do not present the channel as unrestricted testing permission or a bounty promise.
Planning outputAn agreed program setup, reachable owners and a readiness checklist with outstanding dependencies.
LAUNCH
PHASE 03 / BEGIN WHEN READY
Put the agreed process into operation.
Check the reporting route and escalation handoff, then activate the approved setup. A test submission can confirm routing; it should be labeled as a workflow test rather than counted as a security finding.
Your team
Confirm authorization and readiness. Keep technical and decision contacts reachable under the agreed arrangements. Respond to necessary context questions and own action on relevant findings.
Hackrate
Operate agreed intake, validation and communication. If reports arrive, assess evidence within the authorized scope and route findings or urgent questions through the defined workflow.
Enable participation under the agreed model and rules. Resolve access questions before affected activities proceed. Qualifying rewards follow program rules and customer approval.
Make the reporting policy and channel available as agreed. Handle incoming disclosures without assuming that launch itself produces research activity or valid reports.
Operational outputA functioning reporting and handling process, with any received activity, decisions and handoffs recorded.
REVIEW
PHASE 04 / LEARN AND PRIORITIZE
Review evidence, workload and next actions.
Separate what is operational from what has been tested or fixed. Review submissions if any arrived, decisions still needed, remediation progress and preparation tasks that remain open.
Your team
Review priorities, outstanding risk and technical capacity. Assign remediation owners and decisions. Confirm whether scope and the operating model still fit your goals.
Hackrate
Review the agreed handling activities and handoffs. Discuss limitations, recurring questions and process improvements. Carry out remediation verification only where agreed.
Review researcher access, participation, scope clarity and reward rules alongside any findings. Decide whether to maintain, refine or expand the program.
Review channel visibility, routing and reporter handling. A quiet inbox can still have a working process; it does not establish that the product is free of vulnerabilities.
Review outputAn agreed action list with owners, open dependencies, remediation status and next program priorities.
Before activity begins
A readiness gate,
not a calendar promise.
Agree these conditions for your engagement and resolve gaps before the affected activity starts.
- Scope and asset authority are confirmed.
- The customer owner, technical contacts and escalation backup are known.
- The reporting route and handoff have been checked.
- Required access and testing restrictions are clear.
- Service responsibilities, coverage and escalation expectations are agreed.
- For bug bounty, participation, reward rules and budget approval are in place.
- There is a practical route to remediation and agreed verification.
When the sequence changes
Handle dependencies openly.
A realistic first review can include delayed access, open decisions or no valid reports. Record what is known and choose a useful next action.
Access or approval is delayed.
Assign the dependency to an owner and adjust the sequence. Continue preparation that does not rely on it. Do not invite researchers to work around missing authorization or present an unready asset as available for testing.
When the dependency is resolved, recheck scope, permissions and any communications affected by the change.
No valid reports arrive.
Verify that the channel works and the setup is understandable. For bug bounty, also review participation and access. Avoid treating the absence of reports as proof of security or treating test submissions as discoveries.
Document operational readiness separately from research coverage, validated issues and completed remediation.
Keep the first review actionable.
Ask: What is ready? What activity did we observe? Which decisions or fixes remain open? Who owns each next step? The answers are more useful than measuring the program against an assumed number of vulnerabilities.
Read Levente's answers to buyer questionsFrequently asked questions
The details worth agreeing.
Use these answers to prepare the conversation about your own scope and responsibilities.
Will our program launch within the first month?
That depends on scope, access, customer decisions and the agreed engagement. This page is an illustrative sequence, not a delivery deadline. Define launch conditions together and use readiness checks to decide when activity can begin. Outstanding authorization or technical access should be resolved rather than bypassed to meet an example timeline.
What should we bring to the first discussion?
Bring the business objective, proposed assets, existing reporting channels, known constraints and the names of the people who can approve scope and arrange fixes. If you have a disclosure policy, reward rules or a technical provider, include those details. Missing information becomes a preparation task rather than a reason to guess.
How does onboarding differ for bug bounty and VDP?
Both need ownership, a reporting workflow and escalation rules. Bug bounty additionally needs authorized testing boundaries, a participation model and reward rules with an approved budget. A managed VDP focuses on the reporting policy, channel and handling of incoming disclosures. It does not automatically commission research or include bounty payments.
What happens if test accounts or approvals are delayed?
Record the dependency, assign an owner and adjust the launch sequence. Policy and workflow preparation may continue while access is resolved, but researchers should not be invited to perform activities that lack the necessary authorization or setup. Recheck affected scope and communications when the dependency is cleared.
Will we receive vulnerability findings in the first month?
There is no guarantee of valid findings in a specific period. A reporting-channel test checks that a submission reaches the right people; it is not evidence of a discovered vulnerability. If there are no valid reports, review operational readiness and relevant participation or access conditions without claiming the absence of vulnerabilities.
What should the first review produce?
Produce an agreed record of the operational setup, activity received, decisions made, remediation ownership and open dependencies. Keep launch readiness, report validation and completed fixes separate. Decide the next actions, responsible owners and review approach based on observed activity rather than an assumed number of discoveries.
PLAN YOUR NEXT STEP
Practical guides. Clearer decisions.
Explore the people, preparation and choices behind a working researcher program.
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 guideHow Much Time Will Our Team Need?
See the customer tasks behind managed bug bounty and VDP programs: scope, technical access, risk decisions, remediation and urgent escalation.
Read the guideBug 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 guideA practical next step
Make your first month purposeful.
Discuss your goals, asset ownership and technical capacity with Hackrate. We can define the preparation, responsibilities and launch conditions for your program.
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
Products
From the Blog
-
Hackrate Ranked 1st in Hungary and 22nd Globally at Hack The Box’s Global Cyber Skills Benchmark 2026
May 29 • 13 min read
-
Press release: Hackrate becomes Hungary’s first CVE Numbering Authority
Jan 13 • 5 min read ★
-
Let 2026 be the year bug bounty becomes part of how you build and operate
Jan 05 • 4 min read
Numbering Authority