Cyber Essentials and your line-of-business software: what an assessor will actually ask

Most advice about Cyber Essentials is about firewalls, passwords and laptops. That is fair, because those are the bulk of the scheme. But there is a question that catches out a surprising number of small businesses: what about the software the business actually runs on?

The old Access database, the Sage version nobody dares upgrade, the bespoke system written by a contractor in 2009. This guide covers how those fit into Cyber Essentials, what an assessor is likely to care about, and what your options are when one of them is a problem.

It is general guidance, not a compliance opinion. Your certification body has the final say on your own scope.

What Cyber Essentials is, briefly

Cyber Essentials is a UK government backed scheme, run by the National Cyber Security Centre (NCSC) with its delivery partners, that checks a small set of basic technical controls. The NCSC overview explains the scheme and the levels. The controls cover firewalls, secure configuration, user access, malware protection and security update management.

Customers, insurers and public sector buyers increasingly ask for it, so it often arrives as a request from someone else rather than a project you chose.

Why business software comes into it

Cyber Essentials is not an audit of your software design. Nobody will read your code. What the assessor looks at is the devices and software in scope, and whether they are supported and kept up to date.

In practice that means two things matter for your line-of-business systems.

Is the software still supported by its vendor? Software that no longer receives security updates is a problem for the scheme. If it is in scope, it generally has to be removed, replaced, or kept out of scope in a way you can justify.

Are updates applied promptly? The scheme expects security updates rated high or critical to be applied within 14 days of release, unless there is a good reason. That applies to operating systems, applications and the platforms your software runs on.

Notice that this is about the supporting layers. Your own bespoke application is rarely the issue. The things underneath and around it are: the Windows Server it sits on, the database engine, the runtime, the Office version that opens it.

The usual suspects

These are the situations we see most often when a business tells us it has a Cyber Essentials problem.

An old Office version running a macro driven file. The classic is a Microsoft Access or Excel system on a version that has left support. Our guide to Microsoft Access end of life sets out the dates and what they do and do not mean. Moving to a supported version often solves the assessor's question, though not the underlying fragility.

A legacy desktop package on an old operating system. A Sage version or a Visual Basic 6 program that only runs on Windows 7 or an ancient server. The operating system is the thing that fails the check, and the software is the reason you cannot upgrade it. We cover this in moving off an ageing Sage or VB6 system.

A server nobody dares touch. The system works, the supplier has gone, and the machine has not been patched in years. It is the oldest risk in small business IT, and it is exactly what the scheme was designed to flush out.

Cloud tools with weak access settings. Not an age problem, but worth mentioning. Shared logins, no multi-factor authentication on admin accounts and former staff who still have access are all covered by the user access controls, and they apply to hosted software as much as anything on your own network.

Your options when a system is out of support

There is no single right answer, and the cheapest is not always the wrong one.

1. Update the supporting layers

Often the application is fine and one layer beneath it is the problem. Moving to a supported Office release or a current Windows Server may be all that is needed. Check this first, because it is the cheapest route. Test the application on the newer platform before committing, since old software sometimes depends on things that newer systems removed.

2. Take it out of scope, carefully

Some businesses isolate an old machine, for example by putting it on a separate network segment with no internet access. Whether that is acceptable depends on the scheme's rules and your assessor's reading of them, so ask before you build anything. It is a way to buy time. It is also a way to end up with an isolated system that people work around by copying files on a USB stick, which is worse.

3. Rebuild the system on a supported footing

When the application itself is what is holding you back, the honest answer is usually to replace it. A web based system on current, maintained components removes the unsupported layers altogether and puts patching in one place instead of across a dozen desks. This is the kind of project described on our legacy system replacement page, and because it is a web application it also fits the way people work now, which our guide to web app versus desktop app explains.

If you are considering this route, be realistic about timing. Certification deadlines are often set by a customer, while a rebuild takes months, not weeks. Our guide to how long bespoke software takes gives typical ranges. In the meantime, option one or two can cover the gap while the replacement is built.

What not to do

Do not rush into a rebuild just because a questionnaire arrived. Many certification problems are fixed by updating the platform underneath.

Do not hide an old system from the assessor either. Scope is something you agree openly, and a system that turns up later is a bigger problem than one you declared and explained.

And do not treat certification as a one off. It is renewed every year, so a plan that gets you through this year's assessment but leaves the same system ageing for another twelve months has only postponed the conversation.

A sensible order of work

1. List every system the business depends on, including the ones that live on a single PC under someone's desk.
2. For each, note the operating system, database and application versions, and whether the vendor still supports them.
3. Mark the ones that are unsupported, then ask which of those are really needed.
4. For the ones that are needed, decide between updating, isolating and replacing, using the cost of a week without the system as your guide.
5. Agree your approach with your certification body before you spend money.

Getting a second pair of eyes

If one of your core systems is the thing standing between you and a certificate, it helps to have someone look at it who has no interest in selling you a rebuild. Sometimes the answer is a supported version and an afternoon of testing. Where it is not, you will at least know why. The contact page is the quickest way to ask.