Skip to main content
OpsRoadmaps

Checklists / host-patch-and-baseline-readiness

Host Patch and Baseline Readiness Checklist

The unglamorous controls that prevent most host-level incidents: inventory, patch cadence with measured lag, a declarative baseline, and a restore someone has actually performed.

8 steps · 7 required · last reviewed (next review 2027-03-20) · updated 2026-09-20

Related focus areas:SysOps

Sign in to run this checklist

Run this against the fleet as it exists, not the fleet as documented. The gap between those two is the subject of this checklist.

Most items here map directly to enterprise patch management guidance and to configuration benchmarks; the sources are cited on the SysOps page. The item that most often fails is the last one.

  1. Every host is on an inventory with a named owner

    required

    You cannot patch, monitor or decommission a machine you have forgotten, and every estate has one.

  2. Patch lag from release to deployment is measured for critical fixes

    required

    Policy states an intention; the measured lag states what actually happens.

  3. Patch exceptions carry a written reason and a review date

    required

    An undated exception is a permanent decision that nobody consciously made.

  4. Host configuration is expressed declaratively rather than applied by hand

    required

    Reproducibility is what turns a compromised or lost host from a crisis into a rebuild.

  5. Drift from the declared baseline is detected automatically

    required

    Manual fixes that bypass the definition are how a reviewed baseline quietly stops being true.

  6. Backups cover the data that would actually be needed, at a useful granularity

    required

    Backing up the wrong thing thoroughly is a common and expensive discovery.

  7. A restore has been performed from backup and timed within the last quarter

    required

    An untested backup is a belief. This is the item that separates practice from paperwork.

  8. Capacity thresholds are set with an owner rather than discovered at saturation

    optional

    Running out of disk is a predictable failure that is nonetheless a frequent cause of outage.

Run it against your real gaps

A checklist is most useful when you know which controls you are actually missing. A free OpsRoadmaps assessment scores your controls with explainable findings and builds a roadmap from the results.

Assess my stack

Checklists document self-reported practice. Items were last reviewed 2026-09-20 — adapt them to your own environment.