Security reporting policy
Last updated April 25, 2026
Use this policy to submit vulnerabilities responsibly and track expected response milestones from first report through remediation confirmation. VeriRFP reviews reproducible reports; it does not pay to unlock hidden or withheld vulnerability claims.
Submission requirements
- Send reports to admin@verirfp.com.
- Include the affected asset, attack path, impact scope, and reproducible steps.
- State the account role, invitation state, token scope, or other preconditions required.
- Provide proof-of-concept payloads only when needed to validate impact.
- Do not include customer secrets, personal data, or destructive payloads in email attachments.
Response cadence
- Acknowledgement: within 1 business day.
- Triage update: within 3 business days.
- Remediation ETA: shared after severity classification.
- Closure notice: sent when fix is deployed and validated.
Payment and report-access policy
VeriRFP does not currently operate a standing public bug bounty program. We do not pay to receive, unlock, preview, or negotiate access to undisclosed vulnerability reports. Submit a minimally reproducible, non-destructive report first; any paid engagement or reward must be agreed in writing before paid work begins.
Safe-reporting boundaries
- Test only assets you own or have explicit permission to assess.
- Do not disrupt service availability or access non-public customer data.
- Avoid social engineering and physical intrusion attempts.
- Respect security.txt disclosure details when coordinating reports.
What helps triage move faster
The fastest reports separate the vulnerable surface, the attack precondition, and the business impact. That is especially important when a finding touches procurement rooms, trust-center access, evidence delivery, or questionnaire workflows that may carry customer-specific context.
- Describe the exact route, API, or workflow involved.
- State whether authentication, invitation access, or tokenized sharing was required.
- Explain what data or control boundary could be crossed if the issue were exploited.
- Note whether the issue is reproducible in production or only in a local or test setup.
What happens after triage
Security reports are not handled in isolation. Once a report is validated, VeriRFP routes remediation through engineering ownership, tracks customer-impacting status updates, and records the closure state used in trust-center, support, and procurement follow-up. That keeps the external answer consistent with the internal incident record.
- Severity classification determines remediation urgency and escalation path.
- Production-impacting issues are mirrored to the status workflow when customer communication is required.
- Closure notices confirm that the fix was deployed and post-fix validation completed.
Related operational references
Buyers and researchers usually need these pages alongside the reporting policy.
Scope expectations
This policy is intended for responsible disclosure of real security issues affecting VeriRFP-controlled systems and public product surfaces. Questions about pricing, roadmap, procurement terms, or implementation onboarding should go through Support rather than the security reporting queue.
- In-scope: reproducible security defects in public, authenticated, or tokenized VeriRFP workflows.
- Out-of-scope: spam reports, generic scanner output without validation, or requests for custom audits.
- Out-of-scope: payment demands for withheld report details or undisclosed vulnerability claims.
- Customer-specific configuration reviews are coordinated separately through supported channels.