Handling submissions is a core part of running a successful vulnerability disclosure or bug bounty program. A structured and consistent approach helps your team quickly identify valid security issues, filter out noise, and communicate decisions clearly to researchers. By handling submissions thoughtfully, you support efficient remediation, fair researcher evaluation, and long-term program quality.

For programs with managed triage, your organization receives submissions that the Intigriti Triage team has assessed as unique, reproducible, and in scope. These findings are forwarded for your review so you can decide whether to accept them and remediate the issue or treat them as an accepted risk based on your internal context and priorities.

As an exception, submissions that demonstrate clear business impact but fall outside the strict scope definition may still be forwarded to you for a final decision, rather than being closed during triage.

The Intigriti Triage team provides an initial severity assessment based on the severity criteria defined in your program. This assessment reflects their best estimation using the information available during triage. However, triage may not always have full insight into the final business impact of a finding, and you remain free to adjust the severity after review.

If needed, you can use the CVSS calculator in the platform to recalculate the CVSS score and support your decision. Any changes to severity should align with the rules of engagement you defined in the Severity assessment section of your program definition.

Not all similar submissions should be handled in the same way. Correctly distinguishing between duplicate, related, and known vulnerability reports helps ensure fair researcher evaluation, accurate reporting, and efficient remediation.
​

A duplicate submission reports the same underlying vulnerability as an existing submission. Two reports are considered duplicates when they share the same root cause and can be resolved by the same fix, even if the proof of concept, endpoint, or exploitation method differs slightly. When this is the case, link the submission to the original report and close it as Duplicate. Duplicate submissions are still considered valid findings and should be handled consistently.
​

A related submission describes a similar vulnerability pattern but affects a different root cause or requires a different fix. This can include the same vulnerability type occurring on different assets, endpoints, parameters, or code paths. Related submissions are not duplicates and should be reviewed individually, as they may require separate remediation and may warrant separate rewards.
​

A known vulnerability refers to an issue your organization is already aware of, for example from a penetration test report, internal backlog, or previous assessment, but that has not yet been reported through the Intigriti platform. If a researcher reports such an issue for the first time on Intigriti, it should generally be treated as a valid submission unless your program rules explicitly state otherwise.

Adding workflow data to a submission helps your team manage and process findings more efficiently. By enriching submissions with tags, custom submission fields, and internal references, you can capture internal context such as internal scoring, prioritization, remediation status, or follow-up actions. This structured information improves filtering, reporting, and collaboration across teams, and ensures that submissions can be tracked consistently throughout their lifecycle.

Once a submission has passed all checks, you can accept it and reward the researcher. When a submission is accepted, a bounty payout is automatically created based on the severity or CVSS score and the bounty tier of the linked asset, unless the custom bounties feature is enabled.

In both cases the researcher will be rewarded reputation points an be listed as a progrma contributor.
​

Rejecting a submission means that the reported issue hasn't passed all checks. This can happen for several reasons, such as the finding being out of scope, not reproducible, informative only, or a duplicate of an existing report.

When rejecting a submission, select the close reason that best reflects your assessment and add a clear explanation in a submission message. Providing context helps researchers understand the decision and supports transparency and fair evaluation.

Resolving a submission indicates that the reported vulnerability has been fixed and should no longer be detectable.

Before resolving a submission, consider requesting a retest to have the researcher verify that the fix is effective. Retesting helps avoid premature closure and ensures vulnerabilities are properly remediated.

Awarding bonuses allows you to reward researchers independently of the submission state and without relying on standard bounty calculations. Bonuses can be granted at any point in the submission lifecycle and are commonly used to recognize exceptional effort or value, such as out-of-scope findings with significant impact, particularly well-written reports, advanced testing techniques, ...

Using bonuses thoughtfully helps reinforce positive researcher behavior and maintain a strong relationship with the community.