Hand over the route to recovery, not just the backup file

A handover can include a recent encrypted backup and still leave the successor unable to restore the service. The missing element may be the authorised route to the correct key, the person who can approve its use or the instructions needed to connect it to the backup version.

Recovery work should be planned and controlled. The fictional example below uses synthetic records in a separate test environment. It does not direct a reader to restore over production or copy secret values into a shared document.

Inspect what the successor actually received

The handover package contains backup B-17, a restore procedure and an application administrator account. The backup identifies encryption key K-4. The successor can administer the application but cannot follow the documented key-custody process: its responsible custodian and access route are missing from the handover.

The initial checklist says “backup supplied”, which is true but incomplete. The application administrator role does not automatically grant access to the recovery key. Nor should the team solve the problem by pasting that key into the README.

The organisation’s approved recovery policy requires the custodian to authorise the designated recovery operator. The investigation therefore concerns an incomplete transfer of responsibility and procedure, not a request to remove the encryption boundary.

Complete the owned recovery route

The service owner confirms the custodian, the approved access method and the successor’s recovery role. The handover records the key identifier, custody location reference and authorisation steps without recording the secret itself. The restore procedure is checked against the backup’s format and the intended test environment.

The organisation also identifies an alternative contact under its existing policy so the procedure does not depend on an unnamed person being available. The example does not prescribe a universal custody model; it completes the one the organisation has approved for this service.

RIA’s guidance for managers discusses preparation and practice for continuity. A practical handover should turn that responsibility into a task the next authorised owner can actually perform.

Perform a bounded rehearsal

The controlled fixture contains two synthetic project records and one associated document, with expected identities, relationships and a known document checksum. The recovery operator follows the completed authorisation route and restores that fixture into an isolated review environment.

The operator can open both expected records, retrieve the associated document and confirm its checksum. The document remains linked to the intended project. The second project provides a comparison without that association, so the test checks more than the mere presence of three restored objects.

The ordinary application user still cannot access the key-custody system. The routine backup configuration remains unchanged. The rehearsal has supplied the missing authorised recovery path without broadening every user’s permissions or modifying the production service.

Record what passed and what remains

The completed fictional acceptance states which backup and key identifier were used, who authorised the exercise, which environment received the restore and which records were checked. It records the outcome without exposing keys, credentials or private payloads.

The result establishes that the specified fixture can be restored through the documented route. It does not prove a recovery-time commitment for a full production dataset, the availability of every external dependency or the behaviour of a different backup version. Those requirements need their own exercises if they form part of the agreement.

The owner accepts the handover only after the missing custody responsibility is resolved and the scoped rehearsal is complete. Merely adding a person’s name to a spreadsheet would not have demonstrated that the procedure works.

Check the rest of the handover by task

Ask the successor to locate the domain and hosting owners, explain one integration dependency, publish an authorised content correction and find the route for an exception. Each task should have the necessary permission and a clear boundary for decisions requiring someone else’s approval.

Keep continuing work explicit: supplier renewals, updates, content review, recovery practice and access changes. A successful original build does not assign those responsibilities indefinitely.

The support page and maintenance service describe how to scope that continuing work. A useful handover lets the next owner perform a permitted task and know where their authority ends.