Coordinated Disclosure Policy Template

[ORGANISATION NAME] is committed to working collaboratively with the security research community to identify and remediate security vulnerabilities in our products and services.

This Coordinated Vulnerability Disclosure (CVD) policy is based on ISO/IEC 29147:2018 (Vulnerability disclosure) and ISO/IEC 30111:2019 (Vulnerability handling processes), and reflects ENISA good practice guidance on coordinated vulnerability disclosure.

This policy applies to:

• All software and hardware products developed or maintained by [ORGANISATION NAME], including [PRODUCT LIST]
• Associated cloud services and APIs operated at [DOMAIN(S)]
• Mobile applications published under [ORGANISATION NAME] on [APP STORE(S)]

This policy does not cover:

• Products manufactured by third parties and sold under the [ORGANISATION NAME] brand without modification
• Products that have reached end-of-life (see [SUPPORT PAGE URL])
• Physical security vulnerabilities not exploitable remotely

To report a security vulnerability, please use one of the following channels:

Preferred method: Submit a structured report via our vulnerability disclosure portal: [PORTAL URL]

Email: [[email protected]] Please encrypt sensitive reports using our PGP key: Fingerprint: [KEY FINGERPRINT] Available at: [KEY URL] and keyserver hkps://keys.openpgp.org

security.txt: A machine-readable disclosure contact record is published at: https://[YOUR-DOMAIN]/.well-known/security.txt

We accept reports in [LANGUAGE(S)]. Reports should be treated as confidential and will not be shared outside our security team without the reporter's consent.

Please do not disclose vulnerability details publicly or to third parties before coordinating with us.

[ORGANISATION NAME] commits to acknowledging receipt of every vulnerability report within 48 hours of receipt.

Our acknowledgment will confirm:

• That your report has been received and assigned a tracking reference ([REFERENCE FORMAT, e.g. VULN-2025-XXXX])
• The name or alias we will use to credit you (if you wish to be credited)
• An initial assessment timeline

Following acknowledgment, our security team will triage the report to determine:

1. Whether the reported behaviour constitutes a security vulnerability
2. Whether the affected component is within scope
3. An initial severity estimate based on CVSS 3.1 or 4.0

We will inform you of the outcome of triage within [5] business days of acknowledgment.

[ORGANISATION NAME] assesses vulnerability severity using the Common Vulnerability Scoring System (CVSS) version [3.1 / 4.0].

Severity bands and associated response priorities:

| CVSS Score | Severity | Target Remediation Time | |------------|----------|-------------------------| | 9.0 – 10.0 | Critical | [15] calendar days | | 7.0 – 8.9 | High | [30] calendar days | | 4.0 – 6.9 | Medium | [60] calendar days | | 0.1 – 3.9 | Low | [90] calendar days |

Where a vulnerability is of a type not well captured by CVSS (e.g. logic errors, privacy vulnerabilities), we will apply qualitative assessment and document our reasoning.

We will share our severity assessment with the reporter and invite them to contest it if they disagree.

[ORGANISATION NAME] commits to remediating confirmed vulnerabilities within the target timeframes set out in the Severity Assessment section.

Our remediation process includes:

1. Root cause analysis — identifying the underlying flaw, not just the surface symptom
2. Fix development and review — including code review and, for Critical/High vulnerabilities, peer review by a second security engineer
3. Regression testing — ensuring the fix does not reintroduce the issue or introduce new vulnerabilities
4. Release and deployment — delivering the fix to affected customers via [UPDATE MECHANISM]

If we cannot meet a committed remediation timeline, we will notify the reporter promptly, explain the reason for the delay, and agree a revised timeline. We will not ask for timeline extensions of more than [30] days without good cause.

For vulnerabilities that cannot be fully remediated (e.g. due to architectural constraints), we will provide documented mitigations and workarounds.

[ORGANISATION NAME] follows a 90-day coordinated disclosure model by default, consistent with ISO/IEC 29147 and CERT/CC guidance.

The coordinated disclosure clock starts from the date we acknowledge receipt of a valid vulnerability report.

Default timeline:

• Day 0: Report received and acknowledged
• Day 5: Initial triage outcome communicated
• Day 45: Interim status update provided (or earlier if remediation is complete)
• Day 90: Coordinated public disclosure (regardless of patch status, unless exceptional circumstances apply)

Exceptions and extensions:

• For Critical vulnerabilities under active exploitation, [ORGANISATION NAME] may request an accelerated disclosure timeline. We will inform the reporter immediately.
• For complex vulnerabilities requiring supply chain coordination, we may request a timeline extension of up to [30] additional days, with the reporter's agreement.
• If a vulnerability is publicly disclosed before the 90-day window, we will make best efforts to release a patch or mitigation simultaneously.

At no point will [ORGANISATION NAME] request indefinite embargo.

[ORGANISATION NAME] authorises good-faith security research on [ORGANISATION NAME] products and services conducted in accordance with this policy.

We will not initiate or recommend legal action against security researchers who:

• Act in good faith and comply with this policy
• Report discovered vulnerabilities to us before any public or third-party disclosure
• Limit testing to what is strictly necessary to confirm the vulnerability exists
• Do not access, modify, or delete data belonging to users other than themselves
• Do not perform testing that degrades the performance or availability of [ORGANISATION NAME] services
• Do not use social engineering against [ORGANISATION NAME] personnel

[ORGANISATION NAME] waives any claim under [APPLICABLE COMPUTER MISUSE LAW / CFAA / Computer Misuse Act / etc.] against researchers acting in accordance with these conditions.

If you are uncertain whether your intended research falls within this safe harbour, please contact us at [[email protected]] before proceeding.

Upon remediation (or, in the case of 90-day disclosure, upon the coordinated disclosure date), [ORGANISATION NAME] will publish a security advisory for all vulnerabilities rated Medium severity or higher.

Advisories will be published at: [ADVISORY URL / CSAF FEED URL]

Each advisory will include:

• CVE identifier (requested from [CVE NUMBERING AUTHORITY] or MITRE)
• CVSS base score and vector string (CVSS 3.1 or 4.0)
• Affected products and versions
• Description of the vulnerability
• Remediation guidance (patch version, upgrade instructions, or workaround)
• Credit to the reporter (where consent has been given)
• References to related advisories or upstream patches

Where possible, advisories will be published in CSAF 2.0 format (OASIS Common Security Advisory Framework) to enable automated tooling to process them.

Many [ORGANISATION NAME] products include third-party and open-source components. Where a reported vulnerability originates in or affects an upstream component, [ORGANISATION NAME] will:

1. Notify the upstream maintainer or vendor within [5] business days of confirming the vulnerability and its upstream origin
2. Coordinate disclosure timelines with the upstream party
3. Not publicly disclose upstream vulnerabilities before the upstream maintainer has had a reasonable opportunity to respond (minimum [45] days, unless active exploitation requires earlier disclosure)

Downstream notification: Where [ORGANISATION NAME] acts as a component supplier to downstream integrators or OEM customers, we will notify affected downstream parties of confirmed vulnerabilities within [5] business days of confirmation, under a mutual non-disclosure obligation pending coordinated disclosure.

Reporters who believe a vulnerability originates in an upstream component are encouraged to include component name, version, and any known CVE identifiers in their report.