The Unlicensed Half of the Recovery Plan

Most UK organisations have a recovery plan that has been tested at least once. Very few have a recovery plan whose standby estate has been reconciled against the terms under which that standby is permitted to exist. The distinction is invisible until the day a failover is invoked in anger, at which point a technical success can become a commercial and compliance failure within the same afternoon.

The problem is structural rather than careless. Production estates are licensed, counted and reviewed because they generate invoices and attract attention. Standby estates are built during projects, cloned by replication tools, and then left to sit quietly in a secondary site or a second cloud region. Nobody sends an invoice for a virtual machine that is powered off, so nobody asks whether it is entitled to be powered on.

Why standby drifts out of entitlement

Four mechanisms account for most of the drift.

The first is replication itself. Hypervisor-level replication copies guests wholesale, including the software installed inside them. Whether that copy is licensed depends on clauses written long before the architecture existed, and frequently the answer is that it is licensed only while it remains passive and only for a defined period.

The second is the CMDB boundary. Configuration records are typically scoped to production services, with the recovery site represented as a project artefact rather than a managed estate. Entitlements recorded at the last renewal therefore describe a world that no longer matches the deployment.

The third is metric drift. Licensing metrics keyed to physical sockets, cores or virtual CPUs do not map neatly onto an estate where the DR hosts are sized differently from production, or where orchestration tools spin capacity up at the moment of invocation.

The fourth is the hidden dependency layer. Licence servers, key management services, monitoring agents, backup catalogues and database option packs each carry their own entitlement, and each can independently block a recovery that the plan assumes will work.

Four questions that define passive-use rights

Before touching a spreadsheet, establish what the contract actually permits. For each significant vendor, four questions determine the position.

• Is passive use recognised at all? Some licences make no provision for a standby copy, which means the standby is production use from the moment it is instantiated, regardless of whether it serves traffic. Others require the standby to be at a named location, which creates difficulty for cloud-based recovery where region selection may change.
• What triggers chargeable use? The distinction between a test invocation, a declared disaster and a partial cutover is often decisive. Partial failover, where some services run in the standby while others remain in production, is the most common unlicensed event in practice.
• How long does the concession last? Many programmes allow a defined window, commonly thirty, sixty or ninety days, after which full production licensing applies. Understand the reset rules and whether repeated tests accumulate against a total.
• What must be reported, and to whom? Notification obligations, acknowledgement requirements and record-keeping duties are frequently written into the clause and are frequently ignored. A permitted invocation that was never notified is still a breach.

Building the entitlement register

The register should be derived from the recovery plan rather than from the software catalogue, because the plan defines what must run. Work through each service tier in RTO order and list the assets it depends on: compute, database, middleware, identity, observability, network services and the licence infrastructure itself.

For each asset, capture the vendor, product, edition, licensing metric, quantity entitled, quantity deployed in production, quantity present in standby, and the clause reference that governs standby use. Record the named contract owner and the renewal date. The renewal date matters because it is the only reliable moment at which missing passive-use language can be negotiated from a position of leverage.

Reconciling three sources

The reconciliation is a three-way match between the software asset management export, the DR runbook asset list, and the vendor's own entitlement portal or licence statement. Differences between the three are the findings you want to discover and remediate yourself, rather than have presented to you during a vendor audit or a supervisory review.

Pay particular attention to dormant assets. Scanning tools undercount powered-off guests, and active-passive clusters frequently report as a single active instance. A cold image is not automatically licence-free: it requires an entitlement at the point it is powered on, and the media, installers and activation keys must be available and valid when that happens. Activation that depends on a licence server located in the failed primary site is a recovery dependency in its own right, and one that is rarely documented.

Test invocations as contractual evidence

A test executed in accordance with the clause is simultaneously a capability exercise and an entitlement record. Declare the window through whatever notification process the contract specifies, retain the vendor acknowledgement, and log the start and end times, the assets invoked and the point at which the estate returned to passive. Where partial failover is planned, confirm in writing how the vendor will treat it.

The evidence pack

Assemble a single pack that a risk committee, an auditor or a regulator can read without interpretation. It should contain the entitlement schedule signed off jointly by procurement and IT, extracts of the relevant clauses, the reconciliation report with variances and their remediation status, records of test notifications and acknowledgements, and an explicit statement of residual exposure approved by the accountable owner. That final document is the one that converts an unknown into a managed risk.

Governance rhythm

Reconciliation should run quarterly, aligned to change control so that any alteration to the standby build triggers an entitlement check rather than waiting for the next cycle. Contract review should precede every renewal by a sufficient margin to negotiate passive-use language, defined test allowances and clear reporting obligations into the agreement.

Under the FCA and PRA operational resilience regime, and for in-scope financial entities under DORA, the expectation is that important business services can be delivered within impact tolerance throughout a severe but plausible scenario. Recovery capability that rests on an entitlement nobody can evidence does not meet that expectation. The audit question is not whether the failover worked, but whether you were permitted to perform it.