Organization onboarding

Understand the onboarding process

Organization onboarding prepares your team to receive, evaluate and resolve security vulnerability reports through Proofsec. A well-configured organization account gives researchers the information they need to test authorized assets and submit actionable findings.

Before publishing a program, prepare your authorization records, asset inventory, Rules of Engagement, triage process, reward policy and internal remediation workflow.

Publishing a program is not only a configuration task. Your organization must be prepared to respond to reports, protect confidential research material and follow the commitments communicated to researchers.

The exact account setup and publishing controls depend on the functionality available on Proofsec. Complete the applicable verification and configuration steps presented by the platform before making a program public.

Verify authority

Only create or publish an organization program if you are authorized to represent the organization and permit security testing of the listed assets. Keep the organization name, representative details and contact information accurate.

Confirm that the person creating the program has permission to make commitments concerning scope, report handling, rewards and disclosure. If approval is required from a security lead, asset owner or legal team, obtain it before publishing.

Do not include assets merely because your organization uses them, links to them or depends on them. Confirm ownership or obtain explicit permission from the party that controls each asset.

For third-party services, review the relevant provider policies, contracts and testing authorization requirements. Authorization to test your own application does not automatically authorize testing the provider's infrastructure.

Keep records of relevant approvals and asset ownership where appropriate. These records can help resolve scope questions and demonstrate that the program was published with proper authorization.

If your authority over an asset changes, remove it from scope or update the program promptly. Do not continue to authorize testing of assets that your organization can no longer permit researchers to test.

Prepare your organization profile

Provide accurate organization information so researchers can understand who operates the program and which organization is responsible for handling submitted reports.

Use a recognizable organization name and a reliable contact channel. Avoid misleading descriptions, unverified claims or information that implies a relationship with another company that does not exist.

Designate the people or team responsible for program administration, vulnerability triage, remediation coordination and reward approval.

Ensure that authorized representatives can access the relevant organization account and receive important communications. Protect the email accounts and credentials associated with administrative access.

Review the organization information periodically and update it when representatives, contact details or operational responsibilities change.

Only provide personal or confidential information that is necessary for account administration and verification. Do not publish internal contact details or sensitive organizational information unless there is a clear reason to do so.

Inventory your assets

Build an inventory of the assets you intend to include before defining the program scope. Depending on your environment, this may include web applications, domains, APIs, mobile applications, desktop software, cloud resources and other systems.

For each asset, record its owner, operational purpose, environment, dependencies and the authorization available for security testing.

Distinguish assets operated directly by your organization from those operated by hosting providers, SaaS vendors, business partners or other third parties.

Identify sensitive systems where testing could affect production availability, customer data, financial transactions or other critical operations.

Use the inventory to determine which assets can be included, which require additional approval and which must remain out of scope.

Do not publish broad wildcard entries or vague asset descriptions unless you can clearly establish what they include and have authority to authorize testing across that entire range.

Design an actionable scope

• List exact domains, applications, APIs, mobile packages or other assets that may be tested.
• Use descriptions that distinguish authorized targets from similarly named systems, unrelated subdomains and third-party services.
• State exclusions explicitly, including third-party infrastructure, unrelated services and production-sensitive areas.
• Describe allowed and prohibited vulnerability classes and testing techniques.
• Explain rate limits, test-account requirements, test windows and other operational restrictions.
• Specify whether automated scanning is allowed and whether additional approval is required for high-volume or potentially disruptive tests.
• Explain how researchers should handle accidentally encountered sensitive information.
• Provide a contact or process for scope questions and urgent findings.
• Review the complete scope for ambiguity before publishing.

Define the Rules of Engagement

The Rules of Engagement explain how researchers may test your assets and what boundaries they must respect. They should be specific enough that a researcher can determine whether a proposed test is authorized before performing it.

State whether denial-of-service testing, social engineering, phishing, physical security testing, destructive actions, persistence or testing involving real customer accounts is prohibited or requires separate written approval.

Define any applicable request limits, automation restrictions, testing windows and requirements for using dedicated test accounts.

Explain whether researchers may create accounts, upload test files, perform state-changing actions or interact with external integrations as part of validation.

Require minimal-impact testing. Researchers should collect only the evidence needed to demonstrate a vulnerability and should avoid unnecessary access to sensitive records.

Provide a clear process for requesting clarification or additional authorization. Do not rely on silence or ambiguous wording to imply permission for high-impact activity.

Make sure the Rules of Engagement are consistent with the scope, reward criteria and Organization Terms. Conflicting instructions can create avoidable risk for both the organization and researchers.

Establish a safe harbor commitment

A safe harbor commitment explains how your organization will treat good-faith researchers who act within the program's authorization and follow its Rules of Engagement.

Before publishing, ensure that the commitment reflects what your organization is actually prepared and authorized to honor. Involve the appropriate legal, security and compliance personnel where necessary.

Communicate the commitment to internal teams that may encounter security research, including incident response, customer support, legal and infrastructure operations.

Clearly describe the boundaries of authorization. Safe harbor does not grant permission to attack unrelated systems, disrupt services, misuse data or continue testing after authorization has been withdrawn.

Do not imply that your organization can grant legal protection against claims by unrelated third parties or that Proofsec independently authorizes testing on your behalf.

Use consistent language across the program description, Rules of Engagement and applicable organization terms so researchers understand which protections apply.

Define eligible findings

Explain which vulnerability classes your program considers eligible and which types of reports are excluded. The criteria should reflect the systems you operate and the security risks you want researchers to identify.

Distinguish exploitable security vulnerabilities from general hardening recommendations, best-practice observations, theoretical concerns and scanner output that does not demonstrate a meaningful impact.

Where appropriate, document requirements for demonstrating impact, such as reproducible behavior, an affected endpoint, an explanation of the security boundary and a minimal proof of concept.

Specify how known issues, previously reported vulnerabilities, duplicates, issues in unsupported assets and findings without sufficient evidence will be handled.

Avoid exclusions so broad that researchers cannot reasonably determine whether a genuine vulnerability is eligible. If a category is excluded, explain the boundary clearly.

Ensure that the published criteria can be applied consistently by the team responsible for triage.

Configure severity and reward criteria

If the program offers rewards, publish the reward ranges, eligibility requirements and any material exclusions before research begins.

Describe the factors used to assess severity, such as confidentiality, integrity and availability impact, exploitability, required privileges, affected users and the scope of the security boundary crossed.

Clarify how the organization distinguishes severity from reward eligibility. A technically serious issue does not automatically qualify for a reward if it falls outside the published program terms.

Explain whether reward amounts vary by asset, vulnerability class, severity or other clearly defined criteria. Avoid contradictory ranges and undefined exceptions.

Define how duplicate reports are evaluated and, where relevant, how the organization determines whether a finding was previously known or already submitted.

Ensure that the team approving rewards has the authority and budget to fulfill the commitments made in the program.

Do not introduce new restrictions retroactively to avoid obligations that arose under the terms applicable when a report was submitted.

If the program does not offer rewards, state that clearly. Do not imply that submission guarantees payment, compensation or another benefit.

Prepare your triage team

Assign responsibility for receiving reports, validating findings, determining severity, coordinating remediation and communicating decisions to researchers.

Ensure that incoming reports reach an actively monitored channel and that responsibility does not depend on one individual being continuously available.

Define an internal escalation path for critical vulnerabilities, suspected active exploitation, exposed credentials, sensitive data exposure and other urgent findings.

Set realistic response-time targets and make them visible where the platform supports program-specific expectations. Allow for the complexity of investigations and communicate delays when they occur.

Give reviewers access to the technical expertise and system owners needed to reproduce and assess findings.

Document who can accept or reject reports, assign severity, approve rewards and authorize disclosure. This reduces inconsistent decisions and unnecessary delays.

Prepare a handover process so that reports remain actively managed when team members are unavailable or responsibilities change.

Define the report review workflow

• Receive the report and confirm that it identifies a potentially affected in-scope asset.
• Review the reproduction steps, evidence, affected component and claimed security impact.
• Determine whether additional information is necessary to reproduce the finding.
• Validate the issue using the minimum access, requests and data required.
• Assess severity, scope compliance, eligibility and possible overlap with known findings.
• Record the technical reasoning and evidence supporting the decision.
• Communicate the outcome and its rationale to the researcher.
• If accepted, assign an owner and track remediation through verification.
• Coordinate reward administration and disclosure where applicable.
• Retain the information needed for auditability, follow-up and consistent handling.

Triage responsibly

Acknowledge reports and communicate expected review timelines. If the review will take longer than expected, provide an update when reasonably possible.

Reproduce issues safely using the minimum required access and data. Avoid unnecessary interaction with production systems or real customer accounts.

Keep reports, supporting files, proof-of-concept material and researcher identity confidential.

Avoid asking researchers to collect unnecessary personal data, retrieve unrelated records or perform additional testing beyond the published scope.

If the evidence already demonstrates a serious vulnerability, do not require the researcher to increase impact merely to satisfy an arbitrary reproduction preference.

Record decisions and relevant reasoning so later reviews are consistent. Use the same criteria for comparable findings while accounting for meaningful technical differences.

When rejecting a report, explain the specific reason, such as insufficient evidence, lack of demonstrated security impact, an out-of-scope asset or a previously reported issue.

When a report is marked as a duplicate, provide enough explanation to justify the classification without disclosing another researcher's confidential information.

If new evidence materially changes the assessment, reconsider the finding where appropriate.

Handle sensitive data and credentials

Researchers may occasionally encounter credentials, personal information, internal documents or other sensitive data while validating a vulnerability. Your program should explain how such information must be handled.

Instruct researchers to stop unnecessary access once the issue is demonstrated and to avoid downloading, copying or sharing data that is not required for validation.

Restrict access to submitted evidence to personnel who need it for security assessment, incident response, remediation or other legitimate program responsibilities.

Do not request live passwords, private keys, active tokens or bulk customer records when redacted or synthetic evidence is sufficient.

If an active secret is exposed, follow the appropriate containment process, which may include revocation, rotation, access review and investigation of potential misuse.

Securely store and share report attachments. Avoid unrestricted repositories, public tickets, broad mailing lists and other channels that expose sensitive material unnecessarily.

If you discover that a report contains more sensitive information than necessary, limit further access and coordinate appropriate handling with the researcher.

Rewards and payment administration

If rewards are offered, establish an internal process for confirming eligibility, approving amounts and completing payments under the published program terms.

Identify the team or representative responsible for approving rewards and ensure that approval requirements do not create avoidable delays.

Communicate the reward decision, amount and relevant rationale clearly. If additional verification or payment information is required, explain the reason and use an appropriate secure process.

Request only the personal or financial information reasonably necessary to administer the payment and meet applicable requirements.

Do not promise a particular payment method, currency, processing time or tax treatment unless it has been confirmed under the applicable arrangement.

Honor reward commitments that apply to accepted findings. A later program pause, closure or change in criteria does not automatically cancel an existing obligation.

Keep records of reward decisions and payment status so that the organization can resolve questions and maintain consistent administration.

Review the applicable Proofsec plan and payment documentation for actual platform fees, available payment methods and processing requirements. Do not infer these details from the program's reward range.

Coordinate remediation

The organization remains responsible for fixing vulnerabilities in its systems. A report being accepted does not mean the issue has been resolved.

Assign every accepted finding to an appropriate technical owner and define the next action, priority and expected remediation timeline.

Prioritize issues according to their demonstrated impact, exposure, exploitability and potential harm to users or business operations.

For high-impact issues, follow the organization's incident-response process and involve the relevant security and infrastructure teams without unnecessary delay.

After implementing a fix, verify that the original attack path no longer works and assess whether related endpoints, services or configurations are also affected.

Update the report status when the issue progresses through investigation, remediation and verification, using the states supported by the platform.

If a fix cannot be deployed immediately, document the reason, assess interim mitigations and communicate material delays where appropriate.

Use findings to identify systemic weaknesses, improve security controls and reduce the likelihood of similar vulnerabilities recurring.

Plan vulnerability disclosure

Establish a disclosure process that balances remediation, researcher communication and the safety of affected users.

Discuss disclosure timing with the researcher and agree on a reasonable timeline that accounts for severity, remediation progress and exploitation risk.

Provide meaningful updates when the timeline changes. If you need an extension, explain the reason and propose a practical next step.

Do not impose indefinite confidentiality solely to avoid reputational consequences. Restrictions should have a reasonable and clearly communicated justification.

Before publication, coordinate the removal of active secrets, personal information and technical details that would unnecessarily expose users or systems.

Ensure that internal communications about disclosure are consistent across security, legal, communications and product teams.

Do not imply that Proofsec itself fixes vulnerabilities or guarantees a particular disclosure outcome. Your organization remains responsible for its remediation and its own commitments.

Protect researcher privacy

Use researcher information only for legitimate program operations, report assessment, communication, reward administration and other appropriately disclosed purposes.

Limit access to personal information and confidential research material according to role and operational need.

Do not publish a researcher's identity, private communications or personal information without an appropriate basis or authorization.

Ensure that employees, contractors and external reviewers who access reports follow applicable confidentiality and security requirements.

If identity verification is required for a specific purpose, explain the requirement and collect the information through an appropriate process.

Define appropriate retention and deletion practices for reports and related information, taking account of remediation, security investigations, legal obligations and other legitimate requirements.

Your organization remains responsible for its own handling of information obtained through the program. Using Proofsec does not remove the need to follow applicable data-protection obligations.

Maintain organization access

Restrict organization administration to authorized personnel who need access to configure programs, review reports or manage related operations.

Protect administrative credentials and the email accounts used to access the organization. Enable additional account protections when supported by the platform.

Avoid sharing individual credentials when separate user accounts or supported access controls are available.

Review permissions after staff changes, changes in responsibility or suspected account compromise.

Remove access promptly when a person no longer needs to manage the organization or review confidential reports.

If you suspect unauthorized access to your organization account or report material, secure the affected account, investigate the incident and contact the appropriate Proofsec support channel.

Publish and validate the program

Before publishing, review the program as if you were a researcher encountering it for the first time. Confirm that the targets, exclusions, testing rules, report requirements and reward conditions are understandable without internal knowledge.

Verify that every in-scope asset is authorized and that third-party dependencies have been reviewed.

Check that the scope, Rules of Engagement, severity criteria, reward terms and disclosure expectations do not contradict one another.

Confirm that the designated triage team is ready, incoming reports will be monitored and urgent findings have an escalation path.

Ensure that your organization can meet its response and reward commitments with the staff, budget and technical access available.

Review the public-facing description for outdated information, unsupported promises, vague wording and confidential details that should not be published.

Complete any required platform verification and review the final configuration before making the program available to researchers.

Operate and improve the program

Treat publication as the beginning of an ongoing process rather than a one-time configuration task.

Review incoming reports for recurring weaknesses, unclear scope definitions and categories that generate repeated misunderstandings.

Update asset lists and Rules of Engagement when infrastructure, vendors, ownership or testing permissions change.

Review triage delays, decision consistency, remediation progress and reward administration to identify operational bottlenecks.

When changing program rules, communicate material updates clearly and consider how they affect research already underway and reports already submitted.

Use feedback from researchers and internal reviewers to make reporting requirements clearer and reduce unnecessary friction.

Keep program information accurate and ensure that the team responsible for the program remains capable of fulfilling its commitments.

Pause or close a program

If the organization can no longer support the program, use the available platform controls to pause or close it and communicate the change where appropriate.

Clarify whether researchers must stop ongoing testing and whether any authorization remains valid after the program is paused or closed.

Review outstanding reports, pending reward decisions, unresolved vulnerabilities and agreed disclosure timelines before considering the program fully concluded.

Continue handling existing reports according to the terms that apply to them. Closing a program does not automatically remove obligations that arose before closure.

If an asset is removed because authorization has changed, notify affected researchers as soon as reasonably possible and make the updated scope unambiguous.

Preserve records necessary for remediation, reward administration, security investigations and outstanding commitments, subject to applicable retention requirements.

Common onboarding mistakes

• Publishing assets without confirming ownership or explicit testing authorization.
• Using broad or ambiguous scope descriptions that leave researchers guessing.
• Failing to list third-party exclusions or restrictions on production-sensitive systems.
• Publishing conflicting Rules of Engagement, reward criteria or severity definitions.
• Promising response times or rewards that the organization cannot deliver.
• Leaving report notifications unmonitored or relying on a single unavailable reviewer.
• Requesting unnecessary sensitive data or excessive reproduction steps.
• Rejecting reports without a specific technical explanation.
• Failing to assign accepted findings to an owner for remediation.
• Leaving outdated assets, contacts or permissions in a published program.
• Closing a program without addressing pending reports and existing commitments.

Organization launch checklist

• Verify organization identity and representative authority.
• Confirm ownership or authorization for every in-scope asset.
• Prepare an accurate asset inventory and identify third-party dependencies.
• Publish precise scope definitions and explicit exclusions.
• Review and publish clear Rules of Engagement.
• Define eligible vulnerability classes, report requirements and severity criteria.
• Publish reward ranges and conditions if the program offers rewards.
• Confirm that safe harbor language reflects the organization's actual commitment.
• Assign triage, remediation, reward approval and disclosure responsibilities.
• Establish secure handling procedures for reports and sensitive data.
• Confirm that the team can monitor incoming reports and escalate urgent findings.
• Review all program details for contradictions and unsupported promises.
• Complete the required platform setup and verification.
• Publish the program only when the organization is ready to meet its commitments.

Next steps

After onboarding, monitor incoming reports and maintain communication with researchers throughout triage and remediation.

Use the Organization Terms to review your responsibilities concerning authorization, safe harbor, confidentiality, rewards, disclosure and program closure.

Refer to the relevant Proofsec documentation for report handling, program configuration and any payment or account functionality available to your organization.

Review your program regularly and update it whenever your assets, permissions, operational processes or commitments change.