- The patching platform's per-cycle compliance or deployment report
- The asset inventory, so 'applicable devices' is a real number rather than a guess
- The OT maintenance-window calendar and the process owner's availability for sign-off
ATL-019TRACKEREDITORIAL REVIEW COMPLETE
Patch Deployment Tracker
A cycle-by-cycle record of patching as it actually lands: per platform ring, how many patches applied, deployed, failed or deferred (with reasons and compensation), the completion percentage, and how completion was verified — including the window-scheduled OT lane.
Using this artifact
Purpose, inputs, and completion
Purpose. Patching is where security intentions go to be quietly missed: updates approved but not deployed, deployed but failed, deferred but never compensated. This tracker records each cycle as it actually landed, ring by ring, with the failed-and-deferred remainder named and compensated instead of rounded away. Kept honestly for a year, its completion-percentage trend is the difference between claiming a patch process and demonstrating one.
When to use it. Define your rings in the first section, then add one row per platform ring per cycle, filled from the patching platform's report and spot-verified by hand. Treat the deferral columns as first-class content — the reasons and compensating measures are what make the incomplete months defensible. Schedule the OT ring on maintenance windows with process-owner sign-off, and close each cycle by computing completion per ring and moving every failure into the follow-up section with an owner.
- Define the rings once in the first section — pilot, broad, servers, OT-window — and record every cycle against the same rings so the columns stay comparable.
- Fill the deployed and failed columns from the patching platform's report, then verify a sample by hand; deployment tools report their intentions with more confidence than their results.
- Write a reason and a compensating measure for every deferral in the same row — 'deferred' with an empty reason column is a blank check written against future exposure.
- Run the OT lane on windows, never on autopatch: vendor-validated updates, process-owner sign-off recorded per window, and a compensating measure logged for anything the window could not include.
- Compute completion percentage per ring per cycle and carry it forward; the trend line, not any single month, is what tells you whether patching operates.
Keeping it honest
Evidence, validation, and failure modes
- A per-cycle, per-ring deployment record with completion percentages and verification method
- A deferral trail with reasons and compensating measures rather than bare counts
- Signed window records for OT patching, tied to the cycles they served
- Pick five devices from a ring reported 100% complete and check installed-update state directly on each; tracker rows are claims until sampled.
- Sum each ring's applicable-device counts against the asset inventory; devices missing from every ring are the unpatched population the tracker cannot see.
What looks done but is not
- The tracker records patches released rather than patches verified installed, and the two numbers drift apart for months before anyone samples.
- Failed installs are re-queued forever and counted as in-progress, so the same devices sit unpatched across cycles without ever appearing as a problem.
- OT patching is either reckless (autopatch reaches an HMI and stops the line) or absent ('we never patch production') — with nothing written down in either case.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
IT-06 — Risk-based vulnerability managementOT-05 — OT vulnerability managementIT-03 — Technical debt reduction
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 twelve cycles of tracker rows; the completion-percentage trend per platform is the single most persuasive patching evidence a reviewer can be shown.
Full document
Preview — exactly what prints
TRACKER · VULNERABILITY & PATCHv1.0 · REVIEWED 2026-08-06
Patch Deployment Tracker
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
Patching is where security intentions go to be quietly missed: updates approved but not deployed, deployed but failed, deferred but never compensated. This tracker records each cycle as it actually landed, ring by ring, with the failed-and-deferred remainder named and compensated instead of rounded away. Kept honestly for a year, its completion-percentage trend is the difference between claiming a patch process and demonstrating one.
How to use it
Define your rings in the first section, then add one row per platform ring per cycle, filled from the patching platform's report and spot-verified by hand. Treat the deferral columns as first-class content — the reasons and compensating measures are what make the incomplete months defensible. Schedule the OT ring on maintenance windows with process-owner sign-off, and close each cycle by computing completion per ring and moving every failure into the follow-up section with an owner.
Rings and waves
Rings turn patching from a single terrifying event into a sequence of small reversible ones. Define them once; deploy in order; let each ring soak before the next.
Ring definitions
| Ring 1 — pilot (which devices, how many, soak time before Ring 2) | Ring 2 — broad workforce (scope, target days after release) | Ring 3 — servers and infrastructure (scope, window policy) | Ring 4 — OT / production (window-scheduled; vendor-validated updates only) |
|---|---|---|---|
The pilot ring exists to be broken: it should contain the strange laptops, the line-of-business apps, and at least one of everything you fear. A pilot ring of five identical, healthy machines finds nothing, which is why every ring after it then finds everything.
Patch deployment tracker
One row per platform ring per cycle. Keep old rows — the tracker's value is the trend, and the trend needs history.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Cycle / month | Platform / ring | Patches applicable | Deployed | Failed / deferred | Deferral reason and compensating measure | Completion % | Verified how | Date verified |
|---|---|---|---|---|---|---|---|---|
| EXAMPLE: 2026-07 | Windows endpoints — Ring 1 pilot (5 devices) | 9 | 9 | 0 | n/a | 100% | Endpoint manager compliance report + manual check of 2 devices | 2026-07-12 |
| EXAMPLE: 2026-07 | Packaging-line HMIs — Ring 4 (window) | 3 | 2 | 1 deferred | Vendor validation pending for HMI-2; isolated to OT VLAN and monitored until next window | 67% | Manual check during window; process owner signed | 2026-07-26 |
OT window patching
The OT ring runs on the plant's calendar, not the vendor's release day. The discipline is: validated updates, agreed windows, signed outcomes, compensation for whatever waits.
Per-window routine
- Confirm each update is validated by the equipment vendor for your exact model and version before it enters the window plan — untested firmware on a controller is a production gamble, not a patch.
- Agree the window with the process owner and plant leadership in advance, with the rollback plan and time budget written into the window plan.
- The window plan names who can call a stop, and at what point the rollback is triggered rather than pushed through.
- During the window: apply, verify the process runs correctly, and have the process owner sign the outcome before the window closes.
- For anything deferred out of the window, record the compensating measure in the tracker row the same day — segmentation, monitoring, restricted access — and the next window it is queued for.
Failures and deferrals follow-up
Every failed or deferred install from the cycle lands here with an owner. Items that survive two cycles get escalated, not re-queued.
Open items
| Device / system | Patch and cycle | Failure or deferral reason | Compensating measure in place | Owner and resolve-by 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 | System administrator |
| Approval authority | IT leader |
| Review frequency | Updated every patch cycle (monthly for most platforms); ring definitions reviewed semiannually |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain twelve cycles of tracker rows; the completion-percentage trend per platform is the single most persuasive patching evidence a reviewer can be shown. |
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.