Not-affected rule: do not close from absence of proof. Close as not affected only when evidence shows the named scope does not meet the affected product, version, feature, platform, reachability, or vendor condition.
Not-Affected Evidence Examples
Close not affected only when the evidence disproves relevance.
Use these examples when a CVE, advisory, scanner result, CPE match, or product-family signal looks relevant but local product, version, feature, platform, reachability, or vendor evidence says it does not apply.
The affected component, edition, module, package, or appliance model is not present in the named scope.
The installed version, branch, package release, or backport status falls outside the vendor affected range.
The vulnerable capability is not enabled, deployed, licensed, reachable, or configured in the required mode.
The evidence names the checked asset group, owner, source, validation date, and review trigger.
Examples
Common not-affected closures and the evidence they need
Product mismatch
Scanner matched the family, not the installed product
The plugin title or CPE points to the vendor family, but inventory and owner proof show a different edition, component, appliance model, package, or plugin set.
Version outside range
Installed version is not in the affected range
The vendor affected range excludes the installed build, branch, package release, or hotfix level observed on the asset group.
Backported fix
Package looks old but contains the security fix
A distro or vendor package keeps the upstream version number while backporting the fix into a branch-specific package release.
Feature disabled
The vulnerable capability is not active
The software is installed, but the affected module, protocol, upload path, legacy mode, role, or integration is disabled or absent.
Platform exception
Advisory excludes this platform or deployment type
The vulnerability applies to a different OS, architecture, cloud plan, appliance generation, SaaS mode, or self-hosted deployment type.
Not reachable
The vulnerable path cannot be reached in this scope
The component exists, but required network path, authentication state, route, port, role, or tenant setting is not available to the attacker class in the advisory.
Bad Closures
Reasons that are not enough by themselves
No scanner finding
A missing scanner result does not prove absence. Scanners can miss credentials, paths, plugins, containers, and branch-specific package state.
Owner thinks it is fine
Owner confidence helps, but closure needs product, version, configuration, vendor, or exposure evidence that someone else can review.
Patch was installed somewhere
One fixed asset does not prove the fleet. Name the checked scope, failed assets, excluded assets, and validation coverage.
Low severity or low EPSS
Lower risk can support monitoring, but it does not prove a product, version, feature, or platform is not affected.
Copy Template
Not-affected closure note
Closure outcome: not affected CVE/advisory: [ID and source URL] Reason: [product mismatch / version outside range / backported fix / feature disabled / platform exception / not reachable] Scope checked: [asset group, business service, environment] Installed product/version/configuration: [observed value and source] Authoritative affected range or exception: [vendor/distro/cloud/source reference] Validation method: [inventory, package manager, owner confirmation, config review, network path check] Residual uncertainty: [none / excluded assets / stale inventory / review needed] Owner and validation date: [team/person, date] Reopen trigger: [vendor update, scanner logic change, exposure change, feature enabled, new asset found]
Recommended route: validate the affected range, capture not-affected evidence, then attach the closure note without claiming broader environment safety.