A security advisory becomes useful when you can connect its affected product and version to an asset you actually own, select a documented remedy and verify the result. A headline or severity score is a starting point. This worksheet helps turn a vendor notice into an accountable engineering decision.
Record the source before interpreting the headline
Start with the vendor advisory and its publication or revision date. Record the identifier, product, edition, supported branches and links to remediation. Keep a dated reference: an advisory can be updated after an initial announcement. A social post or community discussion can help you discover a notice, but use the primary notice to establish affected versions and supported actions.
The CISA KEV data repository is an official mirror of its Known Exploited Vulnerabilities catalogue, available in JSON and CSV. It can provide additional prioritisation evidence. Check the specific entry and current guidance; the absence of an entry does not establish that a product is safe. Do not apply a catalogue deadline to your organisation without checking the scope of the requirement and your own response policy.
Match the notice to the deployed asset
| Field | What to record | Evidence |
|---|---|---|
| Product and edition | The exact component in the notice | Inventory entry and vendor terminology |
| Installed version | Release, build and relevant package | Read-only version output or deployment record |
| Affected condition | Version range and configuration prerequisites | The specific advisory section |
| Exposure | Which interfaces are reachable and by whom | Approved configuration and network records |
| Remedy | Supported update or documented mitigation | Vendor instructions and prerequisites |
| Owner | Who decides, implements and verifies | Ticket with a named responsible team |
Do not compare version strings as decimal numbers. Product branches and backported fixes may have different identifiers. If the vendor marks a branch unaffected, keep the evidence for that conclusion. If you cannot establish the installed version, mark the assessment incomplete and assign the inventory work.
Example: a fictitious service, not a live vulnerability
Imagine an advisory for “Example Gateway” that affects one specific release branch when a management feature is enabled. Your inventory lists three gateways. One has the affected branch and feature; one runs a different branch; the third lacks a reliable version record. The decisions are separate: prepare the documented remedy for the first, retain the vendor evidence for the second, and resolve the missing information for the third.
No CVE, version number, exploit or deadline is invented for this example. Its purpose is to demonstrate how an unresolved asset stays visible instead of being counted as patched or unaffected.
Plan the change and define completion
- Choose the vendor-supported action and document prerequisites.
- Agree the change owner, maintenance window and recovery plan.
- Verify the candidate release in an authorised environment using relevant checks.
- Deploy through the normal change process and record the resulting version.
- Verify the affected condition and normal service operation after the change.
- Keep unresolved assets and temporary mitigations in the follow-up queue.
A mitigation and a permanent update can have different maintenance obligations. Record who will revisit temporary measures. Installation success alone does not show that every affected asset changed, and a clean vulnerability scan is one piece of evidence rather than a universal guarantee.
Keep reporting precise
Use separate counts for assessed, affected, remediated, mitigated and unresolved assets. Explain the evidence behind each state and its observation time. For continuing technology coverage, explore the weekly signals and signal archive, then return to the primary advisory before making a production decision.