- Scanner output, vendor advisories, and any penetration-test findings from the period
- The asset inventory, for affected-asset identification and criticality
- Knowledge of what is internet-exposed or reachable from untrusted networks
- Written remediation SLAs per risk rank (or set them in the first session using this register)
ATL-018REGISTEREDITORIAL REVIEW COMPLETE
Vulnerability Register
The single working list of known weaknesses: each finding with its scanner severity and your own risk rank, an explicit patch / compensate / accept decision, an SLA-driven due date, and — for OT findings — whether a maintenance window is required and what compensates until then.
Using this artifact
Purpose, inputs, and completion
Purpose. Scanners produce findings faster than any small team can fix them, so the real work is deciding — visibly, defensibly — what gets fixed first, what gets compensated, and what gets accepted by someone with the authority to accept it. This register is where those decisions live: one row per finding, your risk rank beside the scanner's severity, and a due date that follows from a written SLA rather than from whoever shouted last. For OT findings it adds the two columns that make production remediation honest: window required, and compensation until then.
When to use it. Triage new findings into the register weekly, ranking each with the criteria in the first section before assigning a due date. Work the register from rank one down; run the monthly aging review on everything open past its SLA and escalate or re-decide each. Coordinate every OT row with the process owner — remediation timing on production equipment is a joint decision with plant leadership, and the compensating-control column is what keeps the deferral defensible in the meantime.
- Enter findings from every source into the same register — scanner, advisory, pentest; three lists in three formats is how the worst finding hides between tools.
- Rank risk yourself rather than inheriting the scanner's number: exploitability, exposure, and asset criticality together outrank a raw CVSS score.
- Make the decision column explicit for every row — patch, compensate, or accept — with accept reserved for a named person's signature, never a default reached by silence.
- For OT findings, record whether remediation needs a maintenance window and what compensates until that window arrives; an OT finding with no window and no compensation is an open decision, not a plan.
- Attach closure evidence when closing — a post-fix scan, a version screenshot, a config export; a register that closes rows on someone's say-so converges on fiction.
Keeping it honest
Evidence, validation, and failure modes
- A dated register spanning all finding sources, with per-row decisions and owners
- A record of risk-based prioritization visibly departing from raw scanner severity where justified
- Closure evidence tied to each resolved finding, and a compensation trail for deferred OT fixes
- Rescan (or manually verify) three rows marked closed this quarter; a finding that reappears at the same version closed on paper only.
- List every open row past its SLA due date and check each has an escalation note; silent SLA breaches mean the SLA is decorative.
What looks done but is not
- The register is the scanner export, re-sorted: thousands of unranked rows nobody reads, while the one exploited-in-the-wild finding sits on page forty.
- Accepted risks are undated and unsigned — 'we decided to live with it' with no named decider, no expiry, and no re-review.
- OT findings are marked deferred-to-window with no compensating measure, which turns 'we will patch at the outage' into 'exposed until further notice'.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain closed rows with their closure evidence for at least two years; the register's history is the proof that remediation follows risk, not convenience.
Full document
Preview — exactly what prints
REGISTER · VULNERABILITY & PATCHv1.0 · REVIEWED 2026-08-06
Vulnerability Register
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
Scanners produce findings faster than any small team can fix them, so the real work is deciding — visibly, defensibly — what gets fixed first, what gets compensated, and what gets accepted by someone with the authority to accept it. This register is where those decisions live: one row per finding, your risk rank beside the scanner's severity, and a due date that follows from a written SLA rather than from whoever shouted last. For OT findings it adds the two columns that make production remediation honest: window required, and compensation until then.
How to use it
Triage new findings into the register weekly, ranking each with the criteria in the first section before assigning a due date. Work the register from rank one down; run the monthly aging review on everything open past its SLA and escalate or re-decide each. Coordinate every OT row with the process owner — remediation timing on production equipment is a joint decision with plant leadership, and the compensating-control column is what keeps the deferral defensible in the meantime.
How to rank risk here
The scanner's severity is an input, not a verdict. Rank each finding with three questions, and let their combination — not the CVSS number — set the order of work.
Three ranking questions
- Exploitability: is this finding known to be exploited in the wild, or is public exploit code available?
- Known-exploited findings on exposed systems go straight to rank 1, whatever the CVSS score says.
- Exposure: is the affected asset reachable from the internet, from the general user network, or only from a segmented zone?
- Asset criticality: does the asset hold sensitive contract information, run production, or sit in the path of either?
A medium-severity finding on the internet-facing VPN appliance outranks a critical-severity finding on an isolated lab machine — and the register should show exactly that inversion, because it is the evidence that ranking happens at all. Write the rank scale you use (1–4 works) and the SLA attached to each rank in the decisions section.
Vulnerability register
One row per finding. The severity column records what the tool said; the rank column records what you decided; the gap between them is where the thinking shows.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| ID | Finding | Affected assets | Source | Scanner severity | Risk rank (yours) | Exposed? | Decision | Window required? (OT) | Compensating control | Due per SLA | Owner | Status | Closure evidence |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE: VUL-2026-014 | VPN appliance firmware — known exploited flaw | Edge VPN appliance | Vendor advisory | Critical | 1 | Yes — internet-facing | Patch | No | n/a | 2026-08-09 (72h SLA) | Network admin | In progress | Post-patch scan + version screenshot |
| EXAMPLE: VUL-2026-019 | Unsupported OS on packaging-line HMI | HMI, packaging line | Scanner | High | 3 | No — segmented OT zone | Compensate | Yes — next planned outage 2026-12 | Removed from business VLAN; USB blocked; watched by OT sensor | 2026-12-15 (window) | OT engineer | Compensated | Firewall rule export + window plan |
OT rows are scheduled with the plant, compensated until then
Never patch or rescan production equipment outside an approved maintenance window with the process owner's agreement and vendor guidance where the equipment is vendor-supported — an unscheduled fix that stops the line does more operational damage than most of the findings it closes. Every deferred OT row carries a compensating measure in its column until the window arrives; deferral without compensation is just exposure with a calendar entry.
Decisions and SLAs
Write the SLA per rank once, here, so due dates stop being negotiations. Acceptance is a signature, not a shrug.
Remediation SLAs by rank
| Rank 1 due within (e.g., 72 hours) | Rank 2 due within (e.g., 14 days) | Rank 3 due within (e.g., 45 days, or next window for OT) | Rank 4 due within (e.g., 90 days or accept) |
|---|---|---|---|
Risk acceptances (each one signed and dated)
| Finding ID | Why accepted, and compensating measure if any | Accepted by (name, role) | Expiry / re-review date |
|---|---|---|---|
Closure and follow-ups
A row leaves the register through evidence, not optimism. Monthly, everything past its SLA lands here with an escalation.
Aging review — open past SLA
| Finding ID | Days past due | Blocker | Escalated to / decision | New date |
|---|---|---|---|---|
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader |
| Approval authority | Executive sponsor |
| Review frequency | Weekly triage of new findings; monthly aging review of everything open past its SLA |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain closed rows with their closure evidence for at least two years; the register's history is the proof that remediation follows risk, not convenience. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.