What Cyber Essentials actually asks of your help desk

Cyber Essentials is deliberately narrow: five technical controls, a self-assessment questionnaire, and an assessor who wants clear answers rather than an essay. Read the scheme looking for the words "help desk" and you will not find much. Read it looking for the places where a human grants access, and your desk is in three of the five.

This matters twice over for an MSP. You certify your own organisation, and you are increasingly the party expected to produce evidence when your clients certify theirs.

Where the desk sits in the five controls

User access control

This is the one that lands hardest. The control asks that user accounts are created through an approved process, that special access is granted only to those who need it, and that access is removed when it is no longer required. Every one of those is a desk activity: someone rings, someone acts.

The word doing the work is approved. An assessor is asking who authorised the account, not merely that it exists. If your answer is that engineers create accounts when asked by someone who sounded legitimate, you have a gap — not because the engineers are careless, but because there is no record of authority.

Secure configuration

Default passwords, unnecessary accounts and unneeded software are the desk's territory whether or not anyone has written that down. The relevant question at assessment is whether the process is consistent — the same steps every time — rather than dependent on which engineer picked up the build.

Security update management

Mostly a tooling question, but the exceptions are a desk question: the machine that could not be patched, the user who deferred a restart for six weeks. What the assessor wants is that exceptions are visible and tracked, not that they never happen.

The evidence assessors actually ask for

Cyber Essentials at the basic tier is self-assessed, so the immediate deliverable is an honest answer. Cyber Essentials Plus adds technical verification, and client security questionnaires — which are usually the harder audience — will ask for artefacts. In practice, the useful ones are:

• A written account creation and removal process, with the approval step named.
• A record showing, for a sample of accounts, who requested them and who authorised them.
• The same for privilege escalation: who asked for admin rights, who agreed.
• Evidence that leavers' access was removed, with dates.
• A verification procedure for requests arriving by phone — see the policy template if you do not have one written down.

The gap is almost never the control. It is being able to show the control ran on a particular Tuesday in March.

Why this is harder for an MSP than for a single business

An internal IT team can lean on the fact that they know their colleagues. That informal signal is doing real security work, even if nobody would write it into a policy. An MSP has none of it: you support hundreds of people across dozens of organisations, most of whom you have never met, and the person calling about a locked account is a voice with a plausible story.

So the control that an internal team can partly carry socially, an MSP has to carry procedurally. That is more work — and it is also why an MSP that gets it right has something genuinely worth showing a prospect.

Making the evidence a by-product

The version of this that fails is the one where someone spends the fortnight before an assessment reconstructing history from mailboxes and ticket notes. The version that works produces the evidence as a side effect of doing the work: the authorisation is captured at the moment it is given, attached to the request, and cannot be edited afterwards.

That is the design behind Certra's audit trail and approval workflows — not because certification is the point, but because the same record that satisfies an assessor is the one you want on the morning an account is questioned.