Vulnerability disclosure program management
from intake to coordinated disclosure
Run a coordinated vulnerability disclosure program (VDP) as an operational workflow rather than an inbox. Capture researcher reports, triage with CVSS, communicate inside a branded portal, track remediation against agreed timelines, and produce a defensible disclosure history aligned to ISO/IEC 29147 and 30111.
No credit card required. Free plan available forever.
Vulnerability disclosure program software for security and platform teams
Most vulnerability disclosure programs (VDPs) are launched as a policy page and a security.txt contact, then quietly fall apart at the operational layer. Reports land in a shared mailbox with no acknowledgement clock. Triage decisions live in three different threads. Researchers get ghosted between submission and fix. The closure record, when an auditor finally asks for it, has to be reconstructed from email exports. The cause is almost always the same: there is no single workflow record that follows a report from intake to coordinated disclosure. SecPortal closes that gap with a VDP management workflow that handles intake, triage, researcher communication, remediation tracking, and disclosure history in one workspace.
This page is the operational view. For the policy, scope, and safe harbour groundwork, read the practical VDP setup guide, and for the copy-ready twelve-section policy artefact aligned to ISO/IEC 29147, ISO/IEC 30111, CISA BOD 20-01, and EU CRA Article 13, see the free vulnerability disclosure policy template. For the discovery layer (the file researchers check before they email anyone), the free security.txt generator builds a valid RFC 9116 file with Contact, Expires, Encryption, and Policy fields. For the wider prioritisation model that drives severity decisions, see the vulnerability prioritisation framework. And for the triage discipline behind defensible severity, see the research piece on severity calibration. For the vendor-side workflow that runs after a VDP report lands (intake to fix to CVE request to advisory publication to downstream consumer notification), see the PSIRT product security incident response workflow.
What a VDP management workflow needs to do
Structured intake from a single source of truth
Convert every researcher report (security.txt contact, web form, email forwarding rule) into a finding record with a reference identifier, reporter contact, asset, vulnerability class, and the original artefacts. The inbox stops being the system of record.
Acknowledgement timer per report
Track an acknowledgement clock from the moment a report lands. Most policies promise a response within two to five business days. The platform makes overdue acknowledgements visible to the program owner before they become a public disclosure complaint.
CVSS 3.1 triage with reproducibility evidence
Score every accepted report with a CVSS 3.1 vector and pair it with reproduction evidence (request, response, payload, screenshot). Severity stops being a label and becomes a defensible artefact a researcher and an auditor can both replay.
Branded researcher portal
Invite the researcher into a scoped portal where they can answer triage questions, see status changes, and receive updates without exchanging email attachments. The conversation lives next to the finding it relates to.
Disclosure timeline tracker
Link each finding to the disclosure window committed in the policy. Severity-tiered SLAs (typical baseline: critical 30 days, high 60, medium 90, low 180) drive the close-out clock and surface overdue items before researchers ask for an update.
Audit-ready closure record
Every report carries the intake timestamp, acknowledgement timestamp, triage decision, internal owner, fix evidence, retest result, public disclosure date, and credit decision. Auditors get one export per report instead of a reconstruction across mailboxes.
The end-to-end VDP lifecycle inside SecPortal
A coordinated disclosure follows a defined sequence. The platform records who did what and when at every step so the closure record holds up under researcher scrutiny, internal review, and external audit without a separate logging exercise.
- A researcher submits via the security.txt contact, the published web form, or the policy-stated email. The submission is converted to a finding record with a unique reference and an acknowledgement clock starts.
- The triage owner reproduces the report, attaches evidence, scores it with CVSS 3.1, and decides accept, duplicate, out-of-scope, informational, or false positive. Each disposition is recorded with rationale.
- For accepted reports, an internal remediation owner is assigned, an SLA is set by severity, and the researcher is invited into a branded portal with read access scoped to their report.
- The remediation owner works the fix in the engineering tracker of choice while the finding record holds the SLA, the conversation, and the evidence. Status updates from open to in progress to awaiting retest are timestamped.
- A retest verifies the fix and is paired to the original finding. If the fix lands, the finding moves to closed with a closure timestamp. If it does not, the SLA clock resumes with regression notes captured.
- Public disclosure is coordinated with the researcher when both sides agree the fix is in production. Disclosure language, credit (or anonymity), CVE assignment if applicable, and the closure date are recorded against the finding for the disclosure history.
Triage dispositions every program needs to record
A consistent disposition policy keeps researcher experience predictable across triagers and keeps the audit trail intact. Each closed report carries one of these states with a written rationale visible to the reporter.
| Disposition | When to use it |
|---|---|
| Accepted | Reproducible, in-scope, exploitable. Moves into the remediation workflow with severity, owner, SLA, and researcher comms inside the portal. |
| Duplicate | Already reported by an earlier researcher or already a known internal finding. Linked to the original record so credit and timeline are preserved. |
| Out of scope | Real issue, but not covered by the published scope. Closed with a written reason and a redirect (separate channel, third-party owner, retired asset). |
| Informational | Hardening, defence in depth, or hygiene observation rather than an exploitable vulnerability. Logged for context, not for SLA. |
| False positive | Not reproducible after reasonable effort. Closed with the reproduction attempts, environment notes, and the rationale visible to the reporter. |
| Withdrawn | Researcher retracted the report. Recorded so the same submission does not re-enter the queue under a different reference. |
SLA ladder that keeps disclosure timelines honest
Disclosure windows depend on severity. The ladder below is a defensible starting point for most VDPs. Document the exact targets in the policy, hold engineering to them via the platform, and surface aging buckets to leadership before researchers chase the program themselves. For the broader operational view of remediation tracking, see the remediation tracking workflow.
| Severity | Default target | Notes |
|---|---|---|
| Critical | 30 days | Active exploitation risk, public-facing, or chain leads to data exposure. Engineering treats it as out-of-band remediation alongside the disclosure clock. |
| High | 60 days | Significant impact mitigated only by complexity or partial controls. Slotted into the next planned release window with explicit owner accountability. |
| Medium | 90 days | Material risk addressable on the normal release cadence. Tracked but does not interrupt the roadmap. |
| Low | 180 days | Hardening or defence-in-depth items. Bundled into a remediation sprint or addressed alongside related work. |
| Informational | Best effort | No directly exploitable risk. Tracked for visibility, often closed with an accepted-risk decision and a written rationale. |
Where VDPs break in production, and how the workflow stops it
VDPs rarely fail because the policy is wrong. They fail under operational pressure: a researcher gets ghosted, a duplicate is re-triaged three times, an SLA quietly slips, and the audit walkthrough turns into a reconstruction project. Each failure mode below is one the workflow is built to prevent rather than survive.
Reports lost across mailboxes and shared inboxes
A security.txt address forwarding to a shared mailbox loses reports to spam, vacation auto-responders, and inbox triage debt. Converting submissions into finding records on receipt removes the failure mode entirely.
Researchers ghosted between submission and fix
Researchers tolerate slow fixes. They do not tolerate silence. A scoped portal where they see status changes and can ask clarifying questions removes the most common reason VDPs lose researcher goodwill.
Duplicate intake from automation and from people
A scanner output forwarded by a third party, a CVE-driven mass submission, and a hand-curated report can all describe the same issue. Linking duplicates to a canonical record preserves credit and avoids re-triaging the same finding three times.
Disclosure timelines slipping silently
Without an SLA tied to severity, disclosure windows drift until a researcher publicly nudges the program. SLA timers and overdue views surface the slip while there is still time to act.
No paper trail for SOC 2, ISO 27001, NIS2, or BOD 20-01 reviews
Auditors increasingly ask for evidence that the disclosure process exists in practice, not only in policy. A per-report record with timestamps, decisions, and closure evidence is the artefact every framework actually wants.
Standards and frameworks the workflow aligns to
VDPs sit at the intersection of several standards. Running the workflow as a structured record per report makes the same dataset useful for each framework without re-keying evidence every audit cycle.
ISO/IEC 29147
External vulnerability disclosure handling. The standard expects a published policy, an intake channel, acknowledgement, triage, remediation tracking, and coordinated public disclosure. The workflow on this page maps to each clause without adapter tooling.
ISO/IEC 30111
Internal vulnerability handling processes. The standard expects defined roles, triage criteria, internal communication, and remediation governance. The internal remediation owner, SLA tier, and audit log inside the platform satisfy the same clauses.
CISA Binding Operational Directive 20-01
Mandates VDPs for US federal civilian agencies, including a published policy, scope coverage, safe harbour, and reporting cadence to CISA. Per-report intake records and aggregate reporting views support both obligations from the same dataset.
NIS2 Directive (EU 2022/2555)
Article 21 expects coordinated vulnerability disclosure for essential and important entities, and Article 23 imposes incident notification deadlines. A disclosed vulnerability that becomes a significant incident moves into the same workflow without re-keying evidence.
SOC 2 and ISO 27001
Auditors evaluating Trust Services Criteria and Annex A controls increasingly look for evidence of a working disclosure process. The closure record per report is the audit artefact that satisfies the control walkthrough.
Researcher communication without the email tax
The most common reason researchers stop reporting to a program is silence. A scoped, branded researcher portal replaces the email thread with a workspace per report: status changes, clarifying questions, attachments, and the final disclosure decision in one place. Researchers see progress without chasing it; the program owner does not have to copy-paste between Slack, mail, and a tracker. For the broader product view, see the findings management feature and the AI reports feature.
Scoped researcher access
Researchers see only their own reports inside the portal, with their own status, history, and conversation. No cross-tenant leakage, no accidental visibility into other reports. MFA enforcement and AES-256-GCM encryption protect the credential and asset metadata attached to the record.
Internal triage and review roles
Role-based access keeps triagers, remediation owners, program leads, and reviewers in their own scope. Junior triagers can work the queue, leads can approve disclosure language, and the activity log captures every action with a timestamp.
How VDP management connects to the rest of the platform
VDP management is one workflow among several that share the same underlying records. A report that becomes a significant incident moves into incident response without re-keying evidence. A report that comes back in a later assessment is paired to the original record so retests preserve disclosure history. Findings from a paid penetration test and findings from a VDP submission live in the same workspace, with the source clearly labelled, so leadership sees the consolidated picture rather than two stitched datasets. For framework-specific evidence packs, the same finding records map straight into ISO 27001, SOC 2, NIS2, and NIST SP 800-53 evidence packs.
For application security teams
Application security teams running a public-facing product use the VDP queue as the front door for external research and route accepted reports straight into the AppSec triage flow alongside DAST, SAST, and SCA findings.
For internal security teams and vCISOs
Internal security teams and vCISO programs use the VDP record as the canonical source of truth for external reports while engineering keeps working in their issue tracker. The two stop drifting because the finding record holds the SLA, the owner, and the retest evidence.
A VDP is a public commitment that the program will receive, triage, and respond to security reports in good faith. Software does not replace that commitment, but it makes the commitment operationally reliable: every report has a reference, a clock, an owner, and a closure record. Get this right and researchers come back; get it wrong and the next disclosure happens on social media instead of inside the portal.
Frequently asked questions about VDP management
What is vulnerability disclosure program management software?
Vulnerability disclosure program management software is a platform that runs the operational workflow of a coordinated vulnerability disclosure program: intake, acknowledgement, triage, researcher communication, remediation tracking, and public disclosure. SecPortal handles the workflow end to end with a finding record per report, CVSS scoring, a branded researcher portal, severity-tiered SLAs, retest pairing, and an audit-ready closure record per submission.
How is a VDP different from a bug bounty?
A VDP is the policy and workflow that lets external researchers report vulnerabilities responsibly without a payout attached. A bug bounty layers cash incentives on top to drive higher report volume. Most organisations need a VDP whether or not they ever launch a bounty. The intake, triage, communication, and disclosure workflow is the same; the bounty is an economic layer on top. SecPortal is built to run the underlying workflow rather than to broker payouts.
Does SecPortal replace HackerOne or Bugcrowd?
SecPortal is not a researcher marketplace. It is the platform organisations use to manage the operational workflow of a VDP they run themselves: intake, triage, communication, remediation tracking, and disclosure history. Teams that already use a managed bug bounty platform often still need an internal workflow record once a report is accepted, and that is the role SecPortal fills.
How do I track disclosure timelines without slipping?
Tie each accepted report to a severity-tiered SLA the moment triage closes. A reasonable baseline is 30 days for critical, 60 for high, 90 for medium, 180 for low, and best effort for informational. The platform shows overdue counts and aging buckets so the program owner sees slippage before the researcher does. The disclosure clock is not the same as the SLA but uses the same record, so they stay aligned.
How should triage dispositions be recorded?
Every report should close with a documented disposition: accepted, duplicate, out of scope, informational, false positive, or withdrawn. Each disposition needs a written rationale visible to the reporter and the auditor. Recording dispositions in a structured field rather than free-text email keeps the audit trail intact and the researcher experience consistent across triagers.
How does retest evidence fit into VDP workflow?
A VDP report is closed when the fix is verified, not when the engineer says it is fixed. Pair the retest result to the original report so the closure record shows the original scope, the fix described by the owner, the retest evidence, and the final outcome. If the retest fails, the report moves back to open with regression notes and the SLA clock resumes.
How do I align my VDP to ISO/IEC 29147 and 30111?
ISO/IEC 29147 covers external disclosure handling and ISO/IEC 30111 covers internal vulnerability handling. The standards expect a published policy, an intake channel, acknowledgement, triage, remediation tracking, internal governance, and coordinated public disclosure. The per-report record on the platform maps directly to each clause: intake timestamp, acknowledgement timestamp, triage decision, owner, SLA, retest, and disclosure date. Auditors get the export rather than a reconstruction across mailboxes.
Adjacent comparison for buyers evaluating crowdsourced platforms
For the side-by-side between SecPortal as the internal findings workspace and a managed researcher marketplace, see SecPortal vs HackerOne. The comparison covers where crowdsourced researcher capacity fits, where an in-house VDP workflow takes over once a report is accepted, and how the two layers hand off to each other inside an enterprise security programme.
How it works in SecPortal
A streamlined workflow from start to finish.
Receive and acknowledge
Convert each researcher submission into a structured engagement with a unique reference. Acknowledge receipt against the timeline you publish, before triage begins, so the researcher sees the program responding in good faith.
Triage with evidence
Reproduce the report, score the finding with a CVSS 3.1 vector, attach evidence (request, response, screenshot, payload), and set severity. Use the 300+ template library so similar reports get consistent triage and remediation guidance from day one.
Communicate in a researcher portal
Pull the researcher into a branded portal scoped to their report. Questions, clarifications, and updates stay attached to the finding rather than getting lost across email threads, with timestamps and a complete audit trail.
Track remediation against the disclosure clock
Assign an internal owner, set the SLA by severity, and track work against the disclosure timeline you committed to in the policy. AI-assisted reports surface overdue items and keep the disclosure window visible to leadership.
Coordinate disclosure and close out
When the fix is verified, agree the public disclosure language with the researcher, retain the full intake to closure record, and close the report with a hall of fame credit if your policy supports it. The closure record becomes evidence for SOC 2, ISO 27001, NIS2, and CISA BOD 20-01 reviews.
Run a VDP that researchers and auditors trust
One workflow for intake, triage, communication, remediation, and disclosure. Start free.
No credit card required. Free plan available forever.