# 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.

<!--
Guidance: How to use this template
- This is the producer-side procedure: what happens inside the organisation after someone
  reports a vulnerability in something you make. The public promise to researchers is the
  Vulnerability Disclosure Policy (`security/vulnerability-disclosure-policy`). Scanning and
  patching third-party software you run is the Vulnerability Management Policy
  (`security/vulnerability-management-policy`). EU CRA duties and the Article 14 runbook are
  in CRA Vulnerability Handling (`security/cra-vulnerability-handling`).
- Fill section 3 (roles) and section 7 (scoring and targets) first. Every other section
  depends on who decides and how fast.
- Write each step so that a deputy who has never run a case can follow it. Name tools and
  queues, not just activities.
- Pitfall: treating hosted-service vulnerabilities as "fixed, nothing to publish". Customers,
  regulators and the CVE Program may still expect a record; decide case by case in 10.
-->

## Document control

<!-- Guidance: Name the PSIRT lead and deputies explicitly. Record the products in scope and the regulatory regimes that apply, because they drive the deadlines in sections 7 and 12. -->

| Field | Value |
|---|---|
| Document ID | [PSIRT-PROC-001] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@psirt-lead] |
| Approvers / reviewers | [@ciso], [@vp-engineering], [@general-counsel], [@head-of-support] |
| Last updated | YYYY-MM-DD |
| Classification | Internal |
| Products in scope | *Example:* Corvid Commerce platform (hosted), Corvid Edge Agent 4.x and 5.x, corvid-cli |
| CNA status | [CNA for own products / Not a CNA, uses [CNA name]] |
| Case tracker | [*Example:* private security project `PSIRT` in the issue tracker, restricted group] |
| Regulatory regimes | [*Example:* EU CRA Article 14; NIS2 national law; customer contracts] |
| Related | Vulnerability Disclosure Policy (`security/vulnerability-disclosure-policy`), CRA Vulnerability Handling (`security/cra-vulnerability-handling`) |
| Next review | YYYY-MM-DD (annually and after every Critical case) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief information security officer | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Vice president of engineering | [@name] | [Decision] | YYYY-MM-DD |
| General counsel | [@name] | [Decision] | YYYY-MM-DD |
| Head of customer support | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record changes to targets, roles, scoring rules and regulatory steps. Link the case that triggered a change where relevant. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; CVSS v4.0 and SSVC adopted for prioritisation |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* CRA Article 14 reporting step added; KEV monitoring automated |

## Contents

<!-- Guidance: Keep aligned with the headings. -->

1. [Purpose, scope and boundaries](#1-purpose-scope-and-boundaries)
2. [Process overview](#2-process-overview)
3. [Roles and responsibilities](#3-roles-and-responsibilities)
4. [Preparation](#4-preparation)
5. [Intake](#5-intake)
6. [Verification](#6-verification)
7. [Triage, scoring and prioritisation](#7-triage-scoring-and-prioritisation)
8. [Remediation development](#8-remediation-development)
9. [Advisories and VEX](#9-advisories-and-vex)
10. [CVE assignment](#10-cve-assignment)
11. [Release and coordinated disclosure](#11-release-and-coordinated-disclosure)
12. [Regulatory and contractual reporting](#12-regulatory-and-contractual-reporting)
13. [Post-release activities](#13-post-release-activities)
14. [Metrics](#14-metrics)
15. [Exceptions, risk acceptance and review](#15-exceptions-risk-acceptance-and-review)
16. [Glossary and references](#16-glossary-and-references)
17. [Standard and licence note](#standard-and-licence-note)

## 1. Purpose, scope and boundaries

<!-- Guidance: State which products and versions the PSIRT covers and which neighbouring processes it hands off to. Unclear boundaries are why cases stall between security operations and product security. -->

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.

| Situation | Handled by | Hand-off |
|---|---|---|
| Vulnerability reported in our product or service | This procedure | Start at section 5 |
| Vulnerability in a component we ship (upstream library, base image) | This procedure, for impact on our products | Report upstream (11.3); publish VEX (9.3) |
| Vulnerability in third-party software we only run internally | Vulnerability Management Policy (`security/vulnerability-management-policy`) | Security operations |
| Evidence that a vulnerability is being exploited against our service or customers | Incident response (`compliance/incident-response-plan`) in parallel with this procedure | Incident commander joins the case |
| Actively exploited vulnerability or severe incident in a product on the EU market | This procedure plus `security/cra-vulnerability-handling` | Reporting officer starts the Article 14 clock (12) |
| Findings from a commissioned penetration test | `security/pentest-report`, then section 7 of this procedure | Findings enter as internal reports |

## 2. Process overview

<!-- Guidance: One picture of the whole flow. Every box must map to a numbered section and every decision to an owner. -->

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.

```mermaid
flowchart TD
    P["4 Preparation"] --> I["5 Intake"]
    I --> V["6 Verification"]
    V -->|"not a vulnerability or duplicate"| X["Close with explanation"]
    V --> T["7 Triage and scoring"]
    T -->|"actively exploited"| R["12 Regulatory clock and incident response"]
    T --> D["8 Remediation development"]
    D --> A["9 Advisory and VEX"]
    D --> C["10 CVE assignment"]
    A --> L["11 Release and disclosure"]
    C --> L
    R --> L
    L --> PR["13 Post-release"]
    PR --> M["14 Metrics and improvement"]
    M --> P
```

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

<!-- Guidance: Small organisations combine roles, but keep the decision rights separate: the person who fixes should not alone decide that a case is low severity. Name deputies for every role that has a legal clock. -->

### 3.1 Roles

| Role | Responsibility |
|---|---|
| PSIRT lead | Owns this procedure, assigns case handlers, approves severity and disclosure dates |
| Case handler (PSIRT analyst) | Runs a case from intake to closure, communicates with the finder, keeps the record complete |
| Intake rota | Monitors all channels every business day; on-call outside hours for Critical signals |
| Product security champion | Engineering contact in the affected team; reproduces and assesses code impact (see `security/security-champions-program`) |
| Engineering owner | Develops, reviews and ships the fix and backports within target |
| Release manager | Schedules fixed releases and coordinates embargoed builds |
| CNA liaison | Reserves and publishes CVE IDs, maintains CVE Records |
| Reporting officer | Submits regulatory notifications (12); named deputy required |
| Communications and support leads | Customer notices, support macros, press statements |
| General counsel | Legal questions on researchers, contracts and regulators |

### 3.2 RACI

| Activity | PSIRT lead | Case handler | Eng. owner | Release mgr | CNA liaison | Reporting officer | Comms |
|---|---|---|---|---|---|---|---|
| Acknowledge report | A | R | I | | | | |
| Verify and reproduce | A | R | C | | | | |
| Score and prioritise | A | R | C | | | C | |
| Develop and test fix | C | C | A/R | C | | | |
| Write advisory and VEX | A | R | C | | C | | C |
| Assign and publish CVE | A | C | | | R | | |
| Release fix | C | I | R | A | | | I |
| Regulatory notification | A | C | | | | R | C |
| Customer communication | C | C | | | | | A/R |
| Post-release review | A | R | C | C | I | I | I |

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

## 4. Preparation

<!-- Guidance: Most failures in a real case trace back to missing preparation: no product inventory, no way to build an old supported version, no signing key, no CNA account. Check this list quarterly. -->

The PSIRT MUST keep the following ready before cases arrive:

| ID | Preparation item | Evidence | Owner |
|---|---|---|---|
| PREP-001 | Published Vulnerability Disclosure Policy and security.txt with a monitored contact | Policy URL; security.txt `Expires` date | PSIRT lead |
| PREP-002 | Restricted case tracker with the fields in 5.3 and access limited to need-to-know | Tracker configuration; access review | PSIRT lead |
| PREP-003 | Product and version inventory with support status and end-of-support dates | Inventory export | Release manager |
| PREP-004 | SBOM for each supported release, searchable by component and version (see `security/sbom-vex-policy`) | SBOM store query | Engineering owners |
| PREP-005 | Ability to build, test and sign every supported version, including old release branches | Successful rebuild in the last quarter | Release manager |
| PREP-006 | CNA account or agreement with a CNA for our products | CNA scope statement or contact | CNA liaison |
| PREP-007 | Advisory publication channel and CSAF provider metadata, if CSAF is used | Advisory page; provider metadata URL | Case handler |
| PREP-008 | Registration on the ENISA Single Reporting Platform and named reporting officer and deputy, where the CRA applies | Registration record | Reporting officer |
| PREP-009 | Encrypted communication: OpenPGP key or secure portal; private repository forks for embargoed fixes | Key fingerprint; fork policy | PSIRT lead |
| PREP-010 | Training for case handlers, champions and intake rota; annual tabletop exercise (see `security/tabletop-exercise`) | Training records; exercise report | PSIRT lead |

## 5. Intake

<!-- Guidance: Every channel must feed the same tracker. Measure acknowledgement time from first receipt in any channel, not from ticket creation. Pitfall: reports arriving in support tickets that never reach the PSIRT. -->

### 5.1 Sources

| Source | Route into tracker |
|---|---|
| External finders through the VDP form, email or repository private reporting | Automatic ticket creation; email parsed by the intake rota |
| Bug bounty platform, if any | Platform integration; duplicate check against tracker |
| Coordinators, national CSIRTs, other vendors and upstream projects | Intake rota creates case |
| Customers through support | Support macro routes to PSIRT queue within [1] business day *(Example)* |
| Internal discovery: code review, SAST, DAST, fuzzing, penetration tests, threat models | Engineering or AppSec opens case when impact on a released version is likely |
| Monitoring of advisories and CVE feeds for shipped components | SBOM matching job opens case per affected product (9.3) |
| CISA KEV additions affecting shipped components | Automated alert; treated as exploited until verified (7.2) |

### 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

| Field | Content |
|---|---|
| Case ID, title | `PSIRT-YYYY-NNNN`; neutral title without exploit detail |
| Source and finder | Channel, finder identity and credit preference |
| Timestamps | Received, acknowledged, verified, triaged, fix released, disclosed, closed, regulatory awareness |
| Affected products and versions | From verification (6) |
| Weakness type | CWE identifier |
| Scores | CVSS v4.0 vector and score with nomenclature, EPSS score, percentile, model version and date, KEV status, SSVC outcome |
| Internal severity and target date | From 7.4 |
| Fix references | Commits, pull requests, release versions, backports |
| Advisory, VEX and CVE | Advisory ID, VEX statements, CVE ID and record status |
| Regulatory decision | Article 14 assessment, notifications sent and timestamps |
| Communication log | Every message with finder, vendors, coordinators and customers |

## 6. Verification

<!-- Guidance: Verify fast but carefully. A wrong "not reproducible" closure is the most common cause of a finder publishing without you. Record the reasoning for every negative decision. -->

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

<!-- Guidance: Use more than one signal. CVSS describes technical severity; EPSS estimates the likelihood of exploitation activity; KEV records known exploitation; SSVC turns these into an action. Pitfall: using the CVSS base score alone as a deadline. -->

### 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.

| Decision point | Values | How we determine it |
|---|---|---|
| Exploitation | None, Public PoC, Active | Threat intelligence, KEV, finder statement, our telemetry |
| Technical Impact | Partial, Total | Control an attacker gains over the affected component |
| Automatable | Yes, No | Whether the first steps of the attack can be automated and repeated at scale |
| Mission Prevalence | Minimal, Support, Essential | How central the affected feature is to customers' operations |
| Public Well-being Impact | Minimal, Material, Irreversible | Effect on people, for example through payment or health data |

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.

| Outcome | Meaning for the PSIRT |
|---|---|
| Act | Treat as Critical priority: emergency fix or mitigation, leadership informed, regulatory check |
| Attend | Expedite ahead of the normal release train |
| Track\* | Normal train, watched closely for changes in exploitation |
| Track | Normal release train and target |

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

| Priority | Typical trigger | Fix or mitigation target | Customer notice |
|---|---|---|---|
| P0 *(Example)* | SSVC Act, or Active exploitation, or KEV-listed component in a shipped product | Mitigation within 72 hours, fix within 7 days *(Example)* | At mitigation, then at fix |
| P1 *(Example)* | SSVC Attend, or CVSS-B Critical without exploitation | 30 days *(Example)* | With advisory |
| P2 *(Example)* | CVSS-B High, SSVC Track\* | 60 days *(Example)* | With advisory |
| P3 *(Example)* | CVSS-B Medium or Low, SSVC Track | 90 to 180 days *(Example)* | With advisory or release notes |

Communication targets with the finder *(Example)*:

| Step | Internal target | Measured from |
|---|---|---|
| Human acknowledgement | 2 business days | First receipt in any channel |
| Verification outcome shared with the finder | 7 calendar days | First receipt |
| Status update to the finder | At least every 14 calendar days until the fix is released | Last update |
| Default disclosure date | Earlier of 14 days after the fix and advisory, or 90 days after acknowledgement | Acknowledgement or fix release |

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

<!-- Guidance: Develop fixes in private, test them for regressions and bypasses, and ship them for every supported version at once where you can. Pitfall: fixing the main branch and forgetting the long-term support branch customers actually run. -->

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

<!-- Guidance: The advisory is what customers act on. Write it for an operator who must decide in five minutes whether to update tonight. Keep VEX consistent with the advisory and the SBOM. -->

### 9.1 When to publish an advisory

| Case | Advisory |
|---|---|
| Vulnerability in an installable product or open source project | Always, at release of the fix |
| Hosted-service vulnerability requiring customer action | Always |
| Hosted-service vulnerability fixed with no customer action and no evidence of exploitation | Short notice or none, by PSIRT lead decision recorded in the case |
| Vulnerability in a shipped component that does not affect our products | No advisory; publish a VEX `not_affected` statement on request or in the VEX feed |

### 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

<!-- Guidance: Decide early whether a CVE ID is needed, because reserving one takes time and the ID appears in the fix release notes. If you are a CNA, follow the CNA Operational Rules for your scope. -->

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

<!-- Guidance: Treat the disclosure date as a release with a checklist. Customers, the finder, other vendors and regulators may each need a different message at a different time. -->

### 11.1 Release checklist

| Step | Owner | Done |
|---|---|---|
| Fixed builds produced, signed and tested for every affected supported version | Release manager | [ ] |
| SBOM and VEX updated for fixed releases | Engineering owner | [ ] |
| Advisory, CSAF document and CVE Record ready and reviewed | Case handler, CNA liaison | [ ] |
| Support macro and customer notice ready; high-risk customers identified | Support lead | [ ] |
| Finder informed of release time and credit text | Case handler | [ ] |
| Other vendors and coordinators informed under embargo | Case handler | [ ] |
| Release published, then advisory and CVE Record published within the agreed window | Release manager, CNA liaison | [ ] |
| Regulatory final report deadline calculated if a notification was made (12) | Reporting officer | [ ] |

### 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

<!-- Guidance: Run this check on every case, not only on Critical ones: the CRA trigger is active exploitation, not severity. Record the decision and the awareness time. The detailed runbook is in `security/cra-vulnerability-handling`. -->

### 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.

| Stage | Deadline (summary) | Owner |
|---|---|---|
| Early warning | Without undue delay, at most 24 hours after becoming aware | Reporting officer |
| Notification | Without undue delay, at most 72 hours after becoming aware | Reporting officer |
| Final report, exploited vulnerability | At most 14 days after a corrective or mitigating measure is available | Reporting officer |
| Final report, severe incident | Within one month after the incident notification | Reporting officer |

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

| Obligation | Trigger | Owner |
|---|---|---|
| NIS2 incident reporting (national law) | Significant incident affecting our own service, if we are an essential or important entity | Incident commander |
| Personal data breach notification (GDPR Articles 33 and 34) | Exploitation led to a personal data breach | Data protection officer |
| Customer contracts | Contractual notice periods for vulnerabilities or incidents | Account management with counsel |

## 13. Post-release activities

<!-- Guidance: A case is not done at publication. Watch for exploitation, incomplete fixes and questions from customers, then feed lessons back into development. -->

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

<!-- Guidance: Report quarterly to the security steering group. Use medians and percentiles, not averages, because a few long cases distort means. Pitfall: measuring speed alone and rewarding "not a vulnerability" closures. -->

| ID | Metric | Formula | Target |
|---|---|---|---|
| PSIRT-M-01 | Acknowledgement within target | Cases acknowledged within published target / cases received | ≥ 95 % *(Example)* |
| PSIRT-M-02 | Median time to verification | Median (verified time minus received time) | ≤ 7 days *(Example)* |
| PSIRT-M-03 | Remediation within target | Cases fixed within priority target / cases due in period | ≥ 90 % *(Example)* |
| PSIRT-M-04 | Median time to fix by priority | Median (fix released minus triaged), per P0 to P3 | P1 ≤ 30 days *(Example)* |
| PSIRT-M-05 | Backport completeness | Affected supported versions fixed / affected supported versions | 100 % *(Example)* |
| PSIRT-M-06 | Coordinated disclosure rate | Cases disclosed on the agreed date / cases disclosed | ≥ 90 % *(Example)* |
| PSIRT-M-07 | CVE Record timeliness | CVE Records published within 72 hours of disclosure / CVE IDs disclosed | 100 % *(Example)* |
| PSIRT-M-08 | Regulatory timeliness | Notifications sent within deadline / notifications required | 100 % |
| PSIRT-M-09 | Repeat weakness rate | Cases whose CWE matches a case closed in the previous 12 months / cases verified | Falling trend *(Example)* |
| PSIRT-M-10 | Fix bypass rate | Bypass cases opened / fixes released | ≤ 5 % *(Example)* |

*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

<!-- Guidance: Exceptions are normal; undocumented exceptions are not. Every missed target needs an owner, a reason and a new date. -->

- 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

<!-- Guidance: Keep terms aligned with the disclosure policy and the CRA procedure so that the same word means the same thing in all three documents. -->

### 16.1 Glossary

| Term | Meaning |
|---|---|
| PSIRT | Product security incident response team: handles vulnerabilities in products the organisation makes |
| Case | One tracked vulnerability report from receipt to closure |
| Finder | Person or organisation that reported the vulnerability |
| CVSS v4.0 | FIRST Common Vulnerability Scoring System version 4.0: metric groups Base, Threat, Environmental and Supplemental |
| EPSS | FIRST Exploit Prediction Scoring System: daily probability estimate of exploitation activity for published CVEs; the model version is named in each data file |
| KEV | CISA Known Exploited Vulnerabilities catalog |
| SSVC | Stakeholder-Specific Vulnerability Categorization: decision-tree method producing Track, Track\*, Attend or Act |
| CNA | CVE Numbering Authority |
| CSAF | OASIS Common Security Advisory Framework, machine-readable advisory format |
| VEX | Vulnerability Exploitability eXchange: statement of a product's status for a vulnerability |
| Actively exploited vulnerability | Under the CRA, a vulnerability with reliable evidence of exploitation by a malicious actor without the system owner's permission |
| Backport | Applying a fix to an older supported release branch |

### 16.2 References

| Reference | Use |
|---|---|
| ISO/IEC 30111:2019, *Vulnerability handling processes* (iso.org/standard/69725.html) | Process topic structure (no text reproduced) |
| ISO/IEC 29147:2018, *Vulnerability disclosure* (iso.org/standard/72311.html) | Disclosure interface |
| FIRST CVSS v4.0 (first.org/cvss/v4-0) | Severity scoring (names and nomenclature only) |
| FIRST EPSS (first.org/epss; model version from the data feed header, v2026.06.15 as of October 2026) | Likelihood signal |
| CISA Known Exploited Vulnerabilities catalog (cisa.gov/known-exploited-vulnerabilities-catalog) | Exploitation signal |
| CISA, *Stakeholder-Specific Vulnerability Categorization Guide*, November 2022 (cisa.gov/ssvc) | Decision points and outcomes |
| CVE Program, CNA Operational Rules 4.2.0, effective 2026-08-25 (cve.org) | CVE assignment and record publication |
| CISA, *Minimum Requirements for Vulnerability Exploitability eXchange (VEX)*, April 2023 | VEX statuses |
| OASIS CSAF 2.0 (docs.oasis-open.org/csaf) | Machine-readable advisories |
| Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 (eur-lex.europa.eu/eli/reg/2024/2847/oj) | Regulatory reporting |
| FIRST PSIRT Services Framework v1.1 (first.org/standards/frameworks/psirts) | Service area names used for capability planning: Stakeholder Ecosystem Management, Vulnerability Discovery, Vulnerability Triage and Analysis, Remediation, Vulnerability Disclosure, Training and Education |
| FIRST, *Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure* v1.1 | Multi-party coordination (cited by name) |
| OpenSSF, *Guide to coordinated vulnerability disclosure for open source software projects* (CC BY 4.0) | Upstream and open source coordination |
| Vulnerability Disclosure Policy (`security/vulnerability-disclosure-policy`) | Public promise this procedure delivers |
| CRA Vulnerability Handling (`security/cra-vulnerability-handling`) | CRA duties and Article 14 runbook |
| Security Advisory (`security/security-advisory`) and SBOM and VEX Policy (`security/sbom-vex-policy`) | Advisory and VEX formats |
| Vulnerability Management Policy (`security/vulnerability-management-policy`) | Consumer-side counterpart |
| Security Policy (`dev/security-policy`) and Incident Communication (`dev/incident-communication`) | Repository policy and customer messaging |

## 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.