# Vulnerability lifecycle

Connect scan findings to risk, remediation and a same-scope retest.

SecNet.Work | 2026.10 | 2026-10-21

A severity score alone does not determine business priority. Combine asset criticality, exposure, exploitation evidence and existing controls. CISA KEV informs prioritization of exploited vulnerabilities; US federal deadlines do not automatically apply to every organization. This pack extends the scanning guide into finding management.

## Work boundary
Authorized organizational assets and permitted validation. Live exploitation or unauthorized access attempts are not recommended.

## Process

### 1. Validate the finding
Record asset, version, scan time and authorization. Support false-positive decisions with evidence. Distinguish authenticated scan coverage from external observation.

Expected evidence: Asset-bound validation

### 2. Prioritize business impact
Review KEV, exposure and critical dependencies together. Assign remediation timing using organizational policy. Do not automatically deprioritize a lower-score issue on a sensitive access path.

Expected evidence: Justified priority and owner

### 3. Manage the change
Define testing, rollback and maintenance for a patch or configuration change. If correction is infeasible, state what the compensating control blocks and what remains. Do not let exceptions become forgotten permanent records.

Expected evidence: Change or time-bound exception

### 4. Retest the same scope
Verify the finding no longer applies on the same asset and conditions. If an asset disappeared, record a scope change rather than claiming a fix. Convert recurring causes into shared corrective actions.

Expected evidence: Retest and closure rationale

## One control, three perspectives

### Operator
Did remediation work?
Retest the same scope.
Evidence: Before/after result

### Auditor
Is prioritization justified?
Check business impact and source date.
Evidence: Risk rationale and owner

### Leader
Which business process is affected by delay?
Own residual risk and exceptions.
Evidence: Time-bound acceptance and control test

## Evaluate evidence

**Claim:** The vulnerability was remediated.

**Weak support:** A row was removed from the scan report.

**Stronger support:** The change ticket is linked to a same-asset, same-scope retest.

**Rationale:** Disappearance is not remediation; scan permissions or asset scope may have changed.

## Decision desk
A medium-score finding affects a critical exposed asset and appears in KEV.
Start: start

### start
First decision?

- **Prioritize using impact and exploitation evidence** (good)
  You add context to the score. Now check same-asset verification.
  Next: verify

- **Defer to next quarter because the score is medium** (risk)
  Active exploitation and exposure were omitted. Reassess using organizational risk-based prioritization.
  Next: repair

- **Close without a rationale** (incomplete)
  Deferring an open issue is not closure evidence. Record the uncertainty, owner and next verification step.
  Next: revise

### verify
The new scan finds nothing, but the scan account lost its permissions.

- **Restore scan coverage and verify again** (good)
  A measurement gap is not remediation evidence. Validate test permissions and asset matching.
  Next: planned

- **Accept the claim without testing** (risk)
  The initial claim and observed result differ. Support closure with a repeatable check in the same scope, rather than a promise or ticket status.
  Next: revise

### repair
The ticket closed but the asset remains affected.

- **Reopen the finding and assign control and ownership** (good)
  The closure claim conflicts with the result. Link new evidence to the prior ticket and plan correction.
  Next: planned

- **Delete the earlier record and close** (risk)
  Deleting the earlier decision undermines learning and accountability. Link the new action to the prior record and keep the rationale and residual risk visible.
  Next: revise

### supported
This decision is supported by the evidence in the example. Verify closure conditions in your own scope.

### revise
The decision lacks support. Record the rationale and required evidence, then reassess.

### planned
A remediation path is defined. Keep the matter open until implementation and verification are complete.

## Worked example
Entirely fictional.
- Asset: TEST-WEB-01
- Finding: Fictional version finding
- Business impact: Customer portal
- Priority rationale: Exposure + critical service
- Owner / action: Application owner / patch
- Retest: Same permission and scope pending

## Closure checklist
- [ ] Asset and test authorization verified.
- [ ] Business priority justified beyond score.
- [ ] Exceptions have owners and expiry.
- [ ] Closure tested in the same scope.

## Official sources
- [CISA — Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- [NIST Cybersecurity Framework 2.0](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final)

https://secnet.work/learn/toolkits/vulnerability-lifecycle