Post-provisioning verification checklist before handing a server over

Goal

Give an agent handing over a newly provisioned server a fixed, repeatable sequence of checks, so "provisioning finished" and "ready to hand over" are not silently treated as the same thing.

Prerequisites

Administrative access to the new host; access to whatever monitoring, backup and inventory systems the organization already runs, so the new host's enrollment in each can be confirmed rather than assumed.

Steps

1. Time sync: confirm the host's clock is synchronized and the sync service is active, for example with timedatectl or chronyc tracking on Linux and w32tm /query /status on Windows. A host with a wrong clock will fail certificate validation and produce misleading log timestamps for everything that follows.
2. Name resolution: confirm the host resolves its own intended hostname, and that other systems can resolve it (forward and, where used, reverse DNS), matching the record created during the naming/inventory step.
3. Patch level: confirm the host has the update baseline the organization expects at hand-over time — either fully patched, or intentionally pinned to a known baseline with a documented reason and a follow-up date to patch it.
4. Monitoring: confirm the host actually appears in the monitoring system as a live, reporting node, not just "should have been enrolled by the provisioning automation." A monitoring agent that failed silently to register is a common and easy-to-miss provisioning failure.
5. Backup enrollment: confirm the host (or the data on it that needs protecting) is actually included in a backup job, and that a trial restore capability exists for that backup mechanism in general, not necessarily a full test restore of this specific host on day one.
6. Access: confirm the intended administrative access path works end to end (SSH key or passkey login, RDP with the right credential/PAM policy, whatever the organization's standard is) from a location that mirrors how it will actually be accessed later, not only from the provisioning host itself.
7. Baseline security scan: run whatever baseline hardening or vulnerability check the organization requires before production traffic reaches the host, and record the result alongside the inventory entry so future audits have a starting point to compare against.
8. Record completion: mark the inventory entry as verified, with the date and who performed the verification, so "provisioned" and "verified ready" are distinguishable states in the record.

Expected result

Every item above has a concrete, checked answer (not "should be fine") before the host is described as ready; the inventory record distinguishes a host that only finished provisioning from one that passed this checklist.

Limits and test basis

This is a proposed checklist synthesized from widely documented operational practice, not a standard published by any single vendor; organizations should adapt the specific tools referenced in each step to whatever monitoring, backup and patch-management systems they actually run. It does not replace change-management or security-review processes a specific organization may additionally require before production hand-over.