The old accounts package still opens. The laptop still starts. Nobody has complained about the router. Those are useful observations, but none tells you whether the software is still receiving security fixes.
An end-of-support date can turn a working piece of equipment into a problem for Cyber Essentials. Finding it a week before your assessment leaves you choosing between a rushed replacement and a difficult conversation about scope.
Start with the software that would be awkward to replace. The practical planning steps below are suggestions for running that job, rather than extra assessment requirements.
Find the date that matters
Look for security support for the exact product and version you use. A helpdesk contract, a valid licence and a working download link don't establish that security fixes are still being produced.
The IASME glossary defines supported software by a vendor's commitment to supply security updates and provide a future end date. Support can come from another vendor if it can modify the original software to make those fixes.
For each important product, save the vendor's support page alongside these details:
- Product name, version and edition.
- Devices or services where it is installed.
- Security support end date.
- Any support subscription the business relies on.
- Person responsible for replacing or upgrading it.
Check the edition carefully. Two products with similar names may have different support dates. If extended support is involved, ask for confirmation that your organisation and installed version are covered. A quote for a subscription isn't evidence that it has been activated.
The IASME software and system support hub is a useful starting point for finding support information. Follow through to the vendor's current terms before making a purchasing decision.
Ask what would stop working
Replacing an operating system may be straightforward until somebody mentions the label printer, payroll export or specialist drawing package that depends on it.
Sit with the person who uses the system and watch a normal piece of work. Ask what they open, which files they import, what equipment connects to it and where the finished result goes. Write down the awkward steps as well as the main application.
Imagine a small distributor whose older stock application prints shipping labels. A replacement plan that only checks whether the new software starts could miss the printer driver and the courier file format. A useful trial would take an order through to a correctly printed label and an accepted courier upload.
Choose a few representative tasks like that. You need enough detail to approve the replacement with confidence, without turning a small upgrade into a months-long documentation exercise.
Choose a route and give it an owner
Use a short decision record so approval doesn't get confused with completion:
| Situation | Practical next step | What closes the action |
|---|---|---|
| A supported upgrade is available | Check compatibility, agree cost and schedule the change. | The supported version is installed and normal work has been tested. |
| Nobody needs the application | Arrange removal from every affected device. | Confirm the old installation and any automatic jobs have gone. |
| A replacement changes the work | Test representative business tasks with the people who do them. | The owner accepts the workflow and support information is saved. |
| Isolation is being considered | Ask the provider to describe the technical separation and consult the Certification Body. | Record the agreed boundary and how it is maintained, without assuming that isolation repairs the software. |
This is a planning aid, not a list of exceptions to the scheme requirements.
For software you still need, investigate a supported upgrade or replacement. For software nobody needs, arrange removal and check that it has disappeared from the affected devices.
Give each item one named owner, a next action and a date. Keep cost approval separate from technical completion. A replacement marked as approved in a budget spreadsheet may still be sitting in its box.
Your plan could read:
- Finance manager confirms that the new package can produce the required reports.
- IT provider installs the supported version on a test device.
- Accounts assistant checks the month-end workflow using an agreed test copy.
- Business owner approves the changeover after the results are recorded.
These are example responsibilities, not prescribed job titles. In a two-person business, the same person might cover several steps. What matters is that each decision has somewhere to go.
Treat isolation as a technical decision
IASME's security update guidance explains that unsupported software must be removed, or taken out of assessment scope using a properly segregated and separately managed subset that prevents traffic to and from the internet.
Moving a computer into a cupboard doesn't achieve that. Nor does a promise that its user won't open a browser. If you are considering isolation, ask your IT provider to describe the actual network controls and how their operation will be checked.
The IASME scope guide explains the need for technical separation when certifying a subset. Agree the proposed boundary with your Certification Body before relying on it. A partial scope also needs an accurate description, so customers can understand what the certificate covers.
Write down how information will enter and leave the isolated system, who can change its connections and how future support will work. Those practical questions often reveal why keeping an old application creates continuing work. Isolation doesn't repair its unsupported software or replace a longer-term migration plan.
Finish the change properly
Before you close the task, have someone carry out the agreed business checks on the replacement. Record the version now in use and where its security updates come from.
Check the less visible leftovers too. Is the old application still installed on another laptop? Does a shortcut launch the retired version? Has an automatic job continued to use the old server? Are staff keeping a second copy because nobody showed them the new process?
Keep the support evidence somewhere the next person can find it, then put the next decision date in your normal planning calendar. Choose that date by working backwards from the work involved. Buying a replacement laptop might need far less notice than changing the application that runs your orders.
Once the supported system is in place, keep it current. Our fourteen-day patching workflow covers the separate job of checking that required fixes actually reach the devices using it.