What evidence should move with a system handover?

A system handover should transfer control evidence, its scope and limitations, the people responsible for ongoing operation, and any unresolved actions or exceptions. Include where records are kept, when they were collected and what changes require further review. An assessment report remains useful evidence of the position examined at that time.

This matters when an uplift project moves into normal operations, a supplier changes or responsibility moves between teams. The control may have been implemented correctly. The practical question is whether the incoming owner can sustain it and explain its current state.

Define what is changing hands

Start with the systems, information, users and locations covered by the handover. Identify dependencies that remain with another team or supplier. A service name alone may not make those boundaries clear.

Then distinguish what is changing from what remains the same. A new service owner may inherit existing technical arrangements but different access to evidence, support or decision authority. Those differences matter even when no technology is being replaced. The handover should make them visible before either team assumes the other has them covered.

Keep the context attached to the evidence

A policy, configuration export or assessment finding is more useful when the incoming owner understands what it demonstrates. Record the relevant scope, collection date, source and known limitations alongside the evidence. Preserve the link between a conclusion and the material supporting it.

Point in time evidence remains valuable. It can explain the basis for an earlier decision and provide a reference for subsequent checks. It should not silently become a claim about a wider environment or a later operating state. If important changes have occurred since the evidence was collected, identify what needs to be checked again.

Agree who does the ongoing work

Completing an uplift project does not remove the need to maintain the controls it introduced. The receiving organisation needs clear ownership of ongoing operation, even where a provider performs particular tasks. Advice, implementation and continued operation can involve different people.

For each significant control, a short handover record can make the responsibilities explicit:

• Who performs the operating task and who covers their absence?
• Who can obtain and review evidence that the task occurred?
• Who resolves a problem that the operating team cannot address?
• Who has authority to decide how an unresolved risk is treated?

Walk through an operating task together

Before closing the handover, choose a relevant task and ask the receiving team to walk through it. For example, can they locate the record of an access review, explain its scope and identify who follows up an unresolved action? This is a practical handover check, not a substitute for validating the control itself.

The walkthrough can reveal missing access, unclear records or dependencies on someone who is leaving. Resolve those issues through the appropriate access and information handling arrangements. Transferring a folder is less useful if the new owner cannot find, interpret or appropriately maintain its contents.

Carry unresolved conditions forward explicitly

Not every issue will be resolved before ownership changes. Record outstanding actions, exceptions, dependencies and evidence gaps, including who is responsible and when the position will be reviewed. Where alternative measures are being relied on, describe them and the conditions under which they need reconsideration.

An entry in a risk register does not perform that ongoing work. The receiving owner needs to know which actions remain active and how changes will be escalated. A clear handover allows the next team to continue from an understood position, with evidence and responsibilities that remain connected to the service being operated.

For advice on control ownership and assurance through a system or service transition, speak with Strategic Cyber about Cyber Risk Advisory.