Backup promises and restoration evidence in a software service

A backup promise describes the creation and retention of copies. A restoration promise describes the outcome the customer expects when it needs those copies. The difference can determine whether a software service resumes useful work or merely returns a collection of files that still need substantial reconstruction.

For a defence technology business selling a hosted application, recovery belongs in the product offer. Customers need to know what information is covered, what state can be recovered and which party checks that the restored service supports the agreed business use. Storage volume and backup frequency are useful details, but they do not answer those questions alone.

Define the business outcome before the storage feature

NIST's 2010 contingency-planning guide, SP 800-34 revision 1, distinguishes recovery time from recovery point. The former concerns how long a resource can remain unavailable; the latter concerns the point in time to which data can be recovered. It also distinguishes those objectives from the overall business tolerance for disruption and includes validation of restored capability in its reconstitution phase.

Those definitions provide a useful vocabulary for a purchase. A customer may tolerate some delay while the service is restored but be unable to reconstruct certain missing records. Another may accept older data for a temporary reference service while placing greater value on prompt availability. The offer should make the intended outcome clear enough to compare.

A stated objective is not automatically a demonstrated result or a contractual guarantee. The supplier should explain whether the number describes a design target, an observed exercise or a supported service commitment. Each can inform a buyer, but they carry different evidential and commercial weight.

Identify everything the customer needs back

A restored database may be only part of a usable application. The customer may also depend on attachments, configuration, access relationships, audit history and integrations. The product boundary should identify which of those are included in the recovery service and which need action by another party.

Consider a hypothetical supplier-document portal. Returning the documents without their associated permissions and approval history could leave the customer with substantial work before ordinary use resumes. A demonstration that retrieves one file successfully would not establish recovery of that wider workflow.

The buyer can define a representative business outcome in plain language: an authorised user can locate the agreed historical record, understand its status and continue the supported process. The supplier can then explain which evidence supports that outcome and what remains outside the service boundary.

This connects to cloud shared responsibilities. A hosting provider may maintain infrastructure features used by the application vendor, while the finished recovery commitment belongs to the vendor. The end customer needs a clear account of the purchased application service, not only a list of underlying platform capabilities.

Examine restoration evidence at the right scale

An exercise record should identify the service or release considered, the data scope, the starting assumptions, the outcome and the unresolved limitations. A concise summary can be enough for a commercial evaluation if it gives the buyer a defensible understanding of what was demonstrated.

Scale matters. A small sample can establish that a restoration mechanism works for that sample while leaving questions about a larger customer dataset. An exercise conducted with a prepared environment may not include the time required to obtain that environment during an actual disruption. The record should preserve those boundaries.

The customer should also distinguish a fully observed result from an estimate assembled from several stages. Both may be useful for planning. An estimate becomes misleading if it is presented as a completed end-to-end recovery exercise. The supplier can explain the basis without promising that every future incident will reproduce the same timing.

Where an exercise identifies a problem, the buyer should look for the resulting action and its current status. A documented improvement can add confidence in the service. A polished summary that removes all limitations gives the customer less information about whether the observed outcome fits its needs.

Separate backup protection from recovery readiness

The NCSC's November 2024 backup principles focus on resistance to destructive ransomware. The guidance says that a solution still needs regular testing and monitoring within the organisation's overall backup system. It also states that protecting against destruction does not itself address the separate threat of stolen information being used for extortion.

For purchasing purposes, that means a protection feature should remain attached to the outcome it supports. A service can provide valuable protection for stored copies while requiring additional work to demonstrate restoration of the customer's application. The supplier should explain both parts of the offer.

The buyer does not need sensitive recovery procedures during an initial sales review. It does need a statement of the covered scenario, the relevant dependencies and the evidence that supports the proposed service. A backup feature described as resilient should not silently become an assurance covering every cause of disruption.

The distinction also helps suppliers avoid exaggerated marketing. They can describe the protection implemented, the recovery exercises completed and the customer responsibilities remaining. Those are concrete claims a buyer can assess without relying on a broad promise that data can never be lost.

Allocate the people and decisions

Recovery involves more than technical work. Someone needs to decide when the relevant process begins, maintain the customer conversation and confirm that the restored service is suitable for normal use. Those roles should be part of the commercial arrangement, especially when the application depends on several suppliers.

A customer-managed integration can affect the final outcome even when the application vendor has completed its own recovery work. The parties should know who verifies that integration and how unresolved dependencies are reported. Otherwise the provider may describe its service as restored while the customer still cannot perform the purchased workflow.

The support offer should also explain the availability of the necessary staff. A recovery objective that assumes immediate access to a specialist team needs a corresponding service arrangement. The buyer should not infer that ordinary business-hours support includes every form of assistance required outside those hours.

Our guide to continuing software assurance examines how evidence stays relevant as a product changes. Recovery evidence needs similar attention when data structures, hosting arrangements or important integrations change. An exercise from an earlier product architecture should be reviewed before being used to support the current offer.

Include retention and exit in the comparison

A customer may need to recover a record after discovering a problem much later. The proposal should therefore explain the retained history, the distinction between customer-requested retrieval and service-wide restoration, and any material cost or scope differences between those activities.

Ending a subscription creates another boundary. The customer should know when access to retained copies ends and what export or handover is available before then. A backup held for the provider's own recovery purposes may not constitute an accessible customer archive. The purchase should state which service is actually offered.

These details affect total adoption cost. An apparently inexpensive application may leave the customer to arrange additional retention, recovery validation or specialist support. Another may include those services in a higher subscription price. Comparing the same outcome makes the tradeoff visible.

A credible restoration offer defines the recoverable business state, the evidence supporting it and the responsibilities needed to reach it. Suppliers can use that structure to make their continuing service concrete. Buyers can use it to distinguish stored copies from a demonstrated and supportable route back to useful work.