How it is created — PSM-PROC-002 Vulnerability Handling Process

1. Why this artifact exists

Annex I Part II is the half of the CRA that has no release date. A product can ship fully compliant and fall out of compliance six months later because nobody triaged a report, or because an actively exploited vulnerability was analysed carefully for four days instead of being reported within twenty-four hours.

This is also the document that gets written too late. The intake address, the disclosure policy and the reporting-platform account have to exist before they are needed — a contact point improvised during an incident is not a contact point. Writing it early costs a day; writing it during a live exploitation event costs the deadline.

2. Inputs

• Your product register with support-period end dates and, per product, the branches still receiving updates. Without it, "affected versions" is guesswork.
• The SBOMs of everything shipped, wired into a scanner — most of your vulnerabilities will arrive as component CVEs, not as researcher reports.
• The support and update policy: what "free of charge", "separate from feature updates" and "secure delivery" mean concretely for your products.
• Your supplier terms: whether component vendors owe you notification, and how fast.
• The reporting route: an ENISA single-reporting-platform account, and the CSIRT that coordinates for you.

3. Steps

1. Name one owner and one deputy. Every deadline in this process is measured in hours. A process whose owner is on holiday has no owner.
2. Open the intake channels first, then describe them: a monitored security@ address, a security.txt, a published PGP key, and the internal routes (CI scan findings, support tickets flagged security). Give each an SLA — acknowledgement within 48 hours is a reasonable public promise.
3. Publish a coordinated-disclosure policy with scope, a safe-harbour statement for good-faith researchers, an expected timeline, and reporter credit. Without safe harbour you get fewer reports; you do not get fewer vulnerabilities.
4. Write triage as a fixed sequence with a deadline — confirm, register, score, determine affected versions from the SBOM. Five working days is a defensible target.
5. Put the two notification questions at the start of triage, not the end*: is it actively exploited, and is this a severe incident? If either is plausibly yes, the notification track starts in parallel. The 24-hour clock runs from awareness, not from a finished analysis — this single ordering decision is what makes the deadline achievable.
6. Define remediation classes with target fix-to-release times and tie them to something objective (CVSS plus exploitation status). Emergency, high, medium, low is enough; what matters is that each class names a number you can be held to.
7. Say what happens when you cannot fix in time. Publish mitigations, then fix. "Undue delay" is judged against what you did in the meantime.
8. Write the disclosure step as a sequence with an ID scheme — advisory per fixed vulnerability once the update is available, affected and fixed versions, mitigations, reporter credit, and a CVE request so downstream users can track it.
9. Tabulate the Art. 14 track with the four submissions, their clocks, their content and their recipient. Pre-fill the templates and store them where the on-call person will find them at 02:00.
10. Mandate a drill. Once a year, run the 24 h / 72 h path end to end — platform access, credentials, templates, decision authority. A reporting route nobody has ever used is an assumption, not a capability.
11. Add KPIs and a retention rule. Time-to-acknowledge, time-to-triage, fix-to-release per class, open cases by age; case files retained for the statutory period.

4. Done when

• Intake channels are live and monitored, with published response times.
• Triage has a deadline, an owner and a register with one record per case.
• The exploitation / severe-incident question is asked at intake.
• Every remediation class has a target time, and the "no fix yet" path names mitigations.
• The four notification submissions exist as pre-filled templates, and the platform account has been used in a drill.
• Component vulnerabilities are covered, including the duty to report upstream what you discover.
• Management has signed a dated revision.

5. Common mistakes

Treating this as a document rather than a rota — no deputy, no on-call rule. Waiting for complete analysis before the early warning. Covering your own code but not the components you ship. Announcing a fix before the update is actually available to users. And leaving old supported branches unpatched because the fix landed only on the current one.

6. In TRA Studio

Map this process onto the post-release activities of your Secure Lifecycle and assign the Annex I Part II requirements to them — that is where "we handle vulnerabilities" turns into named activities with owners and evidence. Requirements left unassigned here are the ones that bite after release, when the product is already in the field and the technical documentation is frozen.