Vulnerability Disclosure Policy Template one signed document for scope, safe harbour, channels, timelines, and coordinated disclosure
A free, copy-ready vulnerability disclosure policy template (VDP). Twelve structured sections covering policy purpose and authority, scope and out-of-scope rules, safe-harbour commitment with CFAA, DMCA, ECPA, and acceptable-use carve-outs, authorised testing actions and rate limits, submission channels with security.txt and PGP key reference, acknowledgement timeline, triage and validation timeline, coordinated disclosure timeline with embargo back-stop, researcher recognition and bug-bounty cross-reference, regulator and downstream-consumer coordination, programme governance with named owner and review cadence, and document control with version history. Aligned with ISO/IEC 29147, ISO/IEC 30111, CISA Binding Operational Directive 20-01, the EU Cyber Resilience Act Article 13 and Article 14, FIRST Multi-Party Coordinated Vulnerability Disclosure guidance, the OASIS CSAF advisory format, the disclose.io safe-harbour standard, RFC 9116 security.txt, and the 2022 DOJ revised CFAA prosecution policy.
Run the policy against the live disclosure record, not against a separate inbox
SecPortal carries every inbound researcher submission, the acknowledgement timestamp, the triage decision, the fix evidence, the CVE issuance trail, and the coordinated-disclosure window on one workspace so the policy commitments and the audit read are the same record. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn a disclosure intent into a defensible policy
A vulnerability disclosure policy is the document a firm publishes so external researchers can report vulnerabilities with a clear understanding of the rules. The twelve sections below cover the durable shape of the artefact across ISO/IEC 29147, ISO/IEC 30111, CISA Binding Operational Directive 20-01, the EU Cyber Resilience Act Article 13 and Article 14, the FIRST Multi-Party Coordinated Vulnerability Disclosure guidance, OASIS CSAF, RFC 9116 security.txt, the disclose.io safe-harbour standard, and the 2022 DOJ revised CFAA prosecution policy. Copy the section that fits your stage and paste the rest as you go.
Copy the full policy (all twelve sections) as one block.
1. Policy purpose, scope, and authority
Open the policy with the firm intent and the executive authority. A reviewer should know in the first paragraph which entity publishes the policy, which estate is in scope, which executive authority signed it, and the date the policy went into effect. ISO/IEC 27001 Clause 5.2 and 5.3 expect documented information security policies with named authority; this section makes the disclosure policy traceable to the wider ISMS rather than a stand-alone press page.
Policy title: Vulnerability Disclosure Policy
Policy version: {{POLICY_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Last review date: {{LAST_REVIEW_DATE}}
Next review date: {{NEXT_REVIEW_DATE}}
Purpose:
{{ENTITY_NAME}} welcomes good-faith security research from the external community. This policy publishes the channels, scope, safe-harbour commitments, timelines, and recognition we operate against so a researcher who discovers a vulnerability in our systems can report it to us with confidence and a clear understanding of what to expect on our side.
Plain-language commitment:
{{PLAIN_LANGUAGE_COMMITMENT_PARAGRAPH}}
In scope (asset classes covered by this policy):
- Public marketing and corporate sites: {{PUBLIC_SITE_DOMAINS}}
- Public product domains and APIs: {{PRODUCT_DOMAINS_AND_APIS}}
- Mobile applications published under the firm name: {{MOBILE_APP_LIST}}
- Hardware devices shipped under the firm name: {{HARDWARE_DEVICE_LIST}}
- Source-available repositories under the firm organisation: {{REPOSITORY_LIST}}
- Verified subdomains under the firm domains: {{VERIFIED_SUBDOMAIN_RULES}}
Out of scope:
- Third-party SaaS the firm subscribes to (report directly to the third-party VDP).
- Payment processors and card-network infrastructure (report through the payment processor).
- Hosting providers, content-delivery networks, and DNS providers operated by third parties.
- Customer-controlled data and customer environments hosted on the firm platform unless the finding is in the platform itself.
- Marketing campaigns, social-media accounts, and short-link redirectors that do not host application code.
- {{ADDITIONAL_OUT_OF_SCOPE_BOUNDARIES}}
Frameworks the policy evidences:
- ISO/IEC 29147 (Vulnerability Disclosure)
- ISO/IEC 30111 (Vulnerability Handling Processes)
- CISA Binding Operational Directive 20-01 (federal civilian VDP, used as a private-sector benchmark)
- EU Cyber Resilience Act Article 13 (coordinated vulnerability disclosure policy expectation) and Article 14 (vulnerability handling reporting)
- FIRST Multi-Party Coordinated Vulnerability Disclosure Guidance
- OASIS CSAF (Common Security Advisory Framework) for advisory publication
- RFC 9116 (security.txt) for the discovery layer
- 2022 DOJ revised CFAA prosecution policy for the safe-harbour anchor
Approving authority: {{APPROVING_AUTHORITY_NAME_AND_ROLE}}
Approval date: {{APPROVAL_DATE}}
2. Safe-harbour commitment
Safe harbour is the clause that turns the policy from a press release into a contract a researcher can act on. Three components are load-bearing: the explicit non-pursuit promise, the bounded list of authorised activities, and the on-the-record commitment if law enforcement contacts the researcher. The clause has to be reviewed by counsel before publication. CISA Joint Open-Source Software Security Initiative published model safe-harbour language and disclose.io publishes a standard template; both are reasonable starting points.
Safe-harbour scope:
{{ENTITY_NAME}} considers good-faith security research conducted under this policy to be authorised. So long as a researcher acts within this policy, {{ENTITY_NAME}} will:
- Not pursue or support civil or criminal action under the United States Computer Fraud and Abuse Act (18 U.S.C. Section 1030), the Digital Millennium Copyright Act (17 U.S.C. Section 1201), the Electronic Communications Privacy Act, anti-trust statutes, the {{ENTITY_NAME}} acceptable-use policy, the {{ENTITY_NAME}} terms of service, or comparable laws in other jurisdictions where the researcher is located, for the activities listed below.
- Cooperate with law enforcement to clarify the authorised nature of the research if the researcher is contacted by law enforcement, prosecutors, or third-party counsel about activities conducted within this policy.
- Refrain from filing complaints with bug-bounty platforms, hosting providers, or other third parties about activities conducted within this policy.
Activities the safe harbour covers:
- Testing the in-scope assets named in Section 3 of this policy.
- Recording and reporting findings to the {{ENTITY_NAME}} security team through the channels named in Section 5.
- Retaining evidence necessary to demonstrate the finding for as long as needed to support the report, then deleting evidence within {{EVIDENCE_RETENTION_WINDOW}} of report closure.
- Withholding public disclosure for the embargo period named in Section 8 to give {{ENTITY_NAME}} time to remediate before disclosure.
Activities the safe harbour does not cover:
- Denial-of-service testing, resource-exhaustion testing, or any action intended to degrade availability for legitimate users.
- Accessing, modifying, retaining, or exfiltrating data beyond what is necessary to demonstrate the finding to the security team.
- Phishing, social engineering, or impersonation attacks against {{ENTITY_NAME}} staff, contractors, or customers.
- Physical-security testing of {{ENTITY_NAME}} premises or staff.
- Automated scanning above the rate limit named in Section 4 against production assets.
- Public disclosure before the embargo period agreed in Section 8.
- Demanding payment, threatening publication, or otherwise extorting {{ENTITY_NAME}} as a condition of report withdrawal.
If a researcher acts in good faith and uncertain whether a planned action falls inside the policy, the researcher is encouraged to ask before acting through the channels in Section 5; {{ENTITY_NAME}} commits to a non-binding answer within {{PRE_TEST_CLARIFICATION_WINDOW}} business days.
Legal review:
- Safe-harbour clause counsel of record: {{COUNSEL_OF_RECORD_NAME_AND_FIRM}}
- Last review date: {{SAFE_HARBOUR_LAST_REVIEW_DATE}}
- Next review date: {{SAFE_HARBOUR_NEXT_REVIEW_DATE}}
3. Authorised testing actions and rate limits
Bound the action space. A researcher needs to know which testing technique is acceptable on production, which is acceptable on staging, and which is never acceptable. The boundary protects production availability, customer data, and staff while preserving meaningful research scope.
Authorised on production assets in scope:
- Manual testing of application and API endpoints.
- Automated scanning at a rate of no more than {{PRODUCTION_RATE_LIMIT_REQUESTS_PER_SECOND}} requests per second per origin.
- Authentication using a tester-controlled account (researcher self-registers a test account where signup is open).
- Recording requests, responses, and screenshots necessary to demonstrate a finding.
Authorised only on staging or pre-production assets:
- Higher-rate automated scanning subject to coordination with the security team in advance.
- Fuzzing endpoints that handle structured user input where production fuzzing would risk data integrity.
- Testing that requires elevated privilege beyond what a tester-controlled account provides.
Not authorised under any circumstance:
- Denial-of-service or resource-exhaustion testing on any environment.
- Accessing, modifying, downloading, or exfiltrating data belonging to other users or customers; the demonstration of a finding has to use only the researcher own data or test data the researcher created.
- Brute-force credential testing against production accounts beyond {{BRUTE_FORCE_THRESHOLD}} attempts; staging-environment testing requires advance coordination.
- Social engineering of staff, contractors, or customers (phishing, vishing, smishing, impersonation).
- Physical testing of {{ENTITY_NAME}} premises or staff.
- Testing that would compromise availability, integrity, or confidentiality for legitimate users.
- Public disclosure of the finding before the agreed embargo period in Section 8 has lapsed.
If a researcher believes a planned action would benefit the research but falls outside this list, the researcher is encouraged to ask through the channels in Section 5; {{ENTITY_NAME}} will respond with authorisation, modification, or refusal within {{PRE_TEST_CLARIFICATION_WINDOW}} business days.
4. Submission channels and contact points
A defensible VDP supports at least three channels so a researcher with limited tooling can still submit. The dedicated email gives the lowest-barrier entry; the security.txt aligned to RFC 9116 gives discoverability; the optional reporting portal gives structured intake and a tracking identifier. Publish the encryption key fingerprint so a researcher reporting a sensitive finding has a verified channel rather than a public-mailbox guess.
Primary channel: dedicated security email
- Address: {{SECURITY_EMAIL_ADDRESS}}
- PGP public key fingerprint: {{PGP_KEY_FINGERPRINT}}
- PGP key URL or keyserver reference: {{PGP_KEY_URL_OR_KEYSERVER}}
- Acknowledgement is automatic on receipt and renewed by a person within the timeline in Section 6.
Discovery layer: security.txt at /.well-known/security.txt
Aligned to RFC 9116; reachable from every in-scope domain. Required and optional fields:
- Contact: {{SECURITY_TXT_CONTACT_LINE}}
- Expires: {{SECURITY_TXT_EXPIRES_DATE}}
- Encryption: {{SECURITY_TXT_ENCRYPTION_URL}}
- Policy: {{SECURITY_TXT_POLICY_URL}}
- Acknowledgments: {{SECURITY_TXT_ACKNOWLEDGMENTS_URL}}
- Preferred-Languages: {{SECURITY_TXT_PREFERRED_LANGUAGES}}
- Canonical: {{SECURITY_TXT_CANONICAL_URL}}
- Hiring: {{SECURITY_TXT_HIRING_URL}}
Optional channel: reporting portal
- URL: {{REPORTING_PORTAL_URL}}
- The portal captures structured fields (asset, vulnerability class, reproduction steps, evidence, suggested severity) and assigns a tracking identifier the researcher carries through the entire case lifecycle.
Optional channel: bug bounty platform
- Platform: {{BUG_BOUNTY_PLATFORM_NAME_IF_ANY}}
- Programme URL: {{BUG_BOUNTY_PROGRAMME_URL_IF_ANY}}
- Scope and severity reward table on the bounty platform; the safe-harbour and disclosure timelines in this policy apply to all reports regardless of bounty eligibility.
What to include in a report:
- Asset and exact endpoint where the issue was observed.
- Vulnerability class (per the firm taxonomy or CWE identifier).
- Step-by-step reproduction instructions.
- Suggested severity with CVSS 3.1 vector if the researcher is comfortable scoring.
- Impact narrative (what an attacker can do with the issue).
- Evidence (request, response, screenshot, payload) that demonstrates the finding.
- Researcher chosen name or handle for recognition in Section 9, or a request to remain anonymous.
- Researcher preferred contact method for clarifying questions during triage.
Out-of-band escalation: if a report receives no acknowledgement within the timeline in Section 6, the researcher may escalate to {{ESCALATION_CONTACT_NAME_AND_EMAIL}}.
5. Acknowledgement timeline
The acknowledgement timeline is the first commitment a researcher experiences. CISA BOD 20-01 sets a three-business-day window for federal agencies and is the most-cited private-sector benchmark. A timely acknowledgement is the cheapest signal a programme can send that the report has landed and the policy is real.
Acknowledgement commitment:
- {{ENTITY_NAME}} commits to acknowledge a researcher submission within {{ACKNOWLEDGEMENT_BUSINESS_DAYS}} business days of receipt.
- The acknowledgement is sent by a named member of the security team rather than an automated reply, and includes the tracking identifier, the assigned triage owner, and the next-step timeline.
How acknowledgement is measured:
- Clock-start: the timestamp the report lands on the channel named in Section 5.
- Clock-stop: the timestamp the acknowledgement reply is sent by the security team.
- Median acknowledgement time and ninety-fifth percentile acknowledgement time are reported quarterly to the audit committee under Section 11.
What the acknowledgement contains:
- Confirmation of receipt and the tracking identifier the researcher will use through the case lifecycle.
- The named triage owner and the channel where the researcher can ask follow-up questions during triage.
- The triage timeline from Section 7 and the coordinated-disclosure expectations from Section 8.
- A statement of the safe-harbour scope from Section 2 as it applies to the specific report.
- A request for any clarifying information the researcher can supply during triage.
Acknowledgement does not commit {{ENTITY_NAME}} to a triage decision; it commits to taking the report seriously, assigning a named owner, and operating the case through the timelines in Sections 7 and 8.
6. Triage and validation timeline
Triage is where the policy meets the engineering reality. A defensible programme commits to a triage decision within five to ten business days, names the four standard outcomes, and keeps the researcher informed at each transition. ISO/IEC 30111 expects an internal handling discipline that turns inbound reports into actionable cases; this section is what makes that expectation operationally real.
Triage commitment:
- {{ENTITY_NAME}} commits to a triage decision within {{TRIAGE_BUSINESS_DAYS}} business days of acknowledgement.
- If reproduction or validation requires longer than the committed window, the security team contacts the researcher with a status update before the window closes and names a revised timeline.
Triage decisions:
- Confirmed: the finding reproduces in {{ENTITY_NAME}} environment and represents a vulnerability the firm will remediate. The case moves to the engineering owner and the timeline in Section 7 begins.
- Working as designed: the behaviour is intentional and documented; the researcher is given the rationale and the design reference. Where the researcher disagrees, an escalation path to a security director is named.
- Duplicate: the finding has already been received from another source or is on the active fix backlog. The researcher receives the original receipt date and, where applicable, a recognition acknowledgement under Section 9.
- Insufficient information: the report does not contain enough detail to reproduce. The security team asks the researcher specific clarifying questions; the triage clock pauses until the response arrives.
Severity at triage:
- The triage owner records a CVSS 3.1 base vector on every confirmed finding.
- KEV listing or public exploit availability triggers severity escalation per the {{ENTITY_NAME}} severity ladder.
- The researcher suggested severity is recorded; the {{ENTITY_NAME}} severity is the firm operating value.
Triage evidence:
- Reproduction steps, environment, dataset used, and impact observed are recorded on the case.
- Screenshots, request and response captures, and any payloads are stored with the case.
- The triage decision, the severity, and the assigned engineering owner are visible to the researcher through the channel in Section 5.
How triage is measured:
- Median triage time and ninety-fifth percentile triage time per severity band, reported quarterly under Section 11.
- Triage decision mix (confirmed, working as designed, duplicate, insufficient information) per period, reviewed for outliers.
7. Coordinated disclosure timeline
The coordinated-disclosure window is where many programmes drift. Publish a default that gives the firm time to fix without leaving the researcher waiting indefinitely; name a hard back-stop; document the path for extensions. The CERT Coordination Center default is forty-five days; ninety days is common for complex platform issues; longer windows require explicit agreement. The CISA SSVC framework and the FIRST Multi-Party Coordinated Vulnerability Disclosure guidance both expect named timelines rather than open-ended embargoes.
Default disclosure window:
- {{ENTITY_NAME}} commits to remediate or to negotiate an extension within {{DEFAULT_DISCLOSURE_DAYS}} calendar days of confirmation under Section 6.
- Where the underlying issue is complex enough to require a longer window, the security team negotiates an extension with the researcher and records the agreed date on the case before the default window closes.
Hard back-stop:
- Regardless of complexity, {{ENTITY_NAME}} commits to public disclosure no later than {{HARD_BACKSTOP_DAYS}} calendar days after confirmation. The hard back-stop is the durable commitment that prevents indefinite embargoes.
Extension path:
- Request an extension before the default window closes; do not request silently after the fact.
- An extension request is in writing on the case, names the underlying complexity, and proposes a revised disclosure date.
- The researcher is the joint decision-maker on extensions; an extension without researcher agreement is not an extension.
Disclosure mechanics:
- {{ENTITY_NAME}} drafts the public advisory in coordination with the researcher.
- Where the issue warrants a CVE, {{ENTITY_NAME}} requests the CVE through {{CNA_PATH}} (MITRE root CNA, the relevant root CNA, or the firm own CNA arrangement) before the disclosure date.
- The researcher receives the draft advisory in advance and is named in the advisory unless the researcher has requested anonymity under Section 9.
- The advisory is published on the agreed embargo date through {{PUBLICATION_CHANNEL}} (the firm advisory page, the OASIS CSAF feed, the CVE record, the firm security blog).
Multi-party coordination:
- Where the issue affects multiple vendors, {{ENTITY_NAME}} engages with the affected parties through the FIRST Multi-Party Coordinated Vulnerability Disclosure framework.
- {{ENTITY_NAME}} commits to keeping the researcher informed of multi-party coordination progress and the revised disclosure date.
Public disclosure scope:
- The advisory contains the affected products, the affected versions, the fix availability, the workarounds, the CVE identifier, the CVSS vector, and the discovering researcher credit (per Section 9).
- The advisory does not contain proof-of-concept code by default; release of working proof-of-concept code is at the firm discretion and is reviewed against the threat to downstream consumers.
8. Researcher recognition and bug-bounty cross-reference
Recognition is the lightweight reward layer that makes the policy worth the researcher time even without a bounty. Three options dominate: hall of fame, swag, and bug-bounty cross-reference. The policy clarifies that the safe-harbour and disclosure timelines apply to all reports regardless of bounty eligibility.
Hall of fame:
- {{ENTITY_NAME}} maintains a public researcher acknowledgement page at {{HALL_OF_FAME_URL}}.
- Recognised researchers are listed by their chosen handle with the date of the recognised report.
- A researcher may request anonymity at any point; an anonymous report still receives the same acknowledgement, triage, and disclosure treatment.
Swag:
- {{ENTITY_NAME}} sends a token reward (T-shirt, sticker, hoodie) to recognised researchers on request.
- Swag eligibility is per recognised report rather than per finding so a researcher who submits multiple findings on the same case does not get multiple shipments.
Bug bounty cross-reference:
- {{ENTITY_NAME}} {{BUG_BOUNTY_OPERATING_STATEMENT}} a paid bug-bounty programme {{BUG_BOUNTY_PLATFORM_REFERENCE}}.
- Where a paid programme is operating, the in-scope target list, severity reward table, and platform-specific terms are published on the bounty platform.
- The safe-harbour and disclosure timelines in this policy apply to all reports regardless of whether the report qualifies for a paid bounty.
- A report submitted to the VDP that qualifies for the bounty programme is forwarded to the bounty platform with the researcher consent so the researcher receives the bounty payout under the platform terms.
Eligibility for recognition:
- The report demonstrates a confirmed vulnerability under Section 6.
- The report was submitted in good faith through the channels in Section 5.
- The researcher honoured the embargo period in Section 8.
- Duplicates may be recognised if the original researcher has not yet been recognised on the case.
Ineligibility for recognition:
- Reports of known issues already on the active fix backlog (subject to original-receipt-date check).
- Reports that violate the activities in Section 4 (denial-of-service, accessing other users data, public disclosure before embargo).
- Reports submitted under threats of public disclosure as a payment condition.
9. Regulator coordination and downstream-consumer notification
A complete VDP names the path to regulators and downstream consumers. EU CRA Article 14 expects manufacturers to notify ENISA of actively exploited vulnerabilities within set windows. PSIRT teams coordinate CVE issuance and CSAF publication. The supplier cascade carries the advisory to customers who run affected software. Naming each path in the policy makes the obligation auditable rather than implied.
Regulator notification (where applicable):
- EU Cyber Resilience Act Article 14: {{ENTITY_NAME}} notifies ENISA of actively exploited vulnerabilities affecting the firm products within twenty-four hours of becoming aware (early warning), seventy-two hours (intermediate report), and fourteen days (final report). The full lifecycle is operated by the {{ENTITY_NAME}} PSIRT under the policy in {{PSIRT_POLICY_REFERENCE}}.
- Sector-specific notification (financial services, healthcare, critical infrastructure): see the firm sector-specific notification policy at {{SECTOR_NOTIFICATION_POLICY_REFERENCE}}.
CVE coordination:
- {{ENTITY_NAME}} {{CNA_OPERATING_STATEMENT}} (operates as a CVE Numbering Authority for products under the firm root, requests CVE identifiers from MITRE for products outside firm CNA scope, or routes through the relevant root CNA).
- CVE assignment is coordinated with the researcher and recorded on the case before the disclosure date in Section 8.
Advisory publication:
- {{ENTITY_NAME}} publishes advisories at {{ADVISORY_PUBLICATION_URL}} on the agreed embargo date.
- Advisories are published in OASIS CSAF (Common Security Advisory Framework) machine-readable format at {{CSAF_FEED_URL}} where applicable, alongside the human-readable advisory.
Downstream-consumer notification:
- Direct customers receive the advisory through {{CUSTOMER_NOTIFICATION_CHANNEL}} on the disclosure date.
- Distributors and resellers receive the advisory under the supplier cascade rules in {{SUPPLIER_CASCADE_POLICY_REFERENCE}}.
- Open-source ecosystem notification (where the issue affects an upstream open-source dependency or a firm open-source library) is coordinated with the maintainer community at {{OSS_COORDINATION_REFERENCE}}.
Coordination with finder when finder identifies a regulator-relevant issue:
- {{ENTITY_NAME}} commits to keeping the researcher informed of regulator notification timelines and any constraints they impose on the public-disclosure date in Section 8.
- The researcher is asked to honour any regulator-driven embargo extension; a regulator-driven extension is recorded on the case as a documented reason for an extension under Section 8.
10. Programme governance and ownership
Name the people who carry the policy. Policies that float without named owners drift the moment the original author moves teams. ISO/IEC 27001 Clause 5.3 expects roles and authorities for the information security management system to be documented; this section is the discrete artefact that meets that expectation for the disclosure policy.
Policy owner (security or product-security function leader; maintains the document, schedules review cadence, signs off on revisions):
- Name: {{POLICY_OWNER_NAME}}
- Role: {{POLICY_OWNER_ROLE}}
- Function: {{POLICY_OWNER_FUNCTION}}
Programme operator (security or product-security operations leader; runs the inbox, the triage queue, and the disclosure schedule against the policy and reports performance):
- Name: {{PROGRAMME_OPERATOR_NAME}}
- Role: {{PROGRAMME_OPERATOR_ROLE}}
- Function: {{PROGRAMME_OPERATOR_FUNCTION}}
PSIRT lead (named owner who runs the case lifecycle for confirmed findings; coordinates CVE issuance, advisory drafting, and downstream notification):
- Name: {{PSIRT_LEAD_NAME}}
- Role: {{PSIRT_LEAD_ROLE}}
- Function: {{PSIRT_LEAD_FUNCTION}}
Legal authority (counsel of record; reviews the safe-harbour clause and the regulator-notification path):
- Name: {{LEGAL_AUTHORITY_NAME}}
- Firm or function: {{LEGAL_AUTHORITY_FIRM}}
Communications authority (named approver for the public advisory text and the press response):
- Name: {{COMMUNICATIONS_AUTHORITY_NAME}}
- Role: {{COMMUNICATIONS_AUTHORITY_ROLE}}
Governance approver (executive authority who signs the policy and material revisions):
- Name: {{GOVERNANCE_APPROVER_NAME}}
- Role: {{GOVERNANCE_APPROVER_ROLE}}
Reporting recipients:
- Operational leader: monthly performance summary covering acknowledgement time, triage time, decision mix, fix verification rate, and disclosure performance.
- Audit committee: quarterly summary covering programme health, exception cases, and any regulator notifications.
- Board (where applicable): annual review covering programme maturity and any sustained pattern of programme-level risk.
11. Review cadence and revision discipline
Two cadences operate in parallel: performance review against the policy and policy review against the underlying environment. Performance review without policy review produces a programme that operates against rules the audit will challenge. Policy review without performance review produces a clean document the programme does not operate against. Both have to land in the document trail.
Performance review:
- Monthly to operational leader: acknowledgement time distribution, triage time distribution, decision mix, open-case backlog, fix verification rate, disclosure-window adherence rate.
- Quarterly to audit committee: programme health summary, exception cases, regulator notifications, any sustained pattern that warrants policy revision.
- Annually to full board (where applicable): programme maturity review, comparison against peer benchmarks, any planned material change.
Policy review:
- Annual review at minimum, even if no material change has occurred.
- Triggered review on material change including:
- New framework adoption (the firm enters EU CRA scope, passes a SOC 2 attestation that requires VDP evidence, expands into a regulated geography).
- New estate change (a new product line, business unit, supplier acquisition that adds a new asset class).
- New regulatory expectation (a CISA directive, a sector-specific rule, an updated framework version).
- Material threat-environment change (a sustained campaign on the firm sector that justifies tighter scope or more aggressive timelines).
Revision discipline:
- Every policy version is signed by the governance approver in Section 10.
- Every material revision is recorded in Section 12 with date, summary of change, and approver name.
- Researchers are notified of material revisions through the channels in Section 5 so they operate against the current version.
Programme metrics that the audit reads:
- Median and ninety-fifth percentile acknowledgement time.
- Median and ninety-fifth percentile triage time per severity band.
- Triage decision mix per period (confirmed, working as designed, duplicate, insufficient information).
- Median and ninety-fifth percentile time from confirmation to coordinated disclosure per severity band.
- Disclosure-window adherence rate.
- CVE issuance lag from confirmation to CVE record publication.
- Researcher recognition coverage (recognised reports as a fraction of confirmed reports).
12. Document control and acknowledgement
A signed policy with version history is the artefact an external auditor reads. The acknowledgement layer captures stakeholder awareness so the policy is not a security-team-only document. Each acknowledgement is renewed at material revision; new stakeholder onboarding includes acknowledgement.
Document classification: Public (the policy is published externally so researchers can read it before submitting).
Document trail:
- Owner: {{POLICY_OWNER_NAME_AND_ROLE}}
- Approver: {{GOVERNANCE_APPROVER_NAME_AND_ROLE}}
- Counsel of record (safe-harbour clause): {{COUNSEL_OF_RECORD_NAME_AND_FIRM}}
- Distribution: external website, security.txt, internal policy library, supplier portal where applicable.
- Related documents: {{ENTITY_NAME}} Vulnerability Remediation SLA Policy, {{ENTITY_NAME}} PSIRT Operating Policy, {{ENTITY_NAME}} Audit Evidence Retention Policy, {{ENTITY_NAME}} Incident Response Plan, {{ENTITY_NAME}} Risk Acceptance Policy.
Version history:
| Version | Effective date | Approver | Summary of change |
| ------- | -------------- | -------- | ----------------- |
| {{V1_NUMBER}} | {{V1_DATE}} | {{V1_APPROVER}} | {{V1_SUMMARY}} |
| {{V2_NUMBER}} | {{V2_DATE}} | {{V2_APPROVER}} | {{V2_SUMMARY}} |
| {{V3_NUMBER}} | {{V3_DATE}} | {{V3_APPROVER}} | {{V3_SUMMARY}} |
Sign-off panel:
- Policy owner: {{POLICY_OWNER_SIGNATURE_BLOCK}}
- Governance approver: {{GOVERNANCE_APPROVER_SIGNATURE_BLOCK}}
- Legal authority: {{LEGAL_AUTHORITY_SIGNATURE_BLOCK}}
Acknowledgement (recorded for stakeholder groups; renewed at material revision):
- Heads of product engineering teams in scope: {{PRODUCT_ENGINEERING_ACKNOWLEDGEMENTS}}
- Heads of platform and infrastructure teams: {{PLATFORM_TEAM_ACKNOWLEDGEMENTS}}
- Heads of customer support and customer success: {{CUSTOMER_FACING_ACKNOWLEDGEMENTS}}
- Communications and public-relations leadership: {{COMMUNICATIONS_ACKNOWLEDGEMENTS}}
- GRC and compliance function: {{GRC_ACKNOWLEDGEMENTS}}
- Internal audit function: {{INTERNAL_AUDIT_ACKNOWLEDGEMENTS}}
Effective date once all approval signatures collected: {{EFFECTIVE_DATE_FINAL}}
Acknowledgement evidence:
- Signed acknowledgement records stored with the policy version.
- Acknowledgement renewal cadence: at every material revision plus annual training cycle.
- New stakeholder onboarding includes policy acknowledgement.
Six failure modes the policy has to design against
The disclosure policy fails the researcher read and the audit read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the template so the customisation does not weaken the discipline that makes the policy defensible.
The policy is a press release with no signed document behind it
A page on the marketing site invites researchers to email security@ but there is no signed policy, no version history, no approver. The first audit question (show me the document that names this commitment) cannot be answered. Researchers experience the inconsistency in how their reports are handled because there is no rule the team operates against. The fix is one signed policy, one version history, one approver per revision, published on a stable URL the security.txt file references.
Safe harbour is implied rather than written
The marketing page says the firm welcomes good-faith research but does not name the laws the safe harbour covers, the activities it covers, or the on-the-record commitment if law enforcement contacts the researcher. Researchers either avoid the firm or report through the bug-bounty platform of a friendly competitor. The fix is an explicit, counsel-reviewed safe-harbour clause that names CFAA, DMCA, ECPA, the firm acceptable-use policy, the bounded list of authorised activities, and the on-the-record commitment.
Scope is missing or stale
The policy was written for the public marketing site three years ago; the firm now ships a product API, a mobile app, and three subdomains acquired through M&A. Researchers report on the new estate; triage rejects the report as out-of-scope; the researcher discloses publicly because the policy did not protect them. The fix is to name in-scope assets explicitly, name out-of-scope assets explicitly, and review the scope at every material estate change so the boundary keeps up with what the firm ships.
Acknowledgement timeline is unstated and reports go silent
A researcher submits and waits two weeks for an acknowledgement. By the time the security team responds, the researcher has either disclosed publicly or stopped trusting the firm to triage in good faith. The fix is a published acknowledgement timeline (one to three business days), measured against the channel timestamp, reviewed monthly, and reported quarterly. The acknowledgement reply is sent by a named member of the security team rather than an automated bounce.
Coordinated disclosure has no hard back-stop
The policy says the firm will disclose in coordination with the researcher but does not name a default window or a hard back-stop. Cases stretch six months, twelve months, indefinitely; the researcher gives up or discloses unilaterally. The fix is a default disclosure window (forty-five to ninety days), a hard back-stop (one hundred eighty days at most for complex platform issues), an explicit extension path that requires researcher agreement, and a recorded reason for every extension.
Bounty platform inherits the safe-harbour terms instead of supplying them
The firm runs a bug-bounty programme on a third-party platform but has no underlying VDP. The bounty platform terms become the de facto safe harbour, but they apply only to in-scope bounty targets and only to reports submitted through the platform. Researchers reporting against assets outside the bounty scope have no protection. The fix is a VDP that owns the safe-harbour and disclosure commitments at the firm level, with the bounty programme as the optional reward layer that sits on top.
Ten questions the quarterly governance review has to answer
Operational review keeps the programme on top of the inbound queue. Governance review answers whether the policy is delivering durable disclosure performance or accumulating breaches and regulator notifications that the audit will read as policy drift. Run these ten questions at every quarterly review and capture the answers in the governance record.
1.What is the median and ninety-fifth percentile acknowledgement time over the rolling twelve months, and is the trend line up, flat, or down.
2.What is the triage decision mix in the period (confirmed, working as designed, duplicate, insufficient information), and are any categories drifting outside the historical range.
3.What is the median and ninety-fifth percentile time from confirmation to coordinated disclosure per severity band, and how many cases breached the default disclosure window.
4.How many cases used the extension path in the period, what was the most-cited reason for extension, and what was the median extension length.
5.How many cases reached the hard back-stop in the period, and what does the post-mortem say about why the default window was not enough.
6.How many CVE identifiers were issued in the period, what was the median lag from confirmation to CVE record publication, and is the CNA arrangement keeping pace with the case volume.
7.How many advisories were published in the period, how many in machine-readable CSAF format, and what is the downstream-consumer notification coverage.
8.How many recognised researchers were added to the hall of fame in the period, what is the recognition coverage rate against confirmed reports, and is the swag pipeline keeping pace.
9.How many regulator notifications were filed in the period (EU CRA Article 14, sector-specific), and were the notification timelines met.
10.Has any framework, regulation, or estate change in the period triggered a policy review, and is the review on schedule.
How the policy pairs with SecPortal
The template above is copy-ready as a standalone artefact. If your team already runs the inbound disclosure queue, the case lifecycle, and the advisory publication workflow on a workspace, the policy commitments become the byproduct of the work rather than a separate tracking project. SecPortal pairs every inbound report to a versioned engagement record through findings management, so the acknowledgement timestamp, the triage decision, the severity, the fix evidence, and the coordinated-disclosure window are one query against the same record rather than a reconstruction from email threads.
The document management feature carries the signed policy, the version history, the safe-harbour clause history, the scope additions log, the regulator-correspondence trail, and the disposition record for retired versions. The activity log captures the timestamped chain of state changes by user, so the time between submission and acknowledgement, between acknowledgement and triage, and between triage and coordinated disclosure is reproducible at any moment between audit cycles. The compliance tracking feature maps the inbound report to ISO 27001, SOC 2, EU CRA, PCI DSS, and NIST framework controls with CSV export so the disclosure performance can be sliced by framework when an auditor asks.
The team management feature carries the role-based access control that decides who can acknowledge, who can triage, who approves the public advisory text, and who runs the governance review. The client portal on the tenant subdomain becomes the channel where named researchers can read the case status and the disclosure history without exposing the wider engagement record. The AI report generation workflow drafts the leadership briefing and the regulator notification text from the same engagement data so the audit committee read of disclosure performance and the operational read are the same record. The platform does not replace the legal review of the safe-harbour clause, the CNA arrangement with MITRE or the relevant root CNA, or the bounty payout platform; the policy and SecPortal cover the operational layer the firm runs.