> ## Documentation Index > Fetch the complete documentation index at: https://docs.hckrt.com/llms.txt > Use this file to discover all available pages before exploring further. # How to Triage Vulnerability Reports as a Company Admin > Step-by-step guidance for reviewing evidence, validating severity, assigning reports, communicating with researchers, and reaching a final triage decision. Triaging is the process of turning a raw researcher submission into a clear, actionable decision — whether that means accepting a valid vulnerability, requesting more information, marking a duplicate, or closing the report with a rejection. Done well, triaging protects your organisation, builds trust with the research community, and keeps your programme running efficiently. This guide walks you through everything you need to do from the moment a new report lands in your inbox to the moment you set a final status. ## Accessing the report management view Every report has a dedicated management page that only company admins can access. You reach it from **Reports → My Program Reports** by clicking the report title in the inbox table. The management view shows the full report contents, a pre-validation checklist, the CVSS scorer, all comments, attached evidence files, and all available triage actions. You must have a **SuperAdmin** or **StandardAdmin** role for the relevant programme or organisation to triage reports. Read-Only and Analytics roles can view reports but cannot take triage actions such as changing status, adding comments, or awarding bounties. ## Step-by-step triage workflow ### Review the report header At the top of the management view you will see three summary cards showing the current **Status** (with its Open/Closed type), the **Target** (with its tier), and the **Severity** the researcher assigned. These give you an immediate at-a-glance orientation before you read the full submission. Also check: * **Program** — confirms which of your programmes this report belongs to * **Target** — the specific asset the researcher tested; verify it is in-scope for your programme * **Reporter** — the researcher's alias; useful context if you have prior interactions with this person * **VDP flag** — if the report arrived via an embedded/VDP form, this will be indicated on the report ### Check the pre-validation checklist Hackrate automatically analyses each report against a set of quality criteria and surfaces the results as a pre-validation checklist on the management page. This checklist checks whether the report includes all the elements needed for a productive triage: Is a summary provided? A missing or very short summary is a signal that the researcher may not have clearly articulated the vulnerability. Is a detailed description present? The description should explain how the vulnerability works and how it was discovered. Is a business impact statement included? Good reports explain not just what is broken but what an attacker could do with it. Are proof-of-concept files attached? Screenshots, videos, or request/response logs are critical for validation. Has the researcher selected a severity level? An unset or implausible severity warrants attention. Is the reported target currently in-scope for the programme? If the target is marked out-of-scope, the checklist will flag this immediately. Use the checklist as a quick indicator, not an absolute gate. A report can fail one checklist item and still be a high-quality, valid finding — for example, a researcher who submits a clearly demonstrable, critical vulnerability without attaching a file may simply need a gentle prompt to upload a screenshot. ### Read the full report content Scroll through the **Details** section to read: * **Summary** — the researcher's concise description of the issue * **Description** — the full technical write-up, including steps to reproduce * **Impact** — the researcher's assessment of business risk * **CVSS** — the submitted CVSS vector; you can view and recalculate it interactively on the management page using the built-in CVSS scorer * **Vulnerability type** (CAPEC/CWE) — the classification the researcher selected Review all **evidence files** (screenshots, videos, HTTP request captures, or code snippets) attached to the report. Evidence quality is often the deciding factor in borderline cases. ### Assess and adjust severity The severity the researcher assigned may not match your assessment. If you disagree, you can change it directly from the management view. Severity affects the bounty calculation (if your programme uses a bounty table), so setting it accurately before awarding a payout is important. Severity levels available are: **Critical**, **High**, **Medium**, **Low**, and **None**. You can also update the **vulnerability type** (CAPEC classification) and the **CWE type** if the researcher's original selection was imprecise. Use the interactive CVSS calculator on the management page to score the vulnerability yourself if you disagree with the researcher's vector. The recalculated score updates in real time and helps you justify a severity change to the researcher with a concrete, objective basis. ### Assign the report to a team member If your organisation has multiple admins, assign the report to the team member best placed to investigate it — for example, the engineer who owns the affected system, or the security analyst specialising in the relevant vulnerability class. Use the **Assign** control on the management page to select from your programme's admin users. Assigning a report creates clear ownership, prevents reports from falling through the cracks when multiple people are in the inbox, and makes the **Assigned To** column meaningful in CSV exports. ### Communicate with the researcher The management view has a comment system with two distinct modes: Visible to both your team and the researcher. Use public comments to: * Ask for clarification or additional evidence * Confirm that you have reproduced the issue * Update the researcher on remediation progress * Explain the rationale for a triage decision Public comments are the primary channel for researcher communication and have a direct effect on programme reputation and researcher satisfaction. Visible **only to your admin team**. Use internal comments to: * Document your internal analysis and rationale * Coordinate between team members * Record notes about remediation steps or timeline * Flag concerns that are not appropriate to share with the researcher Internal comments are highlighted in green in the management view so they are visually distinct from public comments. You can also store an internal **Team Summary** on the report — a free-text field that is never visible to the researcher and is intended for structured internal documentation of the finding and your team's response. ### Make the triage decision Once you have reviewed the evidence, assessed severity, and (if needed) gathered additional information from the researcher, change the report's status to reflect your decision. The full set of available statuses is described in the [Report Statuses reference](/companies/reports/report-statuses), but the most common triage actions are: | Action | Status to set | | ------------------------------------------------ | --------------------------- | | Confirm valid vulnerability | Accepted | | Ask researcher for more details | Needs more info | | Vulnerability has been fixed | Resolved | | Finding is real but not a security risk | Informative | | Already reported by another researcher | Duplicate | | Report does not demonstrate a real vulnerability | Not Accepted (Invalid) | | Submission is low-quality or irrelevant | Not Accepted (Spam) | | Target is not covered by the programme | Not Accepted (Out of Scope) | | Researcher withdrew or became unresponsive | Not Accepted (Self-Closed) | | Organisation accepts the risk without fixing | Accepted risk | | High-quality submission, but still a duplicate | Good quality duplicate | Always leave a **public comment** when closing a report, especially with a rejection. A brief, specific explanation dramatically improves researcher experience and reduces disputes. ### Mark duplicates correctly When closing a report as **Duplicate** or **Good quality duplicate**, use the **Duplicate Of** field to record the ID of the original (first-submitted) report that describes the same vulnerability. The dropdown on the management page shows all earlier reports in the same organisation's programmes, making it easy to find the right reference. Only mark a report as a duplicate when the root cause and the affected asset genuinely match. A report that describes a related but distinct vulnerability in the same system is not automatically a duplicate — it may deserve separate triage and its own bounty. ### Award a bounty (if applicable) If the report is valid and your programme is a paid bug bounty programme, you can award a bounty directly from the management view. See [Bounty Rewards](/companies/reports/bounty-rewards) for full details on how bounty amounts are determined and how to record the payment. You can also award a **bonus** on top of the standard bounty for exceptional quality, unique impact, or particularly thorough documentation. ## Integrations available from the report view The report management page provides direct access to two external integrations that help bridge your security triage workflow with your engineering and development processes. Create a GitHub issue directly from the report. The issue is pre-populated with the report's title, summary, description, impact, and severity label. Once created, the issue is linked to the report and its current state (open/closed) is shown on the management page. Draft a GitHub Security Advisory from the report. Automatically populated with the report summary, description, impact, affected package/target, and the researcher's GitHub login (if provided). Advisories are created as private drafts, giving your team time to review before any public disclosure. If your programme has a **Jira integration** configured, a Jira issue creation shortcut will also be available on the management page, pre-filled with the report data. ## Hacktivity disclosure Once a report is resolved, you may choose to publish it to the **Hacktivity** feed — Hackrate's public disclosure mechanism. Disclosing a report to Hacktivity increases programme transparency, rewards the researcher with public recognition, and contributes to the wider security community's knowledge base. The Hacktivity disclosure option is available from the report management view for admins with SuperAdmin or StandardAdmin access. You control exactly when (and whether) to publish, so disclosure always happens on your terms and timeline. ## Reopening a closed report If new information emerges after you have closed a report — for example, a researcher provides a compelling additional proof of concept after an Invalid rejection, or a Resolved vulnerability reappears in a new release — you can reopen the report using the **Reopen** action on the management page. This moves the report back to an open status and allows the triage process to continue.