An investigation can accumulate an internal incident number, product names, build identifiers, supplier cases, advisory references, and vulnerability records. The reporting problem is not to force every reference into one field. It is to preserve which reference identifies the case, which identifies the affected product, and which points to supporting evidence.
Begin with the governing content
For an actively exploited vulnerability, the 72-hour Article 14 notification includes available general information about the product, the nature and details of the exploitation and vulnerability, and corrective or mitigating measures taken or available. For a severe incident, the notification includes available general information about the incident’s nature, an initial assessment, and corrective or mitigating measures.
Those content duties make product and case identity operationally important. They do not establish that a particular external identifier must already exist, and they do not justify delaying an early stage while a team waits for one.
Give the case one internal anchor
Assign a neutral, stable case identifier when triage opens. Use it across the technical investigation, legal decision, reporting stages, user communications, and evidence index. Avoid encoding a tentative legal conclusion or confidential product name in the identifier itself.
The anchor should point to records rather than absorb them. Link the manufacturer entity, reporting track, awareness decision, deadline calculations, affected product set, and submission snapshots. If two alerts are later joined, retain both original references and document the merge decision. If one case splits into independent product events, create new anchors and preserve the relationship.
Separate product identity from case identity
Maintain a canonical manufacturer product record with the commercial name and the technical coordinates needed to distinguish affected scope: version, build, firmware, model, package, configuration, or another release marker used by that product.
Aliases belong in the mapping layer, not in place of the canonical record. A distributor label, repository package name, and internal codename may refer to the same product, but a reviewer should be able to see the evidence for that conclusion.
Type external references
Store each external reference with a type, issuing organisation, checked date, and link to the supporting record. A vulnerability identifier, supplier ticket, security advisory, authority reference, and submission receipt serve different purposes. A flat list makes collisions and mistaken substitutions hard to detect.
Treat an external vulnerability identifier as a cross-reference, not as the manufacturer’s product analysis. If it is absent, pending, disputed, or later corrected, preserve that state and the evidence checked. Do not invent a placeholder that resembles an issued identifier.
Reconcile scope before every stage
Before an approved handoff, compare the current product set with the preceding snapshot. Mark each product or version as confirmed, added, removed, or unresolved, and record the evidence for a change. Reconcile the same case anchor across the approval record, submitted snapshot, and receipt.
A good identifier map lets a reviewer answer three separate questions without consulting the reporter: which legal manufacturer owns the case, which product releases the current evidence reaches, and which records prove what was known at each reporting stage.
Continue this workflow with the product-version matrix and the staged evidence trail.