Fictitious example. ACME Embedded GmbH, its products, records and document IDs are invented for illustration. Use this as a structural model, not as a template to adopt unchanged — and not as legal advice.
PSM-PROC-002 — Vulnerability Handling Process
| Document ID | PSM-PROC-002, rev. 3.0 |
| Owner | Vulnerability Manager (VM) — deputy per QM-ORG-003 |
| Approved by | Managing Director, 2026-07-29 |
| Reference | CRA Annex I Part II; Art. 14 (notification obligations); IEC 62443-4-1 practice DM (orientation); SDL-PROC-001 Phase 0.2/0.3 and Phase 4 |
| Applies to | All ACME products within their declared support period (register: PSM-LST-001), incl. all shipped firmware branches |
| Review | Annually + after every severe incident; annual 24 h/72 h notification drill (record kept) |
1. Purpose
This process ensures vulnerabilities in ACME products are identified, assessed, remediated and disclosed without undue delay across the entire support period, and that the legally mandated notifications (Art. 14) are met. It covers vulnerabilities in our own code and in third-party/OSS components we ship.
2. Intake channels
| Channel | Mechanism | SLA |
|---|---|---|
| External reports | security@acme-embedded.example (monitored working days), /.well-known/security.txt on website, PGP key published | Acknowledge ≤ 48 h |
| CVD policy | Public coordinated vulnerability disclosure policy (web page, linked from every product page): scope, safe-harbour statement, expected timeline (target ≤ 90 days to fix), reporter credit | — |
| Component monitoring | Daily CI dependency/CVE scan of all shipped SBOMs (all supported branches); upstream advisory feeds for registry components (SDL-POL-005) | Triage ≤ 5 working days |
| Internal findings | Test, review, fuzzing findings routed from CI/QA | Same as external |
| Field/support | Support tickets flagged "security" escalate to VM | Same day |
3. Triage and classification
Within 5 working days of intake the VM:
- Confirms/reproduces the issue (with FW Lead as needed) and records it in the vulnerability register (VM-REG, one record per case, ID
VM-YYYY-NNN). - Scores severity (CVSS v3.1) and determines affected products/versions from the SBOMs.
- Checks the two Art. 14 trigger questions — immediately, not at the end of triage:
- Is there evidence of active exploitation?
- Is this a severe incident having an impact on the security of the product? If either is plausibly yes, the notification track (Section 6) starts in parallel — the 24 h clock runs from awareness, not from completed analysis.
- Sets the remediation class:
| Class | Criteria | Target fix-to-release |
|---|---|---|
| Emergency | Actively exploited, or CVSS ≥ 9.0 network-exploitable | Hotfix ASAP, target ≤ 7 days |
| High | CVSS 7.0–8.9 | ≤ 30 days |
| Medium | CVSS 4.0–6.9 | Next scheduled security update, ≤ 90 days |
| Low | CVSS < 4.0 | Bundled, documented decision if not fixed |
4. Remediation
- Fixes are developed on all affected supported branches; delta threat-model check if the fix touches interfaces.
- Security fixes ship as separate security updates, free of charge, via the signed, rollback-protected update mechanism (per SDL-STD-022) — never held back for feature releases.
- If no fix is possible without undue delay: document and communicate mitigations/workarounds to users, then fix.
- Third-party component vulnerabilities: patch/upgrade per SDL-POL-005; where we discover the flaw in an OSS component, we report upstream (coordinated disclosure) and record the report in the case file.
- Each case file retains: report, triage record, CVSS rationale, affected-version analysis, fix MRs, test evidence, advisory, and (if applicable) notification records — retention 10 years.
5. Disclosure
Once the update is available:
- Publish a security advisory (ID
ACME-SA-YYYY-NNN) on the website: affected products/versions, severity, description (detail proportionate — full technical detail only after a reasonable update-uptake window for emergency cases), fixed versions, mitigations, credit to reporter (if desired). - Notify registered customers via the update channel / customer portal.
- Request a CVE ID for vulnerabilities in our own products (via our CNA-of-last-resort route) so downstream users can track them.
- Coordinate publication timing with the reporter per the CVD policy.
6. Art. 14 notification track (applicable obligations from 11 Sep 2026)
Trigger: actively exploited vulnerability in an ACME product, or a severe incident having an impact on the security of an ACME product.
| Step | Deadline (from awareness) | Content | To |
|---|---|---|---|
| Early warning | ≤ 24 h | That an actively exploited vulnerability / severe incident exists; indication whether member states affected | ENISA single reporting platform → CSIRT designated as coordinator + ENISA |
| Notification | ≤ 72 h | General information, nature of the vulnerability/incident, severity/impact assessment, corrective/mitigating measures taken or available, mitigation guidance for users | same platform |
| Final report — vulnerability | ≤ 14 days after a corrective/mitigating measure is available | Description incl. severity/impact; exploitation info where available; corrective measure details | same platform |
| Final report — incident | ≤ 1 month after the 72 h notification | Detailed description incl. severity/impact; threat type/root cause where available; mitigation applied and ongoing | same platform |
| User information | Without undue delay, where appropriate | Inform affected users (and, where proportionate, all users): the vulnerability/incident, risk, and mitigations they can apply | Customers via advisory + direct channel |
Operational rules: the VM (or deputy) is reachable per the on-call rule (0.8); templates for all four submissions are pre-filled at /quality/psm/templates/; the platform account and access are verified in the annual drill; the 24 h early warning is sent on plausible evidence — it must not wait for complete analysis, corrections follow in the 72 h notification.
7. Interfaces to other processes
- SDL-PROC-001 Phase 4: this process is the operational content of activities 4.1–4.5.
- PSM-PROC-003: the step-level operating procedure beneath this process — the standing capabilities that must be in place before intake, and the output and evidence retained at each step. Where the two differ, this document governs.
- SDL-STD-022: defines the support periods, the free-of-charge rule, and the secure update mechanism this process uses to deliver fixes.
- SDL-POL-005 / ENG-REC-031: component monitoring scope and supplier obligations (CON-CLS-007: suppliers must notify us without undue delay).
- SDL-REC-002: operation of this process is audited in the annual internal conformity review.
8. KPIs (reported in the management review)
Time-to-acknowledge, time-to-triage, fix-to-release per class, advisory publication lag, drill results, open cases by age.
Revision history
| Rev | Date | Change | Approved |
|---|---|---|---|
| 2.0 | 2025-11-20 | CVD policy published; CVSS classes introduced | MD |
| 3.0 | 2026-07-29 | Art. 14 notification track finalised (24 h/72 h/14 d/1 m); annual drill mandated; upstream-reporting duty added | MD |