What the Template Carries: Attesting Virtual Machine Baselines as Recovery Evidence

Recovery plans tend to focus on the dramatic elements: site loss, storage replication, network reconnection and the order in which services return. The virtual machine template sits further down the list, if it appears at all. It is usually described as a build convenience, a starting point maintained by the platform team. That description is no longer adequate. In a regulated estate, the template is a dependency with a history, a supply chain and a compliance posture of its own. If it is not attested before recovery, the recovery estate may boot successfully while inheriting a baseline that nobody can defend.

From build convenience to recovery dependency

A template is not a neutral empty shell. It contains an operating system build, patch state, management agents, monitoring hooks, backup clients, security tooling, drivers for storage and network devices, certificate stores, local policy, time synchronisation settings and sometimes local accounts or service identities. Each of those elements can drift. A template that was acceptable when it was created may be several patch cycles behind, may carry an agent version that no longer reports correctly, or may include a driver that is incompatible with the recovery hypervisor. None of this necessarily prevents a virtual machine from starting. That is precisely the problem.

The recovery estate can therefore produce a running system that is not a compliant system. It may be missing the endpoint protection agent that the security team relies on, or carrying a certificate that expired months ago, or reporting to a management plane that was decommissioned. The operational resilience risk is not only that recovery fails. It is that recovery appears to succeed while the evidence trail is weak.

A register with provenance, not a folder of artefacts

The first control is a template register that records provenance rather than merely storing files. For each template, the register should identify the source media or vendor image, the build pipeline that produced it, the owner and approver, the creation and review dates, the operating system version, the patch baseline, the included agents and drivers, and the hash or signature of the delivered artefact. Where a template is derived from another, the lineage should be explicit. A clone of a clone is still an inherited artefact, and inheritance is exactly what attestation is meant to expose.

The register should also distinguish between a master template, a published template and a recovery-specific copy. Many estates hold several versions across hypervisor clusters, disaster recovery platforms and departmental build shares. Without a controlled register, the recovery team may select the most recent file rather than the approved baseline. The register removes that ambiguity by making the approved recovery template a named, versioned object with an evidence record attached.

Parity is a property to prove

Attestation is not a document review exercise. It is a comparison between what the template contains and what the organisation says it should contain. A practical attestation report should cover patch currency against the agreed baseline, agent and tooling versions, driver compatibility with the target recovery platform, certificate validity and trust store contents, local policy settings, time and locale configuration, and the presence or absence of monitoring and backup hooks. Where the template differs from the production baseline, the difference should be recorded as an approved exception or corrected before the template is released to recovery.

The comparison should be repeatable. Manual screenshots of a template property page are weak evidence because they are difficult to reproduce and easy to misread. A scripted or pipeline-generated report, stored with the template hash, gives the recovery team and the auditor a consistent view. The objective is not to prove that the template is perfect. It is to prove that its condition is known, approved and aligned with the recovery requirement.

The build path is part of the control

A template that is patched by hand after publication is no longer the artefact that was attested. The build path should therefore be controlled: templates should be produced through an immutable pipeline, signed at output, and released into a controlled library. Manual changes should be exceptional, logged and followed by re-attestation. Where a template must be customised for a recovery platform, that customisation should be expressed as code or a documented build step, not as an undocumented adjustment made during a rehearsal.

This matters in UK regulated estates because operational resilience obligations depend on evidence, not assertion. A firm may be able to show that it has a recovery plan, but it also needs to show that the plan operates from controlled inputs. The template is one of those inputs. Treating it as a controlled build artefact brings it into the same governance envelope as the applications and infrastructure it supports.

An evidence pack for the recovery rehearsal

The attestation should culminate in a recovery evidence pack. At minimum, it should contain the template manifest, signed hashes, the patch and configuration parity report, the approved exception list, a test instantiation log, confirmation that management agents checked in after boot, certificate status at the time of test, and the identity of the approver. The pack should be stored alongside the recovery plan and referenced in the rehearsal record. If a template changes, the pack should be regenerated rather than amended.

The rehearsal itself should include a template attestation step before application recovery begins. That step need not be lengthy. It should confirm that the template selected matches the approved version, that its hash is correct and that the attestation is current. If the check fails, the rehearsal should stop or record a formal deviation. A recovery that proceeds on an unattested template is a recovery with an unquantified baseline.

An operating rhythm that survives contact with change

Templates age quickly. A quarterly review is a reasonable default for stable estates, with re-attestation triggered by major patch cycles, hypervisor upgrades, agent changes, certificate renewals and changes to the recovery platform. Superseded templates should be retired from the recovery library rather than left available for convenience. The register should show which templates are approved for recovery, which are quarantined and which are awaiting review.

The ownership question also needs an answer. Platform teams build templates, security teams set baseline requirements, and resilience teams depend on the outcome. A named owner should be accountable for the register and the attestation cycle, with clear escalation when a template falls out of policy. That is not bureaucracy for its own sake. It is the difference between a recovery estate that builds from a known-good baseline and one that inherits whatever happened to be in the library.

The template is a small object with a long memory. Attesting it before recovery is a modest control that protects a much larger claim: that the recovery estate is built from evidence rather than assumption.