# Vulnerability Disclosure Program Template ## Description Client-fillable template for the vulnerability disclosure program the provider of the offering owns: the public policy, safe harbor, intake and triage path, finder commitments, and the effectiveness review that answers KSI-PIY-RVD, with how the platform evidences the practice. ## Resolution # Vulnerability Disclosure Program Template **TEMPLATE - this document describes practices the provider of the offering owns, outside the GRCITSM platform. Replace the sample text with your organization's actual practice before publishing. The GRCITSM platform evidences these practices through scheduled validation checks; it does not execute them.** ## Purpose This template is the starting point for your organization's vulnerability disclosure program: the public policy that tells a finder how to report a vulnerability in the offering, the safe harbor you offer, the intake and triage path, the commitments you make back to the finder, and the review that keeps the program effective. The program is public-facing and provider-owned. Fill in the sample sections with your real policy, publish it at the location named in the values table, and route accepted reports into the vulnerability pipeline the platform already operates. ## Requirements this document answers One Key Security Indicator. No FedRAMP Rule (FRR) in the 2026 Consolidated Rules names a disclosure program document; the obligation is the KSI outcome. | KSI | Name | Statement | |---|---|---| | KSI-PIY-RVD | Reviewing Vulnerability Disclosures | The effectiveness of the provider's vulnerability disclosure program is persistently reviewed. | The indicator presupposes the program exists and asks that its effectiveness be reviewed on a standing cadence. Two things follow: the program needs a definition someone can measure, and the review needs measures and a cadence. !!! note "Where this KSI is claimed" The platform's Vulnerability Detection, Evaluation, and Response Policy and Procedures does not claim KSI-PIY-RVD. The disclosure program is client-owned, so the indicator routes here. That document's KSI-PIY-RVD Implemented Requirement links are re-pointed to this article at the link-reconciliation pass. Reports accepted through this program still follow the detection, evaluation, and response timelines in that document once they enter the pipeline; this template governs intake and the program, not the remediation clock. ## Sample practice: the disclosure policy **Sample text.** [Organization] publishes a vulnerability disclosure policy at [policy URL], reachable from [discovery paths: the offering's security page, a security.txt file at the well-known location, the trust center]. The policy states: the systems and domains in scope and those explicitly out of scope, the testing methods permitted and prohibited, how to submit a report and what a useful report contains, what the finder can expect back and when, and the safe harbor commitment. Personal data belonging to third parties must not be accessed, and any incidental exposure must be reported and not retained. **Sample text.** Safe harbor: [Organization] will not pursue civil action or refer a report to law enforcement where the finder acted in good faith within this policy, made a reasonable effort to avoid privacy violations and service degradation, and gave [Organization] a reasonable opportunity to remediate before disclosure. [State whether the program is a bug bounty with rewards, or an unpaid coordinated disclosure program, and if rewards exist, name the scope and criteria.] *Replace with your practice.* State the actual scope, the actual safe harbor language your counsel approves, and whether rewards are offered. A policy that promises nothing measurable cannot have its effectiveness reviewed. ## Sample practice: intake, triage, and communication **Sample text.** Reports arrive through [intake channels: the disclosure form, the security mailbox, the bounty platform] and are acknowledged within [duration]. [Role] performs an initial triage within [duration], deciding whether the report is in scope, whether it is reproducible, and its provisional severity. Accepted reports are entered into the vulnerability pipeline as detections, where they inherit the evaluation and response timelines in the Vulnerability Detection, Evaluation, and Response Policy and Procedures. A report that meets the reportable incident criteria is escalated to the incident process immediately rather than waiting on triage completion. **Sample text.** The finder receives: acknowledgement within [duration], a triage outcome with the accept or decline reason within [duration], remediation status updates every [interval] while the report is open, notification when the fix ships, and agreement on coordinated public disclosure timing. Duplicate and out-of-scope reports get a stated reason. Declined reports may be appealed to [role]. *Replace with your practice.* Name real durations. These are the commitments the effectiveness review measures against. ## Sample practice: the effectiveness review **Sample text.** [Role] reviews the program's effectiveness [cadence] against these measures: report volume by source and by outcome; median time to acknowledge, to triage, and to remediate against the committed durations; the share of reports accepted, declined, and duplicated; valid reports that the internal detection pipeline had not already found, which is the measure of what the program adds; reports that escalated to incidents; finder-reported friction with the intake or communication path; and public disclosures that happened outside the coordinated timeline. The review states what changed and what will change, and any corrective action carries an owner and a due date. The policy itself is reviewed [cadence] and on any change to the offering's scope. *Replace with your practice.* The last two measures are the ones that make this a real review: what the program found that internal detection missed, and where the process failed the finder. ## Organization-defined values | Value | Setting | Notes | |---|---|---| | Policy publication URL | [URL] | Public-facing policy | | Discovery paths | [security page, security.txt, trust center] | Findability | | Systems and domains in scope | [scope] | Policy content | | Explicitly out of scope | [scope] | Policy content | | Prohibited testing methods | [methods] | Policy content | | Program type | [coordinated disclosure / bug bounty] | Rewards, if any | | Reward scope and criteria | [criteria or "no rewards offered"] | Program type | | Safe harbor language owner | [legal role] | Counsel-approved | | Intake channels | [channels] | Intake | | Acknowledgement commitment | [duration] | Finder commitment | | Triage commitment | [duration] | Finder commitment | | Status update interval while open | [interval] | Finder commitment | | Coordinated disclosure window | [duration] | Finder commitment | | Triage owner | [role] | Intake | | Appeal authority for declined reports | [role] | Intake | | Effectiveness review owner and cadence | [role; cadence] | KSI-PIY-RVD, "persistently" | | Effectiveness measures | [measures] | KSI-PIY-RVD | | Policy review cadence | [cadence] | Keeps scope current | | Document owner | [role] | Fills the authority section | ## Evidence The GRCITSM platform does not publish your disclosure policy, receive your reports, or talk to finders. It evidences that the program exists, that reports flow into the vulnerability pipeline, and that the effectiveness review happens on its cadence. See the Continuous Monitoring and Reporting Policy and Procedures for the validation tree and the check cadences. | Practice | What the platform records | |---|---| | Policy exists, is public, and is current | The policy as a Component record of type Policy, with validation runs on its review | | Accepted reports | Each accepted report as a detection in the vulnerability pipeline, carrying its source, with evaluation and remediation on the normal clocks | | Reports that meet reportable incident criteria | The incident record and its reporting chain | | Effectiveness review (KSI-PIY-RVD) | Validation runs per review cycle, carrying the measured intervals against the committed durations; misses open Issues tracked to closure | | Program improvement | Improvement Projects opened from review findings | Disclosure-sourced detections are visible in the vulnerability reporting alongside scan-sourced and monitoring-sourced detections, so the share of findings the program contributes is readable from the pipeline rather than reconstructed by hand. ## Authority, review, and revision *Client fills.* Name the executive who issues this document, the role that owns the disclosure program, the legal role that owns the safe harbor language, the review cadence, and the approval path for exceptions. Record the issue date and the revision history below. | Version | Date | Author | Change | |---|---|---|---| | [0.1] | [date] | [author] | Initial draft from template | ## Internal Memo Source: vulnerability-disclosure-program-template.md in the GRCITSM knowledge-base library (species: client-template; editor_type 1 = markdown). Downloaded from the public GRC-ITSM documentation site; body carried verbatim from the library source. Paste the Resolution section as the article body (description_markdown) in your GRCITSM instance and apply the Tags list. ## Tags - GRCITSM Template - Vulnerability Disclosure - FedRAMP Rev5 Class C - FedRAMP 20x Class C - KSI-PIY-RVD