How it is created — PSM-PROC-003 Vulnerability Handling: Detailed Operating Procedure

1. Why this artifact exists

PSM-PROC-002 is the document you show a customer. This is the one you work from at 02:00.

The gap between them is not detail for its own sake. A vulnerability process fails in two specific places, and neither is visible at policy level. The first is preparation: the intake address, the SBOM, the signing key, the reporting-platform account and the test plan all have to exist before the first report arrives, and nothing in a policy document forces anyone to check that they do. The second is evidence: an assessor does not ask whether you triage, they ask to see the triage record for case VM-2026-014. A process written without an evidence column produces compliant behaviour and no proof of it.

So this document does two things a policy cannot. It pulls the standing capabilities into an explicit P0 layer that is reviewed annually as a unit. And it names, for every single step, the artifact that step leaves behind.

2. Inputs

• The approved PSM-PROC-002. This procedure elaborates it; it does not restate or contradict it. Write the policy first, or you will end up with two documents that disagree about the acknowledgement SLA.
• The [product register](/resources/examples/psm-lst-001) with support-period end dates and, per product, the branches still receiving updates.
• The SBOM and the hardware component list. The hardware list is the one teams forget: MCU errata, PHY and switch-chip advisories, secure-element bulletins. If your incoming-vulnerability matching runs only against software, half your embedded attack surface is unmonitored.
• The [per-product risk assessment](/resources/examples/sec-ra-s300), because four capabilities in this procedure scale with risk and the risk assessment is what justifies the choice.
• The release and update mechanism specification — what signed, free-of-charge, separately-shipped delivery actually means for your hardware.

3. Steps

1. Write the P0 layer first, as capabilities rather than intentions. Eight of them: internal policy, public CVD policy, opsec for unfixed vulnerabilities, communication channels, product identification, component inventory, test and review plan, distribution mechanism. Each gets a deliverable and an evidence line. If an item has no evidence, it is not a capability yet.
2. Separate hardware from software identification. One scheme, two identifier sets. This is what lets an advisory say "firmware 2.4.1 on hardware revision C" instead of triggering a conversation about a recall.
3. Decide the risk-scaled options per product and record them. Full-depth versus top-level SBOM, supplier hashes, encrypted reporting channel, machine-readable advisories. Each is applied or not applied with a justification — an applicability statement with blank justifications is the finding an auditor will write up, not the decision itself.
4. Give every pipeline step the same four fields: trigger, activities, output, evidence. The uniformity is the point; it makes an omission visible at a glance.
5. Record the not-applicable outcome as a result. "We looked, and this CVE does not affect us" is a triage output that needs a written justification, not a case you close silently. It is also the cheapest finding to avoid.
6. State once, explicitly, that the triage records are the systematic documentation the CRA requires. Otherwise someone will build a second documentation system to satisfy a duty the register already discharges.
7. Put the awareness timestamp in the register at first suspicion. Not at confirmation. The 24-hour clock is measured from a moment, and if that moment is not written down at the time, you will be reconstructing it under pressure and in your own disfavour.
8. Fix the four-eyes rule in writing: the developer of a fix is not its sole verifier. In a small team this is the only separation of duty that survives contact with reality, so name it rather than implying it.
9. Write the deferred-disclosure path with its conditions attached. Publishing late is legitimate in narrow circumstances; publishing late without the documented assessment is not. Conditions and template together, or the path will be used without them.
10. Close the loop with an annual review that consolidates. One review covering test-plan maintenance, risk-assessment assumptions, KPI performance and the decision whether the product risk assessment needs updating. Four separate annual reviews get skipped; one gets held.

4. Done when

• Every P0 capability names an artifact that exists today, not one that is planned.
• Incoming vulnerability information is matched against both the SBOM and the hardware component list.
• Each pipeline step names its output and the record retained as evidence.
• The applicability statement is filled in for at least one real product, with justifications written.
• The not-applicable case, the deferred-disclosure case and the third-party-fix case all have a documented path.
• The awareness timestamp has a defined starting condition and a place in the register.
• The KPI table has numbers in it, and a review that looks at them.

5. Common mistakes

Writing this instead of the policy rather than beneath it, so the two disagree on timelines. Monitoring software components and ignoring hardware advisories. An applicability statement where every option is "applied" because nobody wanted to justify a "not applied" — that is not a risk-based decision, it is an unexamined one. Steps with outputs but no evidence, which read as complete and audit as empty. And starting the 24-hour clock at confirmation instead of at suspicion, which quietly converts a met deadline into a missed one.

6. In TRA Studio

This is the level at which requirement assignment stops being bookkeeping. Map the P0 capabilities and the P1–P5 steps onto the post-release activities of your Secure Lifecycle, then assign the Annex I Part II requirements to individual steps rather than to the process as a whole. Requirements assigned to a step inherit that step's owner and evidence; requirements assigned to "vulnerability handling" inherit nothing and are indistinguishable from requirements nobody has thought about yet.