Insights  /  Cyber Essentials and Your RMM: Evidencing the Five Controls with Tooling You Already Run

Insights

Cyber Essentials and Your RMM: Evidencing the Five Controls with Tooling You Already Run

Insights By The Helios team  ·  16 August 2026  ·  7 min read

By the Helios team

Most small MSPs treat Cyber Essentials as a form-filling exercise done from memory the week before renewal. That is backwards. Nearly everything the assessment asks about is data your RMM already holds, and the gap between "we believe we patch within 14 days" and "here is the report showing we do" is the gap between an anxious submission and a boring one. This piece maps each of the five controls to the cyber essentials RMM evidence your tooling can produce, whether the machines belong to clients or to your own company, and is honest about what tooling cannot evidence at all. Here is the mapping, control by control, with a report schedule at the end.

What counts as cyber essentials RMM evidence

Cyber Essentials basic is self-assessment, so strictly you attest rather than prove. But two things make evidence worth generating anyway. First, Cyber Essentials Plus involves an assessor actually testing devices, and the same reports tell you in advance whether you will pass. Second, client security questionnaires increasingly ask you to demonstrate, not declare. A dated export from your RMM answers both, and it answers your own doubt, which is usually the loudest voice in the room.

Rule of thumb: for every question on the assessment, decide whether the answer comes from a report, a policy document or a screenshot of a portal setting. If it comes from memory, you do not have an answer yet.

Control 1: firewalls, mostly not your RMM's job

Start with the uncomfortable one. Most RMM platforms do not manage network hardware, so the boundary firewall questions, changed default passwords, no unauthenticated inbound services, admin interfaces not exposed to the internet, are evidenced from the firewall vendor's own portal or config export. Do not pretend otherwise on the form.

What your RMM can evidence is the software firewall on every endpoint. That matters more than it used to, because the scheme cares about devices used on untrusted networks, which is now most laptops most weeks.

  • Windows Firewall state per device. A posture report showing the firewall enabled on all profiles, across the whole estate, with exceptions named. Skip this and one developer's disabled firewall becomes the assessor's first finding.
  • Configuration drift alerts. An alert rule that fires when a firewall is turned off shows the control is monitored, not just set once.

Control 2: secure configuration, where inventory earns its keep

Secure configuration asks whether you have removed what you do not need and locked down what remains. This is inventory work, and inventory is the one thing an RMM does better than anything else you own.

  • Installed software per device. An export of installed applications lets you show that sample devices carry only what the role requires. Estates accumulate software the way lofts accumulate boxes, and this report is how you notice.
  • Local account audit. A list of local accounts per machine, flagging enabled Guest accounts and stale local admins. Default and unused accounts are an explicit assessment question.
  • Auto-run and startup entries. Evidence that you review what launches at boot supports the "unnecessary functionality disabled" attestation.
  • Screen lock settings. Device unlocking rules are in scope. A configuration report or the policy that enforces lock timeouts covers it.

What tooling cannot cover: the password and PIN policy itself is a written policy plus your identity platform's settings. For Microsoft 365 estates, most of it lives in Entra and Intune, and our Microsoft 365 security checklist covers the settings the assessment leans on.

Control 3: user access control, half tooling, half discipline

The scheme wants unique accounts, least privilege, controlled admin access and prompt removal of leavers. Your RMM evidences the endpoint half.

  • Local administrator report. Who is in the Administrators group on each device, scheduled monthly. The assessment asks directly whether users work as standard users. This report is the answer, and it is usually humbling the first time you run it.
  • Admin activity audit trail. Your own technicians' remote sessions and elevated actions should be logged in the RMM. You are in scope too: the tooling you use to manage clients is itself a privileged system, which is why we argue you should harden your own house first.

The other half is process. Joiner and leaver workflows, MFA on cloud accounts, separate admin accounts for admin tasks: these are evidenced by your identity platform and your written procedure, not by monitoring. Tooling shows the state; only a documented process shows intent.

Control 4: malware protection, the easiest report you will run

This is the control RMMs were practically built for. You need to show that every in-scope device runs supported anti-malware, that it updates, and that it scans or blocks in real time.

  • AV status across the estate. One report: product name, version, definition age, real-time protection state, per device. Definition age is the line assessors care about, because "installed" and "working" are different claims.
  • Unprotected device alerts. An alert that fires when Defender is disabled or definitions go stale demonstrates continuous coverage rather than a point-in-time screenshot.
  • Detection history. Not required, but a log of detections and outcomes turns a compliance answer into an operational one.

Control 5: security update management, the control that fails people

The scheme's requirement is blunt: high and critical updates applied within 14 days of release, on operating systems and applications, with unsupported software removed. This is where self-assessed confidence and measured reality diverge most.

  • Patch compliance by age. The single most important report in the whole exercise: missing updates per device, bucketed by days since release. Anything critical older than 14 days is a finding waiting to happen. If your deployment rings make 14 days impossible, that is a rings problem, and we have written about how fast you should actually patch.
  • Third-party application patching. Browsers, PDF readers and runtimes are in scope, and they are where most estates quietly fail. Evidence needs to cover them, not just Windows Update.
  • End-of-life software report. Unsupported operating systems and applications must be off the estate or out of scope. An inventory filter for EOL versions is your evidence either way.
  • Failed patch follow-up. A device that fails to install an update for six weeks is non-compliant however good your policy is. Ticket records showing failures investigated close the loop.

A patch policy without a patch report is a promise. A patch report without a policy is an accident. The assessment wants both.

The gaps tooling will not cover

Be honest on the form about what your RMM cannot see: the boundary firewall and router estate, unmanaged BYOD devices that touch organisational data, cloud service configuration beyond what your Microsoft 365 integration surfaces, and every written policy the scheme assumes exists. The failure mode on each side is instructive. Teams that lean entirely on tooling submit accurate data about an estate with no documented rules, and fail on process questions. Teams that lean entirely on policy submit beautiful documents describing an estate that does not match them, and fail at Plus when a real laptop is tested. You need the report and the paragraph.

Reports to schedule before assessment

Set these up as scheduled exports at least a month before you submit, so you have time to fix what they show you.

ReportControlFrequency
Endpoint firewall stateFirewallsWeekly
Installed software and local accountsSecure configurationMonthly
Local administrators per deviceAccess controlMonthly
AV status and definition ageMalware protectionWeekly
Patch compliance by update ageUpdate managementWeekly
End-of-life software inventoryUpdate managementMonthly

The 14-day test: pick any critical update released a month ago and ask your tooling which devices still lack it. If you cannot answer in five minutes, fix the reporting before you fix the estate.

Where this fits with Helios

Helios is an RMM and PSA in one platform, so the evidence above, patch compliance including third-party applications via winget, security posture, Defender status and Microsoft 365 configuration, comes from one place rather than four exports stitched together. The service desk keeps the failed-patch follow-up tickets next to the data that raised them. We are open about the gaps: Helios does not monitor network hardware, so your boundary firewall evidence still comes from the firewall itself, and the written policies are yours to write. Most of this article is discipline. The tooling just makes the discipline visible.

Helios is flat-priced RMM and PSA for small MSPs and internal IT, from £99 a month with every feature on every plan. 14-day trial, no card, no feature gating. Start free.

Hold your own house to your clients' standard

Helios is an AI-native platform for MSPs and in-house IT teams: monitoring, patching, security and service desk in one place, with a 14-day trial and no feature gating.

Start free

Read next

Insights Co-Managed IT: How to Share a Ticket Queue Between In-House IT and an MSP Insights Backup Monitoring for MSPs: Catching Silent Failures Before the Restore Request Insights MSP Tooling Costs as a Percentage of MRR: How to Model It