PSIRT Vulnerability Handling Procedure Template (ISO/IEC 30111, CVSS v4)

PSIRT Vulnerability Handling Procedure: [Organisation name]

Internal procedure of the product security incident response team (PSIRT) for handling vulnerabilities in the products and services the organisation builds: preparation, intake, verification, triage and scoring, remediation, advisories and VEX, CVE assignment, release, post-release activities and metrics. Structure aligned with the vulnerability handling process topics of ISO/IEC 30111:2019 Vulnerability handling processes, used together with ISO/IEC 29147:2018 for disclosure. Scoring uses FIRST CVSS v4.0, EPSS, the CISA Known Exploited Vulnerabilities (KEV) catalog and the CISA SSVC guide (November 2022). CVE work follows the CVE Program CNA Operational Rules 4.2.0 (effective 2026-08-25). Regulatory reporting notes cover the EU Cyber Resilience Act, Regulation (EU) 2024/2847, Article 14, which applies since 11 September 2026. Replace every [bracketed] value and every row marked Example. Worked examples use Corvid Commerce, a fictional SaaS company that also ships an installable agent and an open source CLI. This is a documentation format, not legal advice.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and boundaries
2. Process overview
3. Roles and responsibilities
4. Preparation
5. Intake
6. Verification
7. Triage, scoring and prioritisation
8. Remediation development
9. Advisories and VEX
10. CVE assignment
11. Release and coordinated disclosure
12. Regulatory and contractual reporting
13. Post-release activities
14. Metrics
15. Exceptions, risk acceptance and review
16. Glossary and references
17. Standard and licence note

1. Purpose, scope and boundaries

This procedure defines how [Organisation name] receives, verifies, prioritises, fixes, discloses and learns from vulnerabilities in the products and services it develops, including third-party and open source components shipped inside them. It applies to every supported version of the products listed in Document control, to hosted services operated by the organisation, and to open source projects the organisation maintains.

2. Process overview

The process has nine phases. The first six follow the vulnerability handling topics of ISO/IEC 30111:2019; the regulatory and metrics phases are additions for current obligations. A case can loop back from verification or remediation to triage when new facts change the severity.

Case states in the tracker: New, Acknowledged, Verifying, Triaged, Fixing, Fix ready, Disclosed, Monitoring, Closed, and terminal states Not a vulnerability, Duplicate, Risk accepted.

3. Roles and responsibilities

3.1 Roles

3.2 RACI

R = responsible, A = accountable, C = consulted, I = informed.

4. Preparation

The PSIRT MUST keep the following ready before cases arrive:

5. Intake

5.1 Sources

5.2 Intake steps

1. Create the case with a unique ID (Example: PSIRT-2026-0147) and record the receipt timestamp of the first message in any channel.
2. Acknowledge the finder within the published target (Example: 2 business days) using the standard message, naming the case handler.
3. Check for duplicates against open and closed cases and known public reports.
4. Screen for exploitation signals: finder mentions attacks in the wild, KEV listing, threat intelligence, customer incident. If present, page the PSIRT lead immediately and open the regulatory check in section 12.
5. Restrict the case to the PSIRT and the people who need it. Do not paste exploit details into chat channels or public issue trackers.

Verification: the case shows a receipt time, an acknowledgement time, a handler and an exploitation screening result.

5.3 Case record fields

6. Verification

1. Reproduce the issue in an isolated environment using the finder's steps. If you cannot, ask the finder for more detail before closing; record each attempt.
2. Determine the root cause and the vulnerable code or configuration.
3. Determine affected products and versions: check every supported release branch, the hosted service and downstream products that embed the component. Use the SBOM store (PREP-004) to find all products that ship the affected component.
4. Determine unaffected versions and the reason (code not present, not reachable, mitigated by configuration), because these become VEX statements in 9.3.
5. Decide the outcome: Verified, Not a vulnerability, Duplicate or Needs information. The PSIRT lead approves Not a vulnerability decisions for reports from external finders.
6. Inform the finder of the outcome within the published target (Example: 7 calendar days from receipt), with reasoning for a negative outcome.

Verification: affected and unaffected versions are listed with evidence; the decision is approved and communicated.

7. Triage, scoring and prioritisation

7.1 Severity scoring (CVSS v4.0)

Score every verified vulnerability with FIRST CVSS v4.0. Record the full vector string and the nomenclature that shows which metric groups were used: CVSS-B (Base only), CVSS-BT (Base and Threat), CVSS-BE (Base and Environmental) or CVSS-BTE (all three). Advisories carry the Base score for the product as shipped; internal prioritisation may add Threat metrics. Supplemental metrics are optional context and do not change the score. Use the qualitative severity rating defined by FIRST to label the score.

7.2 Likelihood signals (EPSS and KEV)

• EPSS (FIRST Exploit Prediction Scoring System) estimates the probability that a published CVE will see exploitation activity in the next 30 days. The model is retrained from time to time; the version in use is named in the first line of the daily data file (as of October 2026, v2026.06.15, the release FIRST refers to as EPSS Version 5). Record the model version with every score, because scores from different models are not directly comparable. EPSS applies only to CVEs that are already public; use it for vulnerabilities in shipped third-party components and for our own published CVEs during post-release monitoring. A low EPSS score never overrides evidence of exploitation.
• KEV (CISA Known Exploited Vulnerabilities catalog) lists CVEs with reliable evidence of exploitation. A KEV listing for a component we ship means the case is treated as exploited until verification shows our product is not affected.

7.3 Decision support (SSVC)

Use the decision points of the CISA Stakeholder-Specific Vulnerability Categorization Guide to decide how fast to act. Record the value of each decision point and the outcome.

The CISA tree first combines Mission Prevalence and Public Well-being Impact into a single Mission and Well-being value (low, medium or high), then reads the outcome from the combination of all decision points. Use the CISA guide or calculator to read the outcome; do not invent a local mapping.

The CISA guide was written for organisations deciding how to respond to vulnerabilities; we apply its decision points from our customers' point of view. CERT/CC publishes other SSVC decision models (for example for suppliers); check their licence before adapting them.

7.4 Internal priority and remediation targets

Communication targets with the finder (Example):

The targets in this section are the source of truth for every published promise. The Vulnerability Disclosure Policy (section 5), each repository's SECURITY.md (dev/security-policy) and the CRA procedure (security/cra-vulnerability-handling, 6.1 and 7.1) MUST quote values equal to or looser than these, and SHOULD quote the same values so that one case has one clock. Change this table first, then update the published documents in the same change. The PSIRT lead MAY raise priority at any time and MUST record a reason when lowering it.

7.5 Worked example

Example: PSIRT-2026-0147. A researcher reports that the Corvid Edge Agent 5.2 accepts an unsigned update manifest when the merchant uses a proxy. Verification confirms versions 5.0 to 5.2 are affected; 4.x uses a different update client and is not affected. CVSS v4.0 base score 8.7, CVSS-B, High (Example). No public exploit and no exploitation evidence: Exploitation None, Technical Impact Total, Automatable No, Mission Prevalence Essential, Public Well-being Impact Material (combined Mission and Well-being: high), outcome Track* (Example). Table 7.4 gives P2; the PSIRT lead raises it to P1 because the flaw undermines the update channel every merchant relies on, and records that reason. Fix target 30 days. Not actively exploited, so no CRA Article 14 notification; the regulatory check is recorded with that result.

8. Remediation development

1. Create the fix in a private branch or private fork (PREP-009). Do not reference the vulnerability in public commit messages or pull request titles before disclosure.
2. Fix the root cause, not only the reported proof of concept. Run variant analysis: search for the same pattern in other components and products.
3. Have the fix reviewed by a second engineer and by the case handler or a security champion. Add regression tests that fail without the fix.
4. Backport to every affected supported version (identified in section 6, step 3). If a backport is not feasible, document the mitigation for that version and get PSIRT lead approval.
5. Ask the finder to validate the fix where they are willing, before release.
6. Prepare mitigations or workarounds that customers can apply before they can update.
7. For hosted services, deploy through the normal progressive rollout unless the priority is P0, in which case use the emergency change path and record it.
8. If the target date cannot be met, inform the PSIRT lead before the date, agree a new date and tell the finder.

Verification: fixed versions are listed per supported branch, tests pass, the finder or a second reviewer has confirmed the fix, and mitigation guidance is drafted.

9. Advisories and VEX

9.1 When to publish an advisory

9.2 Advisory content

Use the Security Advisory template (security/security-advisory). Each advisory MUST state the advisory ID, title, affected products and versions, fixed versions, CVE ID, CVSS v4.0 vector and score with nomenclature, weakness type, description without exploit code, impact, mitigations and workarounds, update instructions, credit, and a revision history. For installable products, publish a machine-readable CSAF 2.0 document alongside the human-readable page. CSAF 2.1 is still a draft at the time of writing; check the OASIS CSAF technical committee before adopting it.

9.3 VEX statements

Publish a VEX statement for each product and vulnerability combination customers are likely to ask about, following the SBOM and VEX Policy (security/sbom-vex-policy). Use the four statuses from the CISA Minimum Requirements for VEX (April 2023): Not Affected, Affected, Fixed and Under Investigation. A Not Affected statement MUST carry a justification or an impact statement explaining why (for example the vulnerable code is not present or cannot be reached). An Affected statement SHOULD carry an action statement.

Example: for PSIRT-2026-0147, Corvid Edge Agent 4.x is Not Affected (vulnerable code not present); 5.0 to 5.2 are Affected with the action "update to 5.2.4"; 5.2.4 and later are Fixed.

10. CVE assignment

1. Request or reserve a CVE ID when the vulnerability is verified and affects a released version, or when a hosted-service vulnerability meets the criteria agreed with the CNA liaison. Current CVE Program rules allow records for vulnerabilities in products that exist only as hosted services; such records carry the tag defined for that purpose.
2. Assign one CVE ID per independently fixable vulnerability. Do not merge separate root causes into one ID or split one root cause across several IDs.
3. Prepare the CVE Record: affected product and versions with status, the weakness type, a prose description, at least one public reference (the advisory), the CVSS v4.0 vector, and the credit.
4. Publish the CVE Record when the advisory is published. Under CNA Operational Rules 4.2.0, a CNA should publish within 24 hours and must publish within 72 hours of publicly disclosing a CVE ID it assigned; build this into the release plan.
5. If we are not the CNA, give the CNA all record content before the disclosure date and confirm their publication time.
6. Track disputes and record updates (for example new fixed versions) in the case.

11. Release and coordinated disclosure

11.1 Release checklist

11.2 Disclosure timing

Default to the dates in the Vulnerability Disclosure Policy. Publish earlier when the issue is exploited or public. Request an extension from the finder only with a reason and a new date. Record every agreed date in the case.

11.3 Multi-party coordination

When the vulnerability affects upstream components, other vendors or downstream products:

1. Report to the upstream maintainer through their published channel, sharing only what is needed. For open source upstreams, use private vulnerability reporting where available.
2. Agree one embargo end date with all parties, and a fallback plan if the embargo breaks.
3. Use a coordinator, such as a national CSIRT, when many vendors are involved or parties do not respond.
4. Keep a contact log per party with the information shared and when.

Practice in this section draws on the concepts of the FIRST Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure (v1.1) and the OpenSSF CVD guide.

12. Regulatory and contractual reporting

12.1 CRA Article 14 check

For products with digital elements on the EU market, Article 14 of Regulation (EU) 2024/2847 requires manufacturers to notify actively exploited vulnerabilities and severe incidents affecting product security through the ENISA Single Reporting Platform, to the coordinating CSIRT and ENISA at the same time. The obligation applies since 11 September 2026, including for products placed on the market before 11 December 2027. Check the consolidated text on EUR-Lex for any amendment.

Steps:

1. At intake (5.2 step 4) and at every change of exploitation status, the case handler asks: is there reliable evidence that the vulnerability has been exploited by a malicious actor? Record the answer and the evidence.
2. If yes, record the awareness timestamp, page the reporting officer and follow the runbook in security/cra-vulnerability-handling.
3. Inform affected users of the vulnerability and corrective measures as required by Article 14(8), coordinated with the advisory.

12.2 Other obligations

13. Post-release activities

1. Monitor for exploitation and public exploit code for [30] days (Example) after disclosure: EPSS changes, KEV additions, threat intelligence and support tickets.
2. Watch for bypasses or regressions reported by the finder or others. A bypass opens a new case linked to the original.
3. Update the advisory, CSAF document, VEX and CVE Record when new fixed versions or new affected products are found; add a revision entry each time.
4. Hold a short review for every P0 and P1 case within [10] business days (Example): timeline, what worked, what slowed the case, root cause class and preventive actions. Use the blameless format of the Postmortem template (dev/postmortem).
5. Feed root causes into secure development: coding standards (security/secure-coding-standard), threat models (security/threat-model) and training through the champions programme.
6. Close the case when all fixed versions are released, all records are published, the finder has been credited and actions are tracked elsewhere.

14. Metrics

Example quarter: 21 cases received, 20 acknowledged within target (20 / 21 = 95.2 %); 9 cases had a fix target falling due in the quarter, and 8 of 9 were fixed within target (88.9 %, below target, one P2 backport to 4.x slipped by 6 days); 7 CVE Records, all published within 72 hours (100 %).

15. Exceptions, risk acceptance and review

• A target in 7.4 may be extended only by the PSIRT lead (P2, P3) or the CISO (P0, P1), with the reason, compensating mitigations and the new date recorded in the case.
• Accepting a vulnerability without a fix requires CISO approval, a documented risk assessment, customer-facing mitigation guidance where customers are exposed, and a review date no more than [6] months (Example) ahead. The finder is told of the decision.
• End-of-support versions: when a vulnerability affects a version that is no longer supported, the advisory MUST say so and recommend the upgrade path; the PSIRT lead decides whether an exceptional fix is justified.
• Review this procedure annually, after each P0 case, after any missed regulatory deadline and when products, CNA scope or laws change. Record the review in the Revision history.

16. Glossary and references

16.1 Glossary

16.2 References

Standard and licence note

Structure aligned with the vulnerability handling topics of ISO/IEC 30111:2019 and the disclosure topics of ISO/IEC 29147:2018; no text, figures or tables from these copyrighted standards are reproduced, and new editions are in development, so check the current edition at iso.org. FIRST CVSS v4.0, EPSS, the PSIRT Services Framework and the multi-party guidelines are FIRST publications with all rights reserved: only their names, metric group names and nomenclature are cited. Based on CISA guidance (SSVC guide, KEV catalog, VEX minimum requirements), which is a work of the United States Government. CVE Program rule references are summarised in original words; check the current CNA Operational Rules at cve.org. EU Cyber Resilience Act references are original summaries of Regulation (EU) 2024/2847: check the consolidated text on EUR-Lex. Open source coordination draws on concepts from the OpenSSF CVD guide (CC BY 4.0). Original text written for this collection; it is not legal advice. Check the current official versions of every source. Template licence: MIT.