Support & operations · Practice guide

Review software updates with their service impact in mind

Illustrative situation

An application has accumulated library updates, but the team cannot distinguish security-relevant fixes from changes that may alter behaviour. Software often relies on components maintained by other suppliers. Updates can address issues or alter behaviour, so the practice needs an owned review process and proportionate checks. Technical staff should translate priorities into effects on your service.

Healthcare website support desk with a system checklist, telephone and orange notebook.
Know who to call and what help your support arrangement includes.

What this means for your practice

Maintain an update review process that considers vendor guidance, exposure and compatibility. Test material changes against the service's actual workflows before release.

An example to discuss with your team

Use a fictional supplier update that changes information received from a connected tool. Ask whether the agreed checks would reveal the effect on the team using it.

Healthcare website maintenance with infrastructure, a status panel, tools and an operational checklist.
Monitor the useful journey, not just whether a server responds.
Healthcare backup and recovery illustrated by storage copies, an archive folder and a restoration route.
Test whether a backup can restore a usable service.

How to review the arrangement

Ask the maintainer to explain a sample update that changes a connected response. Which user tasks would reveal a problem? Confirm that current vendor guidance informs decisions and that a recovery route exists. The owner needs clear priorities and unresolved risks, not an unexplained list of package names.

Ask what the update changes for your service

Have the maintainer explain each material update in terms of the affected service, relevant supplier guidance and the checks needed before release. The practice should understand why work is recommended without having to compare software package names. Keep a maintained list of important components and responsible owners so an update notice can be connected to the applications that actually use it.

Use a fictional update that changes information received from another tool. Ask which everyday task would reveal the difference and how the supplier will check that task before and after release. Agree a recovery route and record any known limitation. Review postponed updates with their reasons rather than assume every pending item is equally urgent or harmless. The useful decision combines the evidence for updating with the effect of changing a working service. Once the agreed checks pass, retain a concise record so future support staff know what changed and what was verified.

How to check the result

Measure overdue reviewed updates and unresolved compatibility issues.

Turn reading into a next step

Your action checklist

Work through these checks with your team or supplier. Tick the ones you have resolved and leave unknowns open.

Checks to discuss

Record what you know, what is still missing and the answer you need from your team or supplier.

Use project decisions only, without personal, patient or confidential details. Entries stay in this page and are not submitted to Kay & Co. Copy or download before leaving; this page does not save your notes.

Further reading

These sources provide background for the topic. The practice examples and checklist are illustrative planning suggestions from Kay & Co.

Related guides

Need help with this?

Tell us what is getting in the way. Kay & Co. can help you understand the options and turn the next step into something that works for your practice.

Explore support & operations services or discuss your project.

Try the free Healthcare Digital Planner to find your starting priority.