The most important factor to consider before starting the process of submitting a report is to make sure to have read and understood the scope, respect it, and read it again for good measure. This is in place to provide safe harbour for researchers while participating in ethical hacking activities within the program rules.
We digress; when writing up a report, be sure to provide clear and concise information to determine the steps to take in which the vulnerability can be reproduced.
In this article you will find:
Submission guidelines
The Intigriti platform has the following required fields which are needed to submit a report. In order to submit reports:
1. Locate and open the chosen program
 Figure 1.1 Screenshot of the selected program to be opened |
2. Check the program details for recent updates or changes before proceeding
3. Click on Create Submission to progress to a new draft
 Figure 1.2 Screenshot of creating submission on the program detail page |
4. Please write your detailed report in English as a preferred language unless otherwise expressly mentioned within the program details
5. Provide a Submission Title for the draft being created
 Figure 1.3 Screenshot of the submission title field |
6. Select the relevant Asset in which the testing was performed
 Figure 1.4 Screenshot of the asset selection |
7. Provide the Endpoint where the vulnerable component can be found (Optional/But Recommended)
8. Select the Type of vulnerability found from the provided options
 Figure 1.5 Screenshot of where vulnerable endpoint was found and type of vulnerability found |
 Figure 1.6 Screenshot of CVSS calculator |
While it is always recommended to use the CVSS calculator, a manual severity selector is also available.
 Figure 1.7 Screenshot of manual severity selector |
10. All information necessary to reproduce the vulnerability should be written in the report, images can be used as guidance, but should not be required to understand and reproduce the submission. Of course, there might be exceptions. While writing your report, remember: “Can my report be printed on a sheet of paper and still be understood?“. Was the answer to this question yes? Good job! If not, try to modify your report until the answer is yes
11. Only include attachments as additional evidence, i.e., screenshots to show better the steps taken towards finding the vulnerability. We cannot guarantee that we can compress all files/images/formats, so in that case, we would suggest zip images/files and uploading the zip files instead, as some particular file formats have specific size limits.
10 MB for PNG / JPG / GIF files
1 GB for all other files
Example:
Does the Triager need to make a certain POST request to reproduce your finding? Copy-paste this request into your report (and redact the cookies/authorization token) or explain how the Triager could find this POST request themselves via the web application. One thing to avoid here is to add a screenshot of the POST request. This makes it harder for the Triager to reproduce as they would need to type out the entire request manually
 Figure 1.8 Screenshot of detail section to provide snapshots and proof of concept |
12. Express the explicit security Impact the vulnerability may leave this company susceptible to and why it is that important
 Figure 1.9 Screenshot of the impact field |
13. Offer a Recommended solution of action to remedy the vulnerability (Optional)
14. Include an IP address used during testing to allow the customer to match against their logs in order to validate the test (Optional/But Recommended)
15. Select Next to proceed
 Figure 1.10 Screenshot of recommended solution and IP address used while tested |
16. Final chance to review the report before selecting submit submission
 Figure 1.11 Screenshot of submit submission button |
17. Congratulations! Submission successfully created
 Figure 1.12 Screenshot of the flag showing submission successfully created |
From this point the Submission will be Triaged, if verified it then moves on to the customer to make the final decision.
Scope validation assistant
Before you submit, an automated assistant helps verify that your findings align with the program's scope. This typically takes less than 5 seconds and runs automatically when you review your draft.
How it works
The assistant analyzes your submission content against the program's out-of-scope requirements. You'll see one of two results:
Clear to submit — No scope concerns detected; proceed with submission
Potential scope issue — The assistant flags a possible concern and explains the specific reason
If you get a scope warning
This early warning helps you avoid submitting out-of-scope findings, saving time for both you and the triage team. However, you always have the final decision.
If you still believe your submission is valid after reviewing the alert:
Read the specific reasoning the assistant provides
Cross-check against the program's scope documentation
Confirm you've reviewed the warning
Proceed with submission
Benefits
Faster turnaround: Catch scope issues before triage review begins
Stronger reputation: Maintain a high-quality submission record
Better learning: Develop sharper understanding of program boundaries
Time savings: Avoid multi-day waits only to receive an out-of-scope determination
The assistant supports your workflow without restricting it. Your security expertise and judgment remain the deciding factors for submission decisions.