Before the consultants leave

Imagine taking over a system that prepares supplier-risk summaries. The documents have arrived, then a source feed changes after launch. Who fixes the connection, checks the next summary and approves the update? A useful handover answers those questions. Start with a list of what keeps the service working and who looks after each part. Counting the files delivered will not tell you whether your team can run it.

Brainpool says clients own the project assets it builds and that Cortex runs in the client’s cloud. Fifty One Degrees publishes commitments on client ownership and handing over code and documentation.^1,2,3,4

Make separate entries for custom code, supplier software, outside licences, prompts, test cases and records of the service’s work. Note who owns each, where it is kept, who can access it and what else it needs to run. Owning one asset does not tell you whether the whole service can run without the original supplier. Have the person taking over use the list before signing off the handover.

Pick a change the team is likely to need: an updated rule, a replacement document or a renamed source field. Have the person taking over make the change, run the agreed checks and release it with the supplier watching. Keep the approval and a way to return to the earlier version. For the supplier-risk summaries, check that a changed field still appears in the supporting evidence. It should not quietly disappear.

Next, try an unavailable connection or a summary the reviewer rejects. Who notices, what does the user see and how does the work continue? You are looking for a response the team can use. A promise that problems will not happen is not an answer to what they should do when one does.

Mercury includes handover and support within the scope agreed with the client. Supercharge lists support services and says its work continues after launch.^5,6,7

Ask each firm to turn those commitments into named jobs and help with the exercises your team needs to practise.^5,6,7

Mercury’s site records Cyber Essentials and Cyber Essentials Plus covering the whole organisation. Supercharge states ISO certification, but certificates were not readable in the saved copy of its Trust Center.^8,9,10,11,12

Nexus confirms that a SOC 2 Type 2 report exists. Lowther Register has not inspected what it covers or its reporting period.¹³

Ask for current documents for the service you will use, then follow where its data goes and which accounts have access. Establish who can read information, who can change it and who grants those permissions. Give security and privacy colleagues the details they need to assess the proposed processing. A certificate about the firm does not settle this particular setup. Equally, a trust page we could not read does not prove that the supplier lacks security evidence.

Nexus describes continuing to improve the first version. Mercury limits support to the agreed scope. Data Science UA offers training for the client’s team.^14,5,15

These offers leave different work with you. Ask each supplier to explain the running arrangement rather than assuming every handover means the same thing.^14,5,15

If the supplier stays, agree who monitors the service, handles incidents, makes routine updates and responds when an outside system changes. Separate that work from new features. If your team takes over, name the receiving owner and the skills they need. Keep a route to specialist help, while distinguishing paid changes from fixing work that did not meet the specification you accepted.

Close the handover only when the assets and access match the arrangement you chose. Keep the acceptance evidence and unanswered questions somewhere the operating team controls. The final note should name the next maintainer, open conditions, included support and what must happen when the contract ends. A colleague should be able to read it and say who makes the next change, who pays and how to leave.