Vulnerability Disclosure Policy Template (ISO/IEC 29147, security.txt)

Vulnerability Disclosure Policy: [Organisation name]

Public coordinated vulnerability disclosure (CVD) policy: what security researchers may test, how we protect good-faith research (safe harbour), how to report, what we promise in return (acknowledgement, triage and remediation timelines), how we coordinate publication and embargoes, how CVE IDs are assigned and how we credit finders. The structure follows the topics covered by ISO/IEC 29147:2018 Vulnerability disclosure (receiving reports, coordination, publishing advisories, disclosure policy), and Appendix A gives a ready security.txt file in the format of RFC 9116 (April 2022). Notes cover the EU Cyber Resilience Act, Regulation (EU) 2024/2847, Articles 13 and 14 and Annex I Part II. Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company. This is a documentation format, not legal advice: have counsel review the safe harbour wording before publication.

Document control

Approvals

Revision history

Contents

1. Introduction and our commitment
2. Scope
3. Authorised testing and safe harbour
4. How to report a vulnerability
5. What happens after you report
6. Coordination, disclosure and embargo
7. CVE assignment and security advisories
8. Recognition and credit
9. Your data and confidentiality
10. Internal: regulatory and standards alignment
11. Internal: governance, measurement and review
12. Glossary and references
13. Appendix A: Ready security.txt file
14. Standard and licence note

1. Introduction and our commitment

[Organisation name] (Example: Corvid Commerce Ltd, "Corvid Commerce", "we") builds and operates [describe products and services, Example: a hosted commerce platform, its public APIs, two mobile apps and an open source command-line tool]. We believe that people who find and report security weaknesses in good faith make our customers safer, and we want reporting to us to be simple, safe and worth the effort.

This policy explains which systems you may test, the rules for testing, how to send us a report, what you can expect from us and how we coordinate public disclosure. If you follow this policy, we will treat your research as authorised, work with you to understand and fix the issue, and credit you if you wish.

We commit to the following:

1. Acknowledge every report within the time stated in section 5.
2. Keep you informed while we investigate and fix, at least at the intervals stated in section 5.
3. Fix confirmed vulnerabilities in line with their risk, and tell you when a fix is available.
4. Coordinate the timing and content of public disclosure with you.
5. Credit you publicly, unless you ask us not to.
6. Not take legal action against good-faith research that follows this policy (section 3).

This policy does not create a bug bounty. [If a bounty exists, state where its rules are published and which document prevails when they differ.]

2. Scope

2.1 In-scope assets

You may also report vulnerabilities in assets not listed here that clearly belong to us. We will review them, but the safe harbour in section 3 applies in full only to listed assets, and you should not perform active testing against unlisted assets without asking us first.

2.2 Out-of-scope assets

2.3 Out-of-scope findings

We usually do not treat the following as vulnerabilities unless you can show a concrete security impact. Please still report them if you believe the impact is real, and explain why.

3. Authorised testing and safe harbour

3.1 What we authorise

When you research an in-scope asset (2.1) in good faith and follow the rules in 3.2, we consider your activity authorised. Good faith means that your purpose is to find and report vulnerabilities so that they can be fixed, that you avoid harm to our customers, our staff and our systems, and that you do not use findings for any other purpose.

3.2 Rules of engagement

You must:

1. Test only against accounts you own or accounts you have the explicit permission of the account holder to use. Create test accounts with an email address that identifies you as a researcher, for example one that contains +security-research.
2. Stop as soon as you have enough evidence to demonstrate the issue. Do not pivot to other systems, escalate further, or keep access.
3. Not access, change, delete or keep data that does not belong to you. If you encounter personal data, payment data or credentials, stop, do not copy them, and tell us immediately.
4. Not degrade the service. Keep automated requests below [10] requests per second per host Example, and do not run denial of service, load or resource-exhaustion tests.
5. Not use social engineering, phishing or physical access.
6. Not install persistent code, backdoors or cryptocurrency miners.
7. Give us a reasonable time to fix the issue before any public disclosure (section 6).
8. Comply with the laws that apply to you.

3.3 Safe harbour

[Example wording; counsel to review:] If you make a good-faith effort to follow this policy, we will:

1. Consider your research authorised for the purposes of the computer misuse laws that apply to us, and not bring or support legal action against you for it.
2. Not pursue claims against you for circumventing technical measures that we use to protect the in-scope assets, to the extent the circumvention was necessary for the research.
3. Waive restrictions in our terms of service and acceptable use policy that would otherwise prohibit the research, for the limited purpose of the research.
4. If a third party starts legal action against you for activity that followed this policy, make it known that your activity was authorised by us.

We cannot authorise testing of systems we do not own, and we cannot bind third parties, including law enforcement. If you are unsure whether an activity is consistent with this policy, ask us at the address in section 4 before you proceed.

Some vulnerabilities you find may be in software or services supplied to us by others. You may report them to us and we will coordinate with the supplier (section 6.3). Testing a supplier's own infrastructure is not covered by this safe harbour; follow that supplier's disclosure policy.

4. How to report a vulnerability

4.1 Reporting channels

Do not report vulnerabilities through public issue trackers, social media or customer support chat. If you do not receive an acknowledgement within the time stated in section 5, please use another channel listed above.

4.2 What to include

A good report lets us reproduce the issue quickly. Please include:

1. The affected asset (URL, API endpoint, app version, product version or commit).
2. The type of vulnerability, using a CWE identifier if you know it.
3. Step-by-step reproduction instructions, including any test account IDs you used, request and response samples, and screenshots or a short video.
4. The impact you believe an attacker could achieve, and any preconditions.
5. Your own severity estimate, if you have one, with the scoring system and vector you used.
6. Whether the issue is already public or known to others, and any date by which you plan to publish.
7. How you would like to be credited (name, handle, affiliation) or that you prefer to stay anonymous.

Partial reports are welcome. We will ask for more information if we need it.

4.3 Encryption and language

You may encrypt reports with our OpenPGP key, published at [https://www.corvid-commerce.example/.well-known/security-pgp.asc] Example with fingerprint [fingerprint]. The key and its expiry are also referenced from our security.txt file (Appendix A). Encryption is optional.

We accept reports in [English] Example. Reports in other languages are welcome; we may take longer to respond while we translate them.

5. What happens after you report

5.1 Response timeline

We assess severity using a published scoring system, currently [CVSS v4.0] Example, adjusted for the context of our service. If we disagree with your severity estimate, we will explain why.

5.2 Report lifecycle

Every report follows the same path. You will hear from us at each step that changes the status of your report.

5.3 Outcomes you can expect

• Accepted: we confirm the vulnerability, share our severity rating and a target fix window, and keep you informed.
• Duplicate: we tell you that the issue was already known and, where possible, when it was first reported. Credit goes to the first reporter, unless your report adds material new impact.
• Informative or not applicable: we explain why the report does not describe a vulnerability or is out of scope.
• Accepted risk: in rare cases we may decide not to fix an issue. We will explain the reasoning and agree with you whether and how it may be published.

6. Coordination, disclosure and embargo

6.1 Default disclosure window

We aim to publish an advisory when a fix is available. Unless we agree otherwise with you, we ask that you wait until the earlier of:

1. [14] days (Example) after we release a fix and publish an advisory, so that customers running self-hosted products have time to update; or
2. [90] days (Example) after your report was acknowledged.

6.2 Extensions and early publication

• We may ask you for an extension when a fix is complex, requires coordination with several vendors, or would expose customers if published before most of them can update. We will explain the reason and propose a new date. Extensions are by agreement, not by default.
• We may publish earlier than agreed if the vulnerability is being actively exploited or becomes public through another route. We will tell you before we do, where possible.
• If you intend to publish before a fix is available, please give us at least [7] days' notice (Example) and share a draft so we can correct factual errors and prepare mitigation guidance for customers.

6.3 Multi-party coordination

When a vulnerability affects other vendors, open source projects or an upstream component, we will, with your agreement:

1. Contact the affected parties, or a coordinator such as a national CSIRT, and share only what each party needs.
2. Propose a common embargo end date and publish at the agreed time.
3. Keep you informed of who has been told.

We follow the principles of the FIRST Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure where relevant.

6.4 Embargo rules

Information shared under embargo is confidential until the agreed date. We share embargoed details only with people who need them to fix, test or prepare communications. If an embargo breaks (for example the issue appears publicly), we will inform all parties and move to publication as soon as a fix or mitigation guidance is ready.

If we cannot agree on severity, scope or timing, either party may ask a neutral coordinator, such as [a national CSIRT or CERT/CC] Example, to help. We will not use disagreement as a reason to stop communicating.

7. CVE assignment and security advisories

7.1 CVE IDs

[Example:] Corvid Commerce is [a CVE Numbering Authority (CNA) for its own products / not a CNA and requests CVE IDs from [the CNA of last resort or a named CNA]]. We request or assign a CVE ID for every confirmed vulnerability in software that customers install or run (SCOPE-003 to SCOPE-005) and, where the CVE Program rules permit and customer action or awareness is useful, for vulnerabilities in our hosted service. We publish the CVE Record when we publish our advisory. You may suggest a CVE description; we will consider it.

7.2 Security advisories

We publish advisories at [https://www.corvid-commerce.example/security/advisories] Example in human-readable form and, for installable products, as machine-readable [CSAF 2.0] Example documents. Each advisory states the affected and fixed versions, severity, a description, mitigation steps, credit and references. For hosted-service issues that required no customer action, we may publish a shorter notice. The format is described in the Security Advisory template (security/security-advisory).

Where customers ask whether a vulnerability in a third-party component affects our products, we publish exploitability statements (VEX) as described in our SBOM and VEX Policy (security/sbom-vex-policy).

8. Recognition and credit

We thank researchers who help us:

1. Advisory credit: we name you in the advisory and the CVE Record, in the form you choose, unless you ask to remain anonymous.
2. Hall of fame: we list researchers who reported valid issues during the year at [https://www.corvid-commerce.example/security/thanks] Example.
3. Rewards: [Example: We do not currently pay monetary rewards under this policy. / Rewards are paid through our bug bounty programme at URL, whose terms apply in addition to this policy.]
4. Letters of appreciation: on request, for researchers who want to show their contribution to an employer or institution.

We credit the first person who reports a given issue. If several people report the same issue independently before we publish, we may credit all of them with their agreement.

9. Your data and confidentiality

We use the contact details and report content you send us only to handle your report, to credit you as you request and to meet legal duties. Report data is kept for [5] years (Example) after the case closes, then deleted or anonymised, and is visible only to the product security team and people who need it to fix the issue. Our privacy notice at [URL] explains your rights.

We will not share your identity with third parties (including affected vendors under section 6.3) without your consent, except where the law requires us to. Please keep the details of your report confidential until publication as described in section 6.

10. Internal: regulatory and standards alignment

10.1 EU Cyber Resilience Act (Regulation (EU) 2024/2847)

For manufacturers of products with digital elements placed on the EU market. Details, roles and the reporting runbook are in CRA Vulnerability Handling (security/cra-vulnerability-handling). This policy supports the following provisions (summaries in our own words; check the consolidated text on EUR-Lex):

A report received under this policy can start the Article 14 clock if it contains reliable evidence of active exploitation. The PSIRT procedure defines how intake staff recognise that case and escalate it.

10.2 Standards and guidance

Also check: national transposition of the NIS2 Directive (EU) 2022/2555, which encourages national CVD schemes (see compliance/nis2-security-measures); national computer misuse laws and prosecutorial guidance on good-faith research; and customer contracts with fixed vulnerability notification times.

11. Internal: governance, measurement and review

11.1 Roles and responsibilities

11.2 Policy statements

• VDP-PS-01: Every product listed in 2.1 MUST have a monitored reporting channel and appear in security.txt or SECURITY.md.
• VDP-PS-02: The security.txt Expires value MUST be refreshed before it passes; the PSIRT lead SHOULD renew it every [6] months Example.
• VDP-PS-03: Any response to a researcher that departs from section 3 MUST be approved by general counsel.
• VDP-PS-04: Internal targets in the PSIRT procedure (7.4) MUST be equal to or tighter than the targets published in section 5; published targets MUST NOT be tighter than the internal ones. SECURITY.md files and the CRA procedure MUST quote the same published values.
• VDP-PS-05: New products and acquired assets SHOULD be added to scope within [90] days Example of launch or acquisition.

11.3 Measures

Example quarter for Corvid Commerce: 48 reports received, 46 acknowledged within 2 business days (46 / 48 = 95.8 %); 12 valid, 11 fixed within target (11 / 12 = 91.7 %).

Exceptions and review. Exceptions to published targets are approved by the CISO, recorded in the case, and explained to the finder. Review this policy at least annually, after any significant incident involving a researcher, and when scope, legal entities or applicable law change. Record each review in the Revision history.

12. Glossary and references

12.1 Glossary

12.2 References

Appendix A: Ready security.txt file

The file below follows RFC 9116. Replace the Example values and sign it with the key named in Encryption.

# security.txt for corvid-commerce.example (Example)
# Report security vulnerabilities to the contacts below.
# Our disclosure policy explains scope, safe harbour and timelines.

Contact: https://www.corvid-commerce.example/security/report
Contact: mailto:security@corvid-commerce.example
Expires: 2027-04-30T23:59:59.000Z
Encryption: https://www.corvid-commerce.example/.well-known/security-pgp.asc
Acknowledgments: https://www.corvid-commerce.example/security/thanks
Preferred-Languages: en
Canonical: https://www.corvid-commerce.example/.well-known/security.txt
Policy: https://www.corvid-commerce.example/security/disclosure-policy
Hiring: https://www.corvid-commerce.example/careers/security

Field notes:

Operational checks: serve the file with HTTP status 200 and Content-Type: text/plain; charset=utf-8, redirect the legacy root path /security.txt to the well-known path if you serve both, add a monitoring check that alerts 30 days before Expires (Example), and test that the reporting form and mailbox deliver to the intake rota.

Standard and licence note

Structure aligned with the topics of ISO/IEC 29147:2018 Vulnerability disclosure; no text, tables or definitions from that copyrighted standard are reproduced, and a new edition is in development, so check the current edition at iso.org. Appendix A is based on RFC 9116 (April 2022), whose field names are used under the IETF Trust's provisions for reuse. EU Cyber Resilience Act references are original summaries of Regulation (EU) 2024/2847: check the consolidated text on EUR-Lex. Open source practice draws on concepts from the OpenSSF Guide to coordinated vulnerability disclosure for open source software projects (CC BY 4.0, github.com/ossf/oss-vulnerability-guide); the CERT Guide to Coordinated Vulnerability Disclosure (SEI) and the FIRST multi-party guidelines are cited by name and concept only. The safe harbour structure follows the pattern common to public-domain VDP templates; all wording, including the safe harbour example, is original text written for this collection and is not legal advice. Check the current official versions of every source before publication. Template licence: MIT.