How to Write and Summarise a Compliant Process for Cyber Essentials

The Assessor Team
3 days ago
7 min read

Category: Guidance for Applicants | Read time: ~7 min

Two of the most common reasons applicants receive a non-compliance finding during a Cyber Essentials assessment are not what most people expect. It is rarely a missing firewall rule or an unpatched device. More often, it comes down to how a process is described — or rather, how it is not described.

Earlier articles in this Resource Hub have explored the difference between a policy and a process and why stating that you do something is not the same as describing how it is done. This article takes the next step: it explains how to build a complete, compliant process and — critically — how to summarise it in a way that satisfies a Cyber Essentials assessor.

Why Process Summaries So Often Fall Short

When assessors review application answers, they frequently see responses that are almost there. An applicant will describe several steps of a process accurately, but leave out the elements that confirm it is a documented, managed, and repeatable procedure rather than something done informally or ad hoc.

A process that lives only in someone's head — even if it is followed consistently — cannot be verified by an assessor, cannot survive staff changes, and cannot be audited. Cyber Essentials requires evidence that controls are actively implemented and maintained. A strong process summary provides that evidence in written form.

The gap between a partial answer and a compliant one is usually found in five areas: who, what, when, how, and how you know it worked.

The Five Elements of a Compliant Process

Every process that is relevant to Cyber Essentials should be able to answer the following five questions. If any one of them is missing from a description, the answer is likely to be incomplete in the eyes of an assessor.

1. Who is responsible?

A compliant process names or describes the role responsible for carrying it out. This does not need to be a job title unique to a large organisation — in a small business, it might simply be "the business owner" or "the person who manages IT." What matters is that responsibility is clearly assigned and not assumed.

Vague: "Someone checks for updates." Compliant: "The IT administrator is responsible for checking for and applying updates."

2. What is being done?

The process must describe the specific action being taken, not just the desired outcome. There is a significant difference between "devices are kept up to date" and "firmware updates are downloaded from the vendor's support page and applied to all in-scope devices." The second version tells an assessor what is actually happening.

3. When does it happen?

Frequency and timing are essential to compliance. Cyber Essentials has specific requirements around timeframes — for example, critical patches must be applied within 14 days of release. An assessor needs to see that your process reflects this, and that it happens consistently rather than when someone remembers to do it.

Vague: "We patch regularly." Compliant: "Patches are applied within 14 days of release. The IT administrator checks the vendor's security bulletin page every Monday."

4. How is it carried out?

This is where many applicants stop short. A compliant process describes the mechanism — the tool, system, or method used to carry out the task. Is it done manually or through a management platform? Is it automated or scheduled? Does it cover all in-scope devices, or only some? These details turn an intention into a demonstrable procedure.

5. How do you know it has been done?

This is the element most commonly omitted, and it is arguably the most important for demonstrating compliance. A process without a verification or logging step cannot be audited. Assessors look for evidence that completion is checked and recorded — whether that is a log file, a report from a management tool, a signed-off checklist, or a ticket in a helpdesk system.

Vague: "We make sure everything is updated." Compliant: "Once updates have been applied, the administrator confirms status through the endpoint management console and records completion in the IT log. Any device that has not received the update within the 14-day window is escalated for investigation."

How to Build a Process Document

A process does not need to be lengthy or written in technical language to be compliant. What it does need to be is clear, specific, and followed in practice. The following structure works well for most Cyber Essentials-relevant processes and is accessible to organisations of any size.

Process title — give the process a short, descriptive name, for example: Firmware and Software Patching Process or New User Account Creation and Access Control Process.
Purpose — one or two sentences explaining what the process achieves and which Cyber Essentials control it supports.
Scope — which devices, systems, or users does this process apply to? This is particularly important if your organisation uses network segregation or has devices outside the assessment scope.
Responsible role — the job title, team, or individual accountable for carrying out and overseeing the process.
Steps — a numbered list of actions in the order they should be carried out. Each step should be specific enough that someone unfamiliar with the role could follow it.
Frequency — how often the process runs, or what triggers it (for example, on receipt of a vendor security advisory, on a new employee joining, or on a weekly schedule).
Verification and recording — how completion is confirmed and where it is logged.
Review date — when the process will next be reviewed to ensure it remains accurate and fit for purpose.

Keeping this document up to date is just as important as creating it. A process document that describes how things were done two years ago, before a systems change or office move, will not accurately reflect current practice and may create inconsistencies during assessment.

How to Summarise a Process for Your Assessment Answer

The Cyber Essentials questionnaire does not ask applicants to submit their full process documents. It asks for answers to specific questions, which means applicants need to be able to summarise a process clearly and concisely without losing the key compliance elements.

A good process summary for an assessment answer should cover all five elements — who, what, when, how, and verification — in plain language, in no more than a short paragraph or a brief numbered list.

Here is an example for software patching, showing a weak answer and a compliant one side by side.

Weak answer: "We keep all software up to date and apply patches as they become available. Our IT provider manages this for us."

This answer states what is done but provides no detail on how it is done, no timeframe, no description of the mechanism, and no indication that completion is verified. An assessor cannot confirm compliance from this response.

Compliant summary: "Software updates and security patches are managed by our IT support provider under a managed service agreement. The provider monitors all in-scope devices — Windows laptops, the office server, and network devices — using a remote monitoring and management (RMM) platform. Critical security patches are applied within 14 days of release. The provider supplies a monthly patching report which is reviewed by the business owner. Any device unable to receive updates within the required timeframe is reported to the business owner and either remediated or temporarily removed from the network."

This answer covers all five elements. An assessor can confirm who is responsible, what is being done, when it happens, how it is carried out, and how compliance is verified.

Practical Tips for Getting Your Process Summaries Right

Walk through the process before you write it down. The best way to ensure a process summary is accurate is to observe or carry out the process step by step and note what actually happens, rather than what should happen in theory.

Use specific language rather than general statements. Words such as "regularly," "promptly," "as required," and "when necessary" do not satisfy an assessor because they have no defined meaning. Replace them with timeframes, frequencies, and defined triggers.
Name your tools and systems. If patching is done through a specific platform, name it. If access control is managed through Active Directory, say so. Specific references are more credible and easier to verify than generic descriptions.
Account for exceptions. A compliant process also describes what happens when the standard procedure cannot be followed — for example, a device that cannot receive a patch within the required window. Showing that exceptions are managed and recorded demonstrates a mature, documented approach.
Keep it proportionate. A sole trader with a single laptop and a cloud-based email service does not need a multi-page process document. A straightforward written record of what is done, by whom, and how compliance is checked is entirely sufficient. Cyber Essentials is designed to be achievable for organisations of all sizes.

A Note on Documentation

The question of whether a process needs to be written down is one that frequently arises. The answer, for the purposes of Cyber Essentials, is yes — at least in summary form.

A process that exists only informally cannot survive the departure of the person who carries it out. It cannot be reviewed or improved. It cannot be shown to an assessor as evidence. And if the process is not documented, there is no reliable way to confirm that it is followed consistently across the organisation.

Documentation does not need to be complex. A simple table, a checklist, or even a clearly written paragraph in a shared document is sufficient, provided it captures the five elements described above and reflects what is actually done in practice.

Key Takeaway

A compliant process for Cyber Essentials is one that answers five questions: who is responsible, what is being done, when it happens, how it is carried out, and how completion is verified.

When summarising a process in an assessment answer, all five elements should be present. A response that covers only some of them — however accurate the parts that are included — leaves an assessor unable to confirm compliance and may result in a finding that could have been avoided.

If you are unsure whether your process summaries meet the standard, Get Cyber Certified's supported service pairs applicants with a senior assessor who can review answers before submission. Find out more here or you can use our pre submission check to check your processes before you go ahead with an assessment service Find out more here. Please contact the team with any questions.