Program details define how your program is presented to researchers and provide the context they need to understand your scope, expectations, and rewards. Well-maintained program details help attract the right researchers, reduce misunderstandings, and improve the overall quality of submissions.
​

You can manage your program details by opening your program and going to Details. From here, you can configure the information that researchers see before and after joining your program.

The program description is the initial description of your program. In many cases, this section serves as an introduction to your organization rather than a detailed explanation of the program itself.
​

If your brand is widely known, the program description can also be used to explain how your organization views and approaches security. This helps researchers understand your security mindset and sets the tone for collaboration before they engage with your scope in detail.

The program industry helps categorize your program and makes it easier for researchers to discover programs that align with their interests and expertise. By selecting the most relevant industry for your program, you improve how your program is recommended to researchers on the platform.

The bounty table defines how researchers are rewarded for accpeted submissions in your program. By configuring your bounty table competitively and consistently, you set expectations, encourage high-quality findings, and align researcher incentives with your security priorities and available budget.

Learn more about bounty setups and tiers.

The Reward Policy section complements your bounty table by explaining how researchers are rewarded beyond the standard configuration. This section is displayed near the bounty table, ensuring important details are not hidden in long descriptions. You can use the Reward Policy section to:

Clearly defining your reward policy helps manage expectations, builds trust with researchers, and encourages continued high-quality engagement.

In this section, you define which assets researchers are allowed to test and which are out of scope. Clear, structured, and well-scoped assets help focus testing efforts, reduce ambiguity, and ensure alignment with your organization’s priorities.

Start by creating company assets or adding existing ones to your program’s scope. Where possible, define assets precisely, for example by listing specific domains, URLs, or endpoints instead of using broad wildcard entries. This level of granularity makes it clear where researchers are authorized to test and helps prevent scope misunderstandings.

Once assets are added, organize them in a logical and consistent order by creating asset groups, for example by product line, environment type, or technology. This makes your scope easier to navigate for researchers and simpler to maintain over time.

Finally, assign each asset to an appropriate bounty tier. The tier should reflect the asset’s importance, sensitivity, technical complexity, and maturity, helping researchers understand where to focus their efforts and what level of reward they can expect.

Asset groups allow you to logically bundle related assets within your program. Instead of treating every asset in isolation, groups help you structure your scope in a way that reflects how your systems, products, or environments are organized.
​

You can create and manage asset groups from your program details.

Asset groups help keep programs with a large number of assets concise by allowing you to place shared information at group level instead of repeating it on every individual asset. Group descriptions can be used to explain common characteristics, expectatins, or testing guidance that applies to all assets in the group.

For researchers, asset groups improve clarity and navigation by showing how assets relate to each other and what they have in common. This makes it easier to understand the broader scope and quickly identify relevant targets, while keeping asset-level descriptions focused and easy to scan.
​

The In scope section is where you welcome researchers and guide them through what you want tested. Programs with clear scope definitions, well-explained priorities, and strong communication tend to attract more engaged researchers and higher-quality submissions. How you present this section often reflects how your team works with researchers throughout the program.

You can also link to relevant documentation or include short guides directly in this section. Providing context upfront reduces the need for researchers to leave the platform to assess whether the program is relevant or worth their time.

This section defines what is explicitly out of scope, both in terms of assets and vulnerability types you are not looking for. Clearly documenting out-of-scope areas helps researchers focus on relevant targets and prevents unnecessary submissions.

The default out-of-scope template is maintained by Intigriti and is designed to reduce noise submissions. Noise submissions create friction for everyone involved, they lower validity ratios, disappoint researchers, increase the number of invalid submissions counted against platform limits, and add no value to your organization. You can customize this template if needed, but we strongly recommend reviewing any changes carefully.

Known issues that cannot be resolved immediately should also be documented in the out of scope section. Listing known issues helps researchers avoid spending time on already identified problems and allows them to focus on uncovering new and unknown blind spots. This is especially important for private or non-public programs, where disappointing researchers by accepting duplicate or already-known findings should be avoided whenever possible.

Learn more about similar submissions handling (duplicates, related findings, and known issues).

The rules of engagement define how researchers are expected to test your scope and interact with your systems. Use this section to specify expectations, restrictions, or prohibitions that are not already covered by the Out of Scope section or the standard Terms & Conditions.
​
You can also use this section to provide guidance on how high-impact proof of concepts (PoCs) should be demonstrated responsibly. This typically includes requiring the use of controlled test accounts and ensuring that no real users, data, or business operations are impacted during testing or exploitation. Examples:

In addition, this section can be used to set expectations around communication and collaboration, such as response time targets, how you handle follow-up questions, or whether you plan to award bonuses for exceptional reports.

Testing requirements are displayed directly underneath the bounty table, making them highly visible to researchers. Clearly defining these requirements helps reduce ambiguity, supports incident response, and allows your teams to quickly recognize authorized testing activity.

Automated tooling
For Application, Registered, or Public programs, we strongly recommend defining a rate limit for automated tooling to avoid operational impact. If excessive traffic becomes an issue, you can update this requirement and notify researchers via a program update.
​

Use of @intigriti.me email address
Using the @intigriti.me email domain helps your teams identify legitimate researcher activity. This can prevent false positives, support fraud handling, and allow automated exceptions or privileges for test accounts.
​

Custom request header
Requiring a specific request header helps identify authorized testing traffic in logs and during incident response. Example: X-Bug-Bounty: <username>
​

Custom user agent
A custom user agent serves a similar purpose, making researcher traffic easier to trace and distinguish from regular users. Example: User-Agent: Intigriti - <username> - Mozilla/5.0 (...)

The safe harbor section clarifies how your organization treats researchers who test your program in good faith and in compliance with your rules.
​
Enabling Safe harbour helps build trust with researchers and encourages responsible disclosure by reassuring them that compliant, good-faith testing will not expose them to unnecessary legal risk.

In the Severity assessment section of your program details, you can explain to researchers how they can expect submissions to be categorized.

If you deviate from the standard approach, use your severity assessment text to explain how severities will be handled for your program.

Intigriti includes a built-in CVSS calculator to support consistent severity assessment. CVSS 3.0 is used by default, and your organization can switch to CVSS 4.0 for more granular scoring. This is configured at company level and applies across all programs.

To select the CVSS version used by your organization:

Switching CVSS versions affects new submissions going forward. For duplicate submissions, the severity vector and level from the parent submission are copied to the duplicate, and the change is logged in the submission activity thread.

The Program FAQ section is used to document common practical questions researchers may have about your program. It typically covers clarifications around testing practicalities, rewards, and test account usage, helping researchers quickly find answers without needing to ask for additional guidance.

Submission questions allow you to extend the default submission template with additional, structured questions that researchers must answer when submitting a report. By collecting this information upfront, you reduce back-and-forth during triage and make submissions easier to evaluate and reproduce.
​

Learn more about Submission questions.
​