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.
Submission requirements
- Send reports to admin@verirfp.com.
- Include attack path, impact scope, and reproducible steps.
- 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.
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.
- Customer-specific configuration reviews are coordinated separately through supported channels.