Skip to content

Cyber Essentials Patch Evidence

Patching becomes messy when inventory is fuzzy. Most evidence problems start there - missing devices, unsupported software, and reports that only describe part of the estate.

Published27 Apr 2026

Updated8 weeks ago

Read time3 min. 565 words.

AuthorGyorgy Bolyki

Cyber Essentials v3.3 is very specific on security update management, and that is helpful.

The requirement says in-scope software must be licensed, supported, updated automatically where possible, and patched within 14 days for critical or high-risk updates.

That also applies when the update addresses CVSS v3 7+ vulnerabilities or the vendor gives no severity details. It is clearer than the old "we patch regularly" line.

For Microsoft 365 environments, the real challenge is not the wording. It is the estate. Windows devices, Microsoft 365 Apps, browsers, third-party tools, and the odd stubborn legacy application all move at different speeds, with different owners and different reporting.

What assessors and customers really care about

They are usually trying to answer four simple questions:

QuestionWhat a good answer looks like
Do you know what devices and software are in scope?Current inventory, not a spreadsheet from last quarter
Are those products supported?Clear support position for OS, browsers, apps, and security tooling
Are important updates landing on time?Reporting that shows status, not just policy intent
If something is delayed, is it controlled?A live exception record with owner and target date

If one of those falls apart, the rest of the patching story usually gets shaky as well.

The Microsoft 365 patching traps

Three traps show up all the time.

The first is assuming Intune coverage equals estate coverage. It does not. Intune tells you about enrolled devices. If a chunk of your real-world estate is outside enrollment, your report is incomplete by definition.

The second is focusing only on Windows cumulative updates and forgetting the rest of the stack. Microsoft 365 Apps channels, browsers, remote support tools, PDF software, VPN clients, and line-of-business apps all count when they are in scope.

The third is leaving unsupported software in place because replacement work is awkward. v3.3 is pretty direct here. Unsupported software needs to go, or it needs to be genuinely removed from scope by isolating it from internet traffic.

A practical evidence pack

For a normal Microsoft 365 endpoint estate, I would want these items ready:

  1. Windows update compliance view.
  2. Current supported Windows version position.
  3. Microsoft 365 Apps update channel and version evidence.
  4. Browser version visibility.
  5. Third-party patching method and ownership.
  6. Exception register for anything delayed or not fully covered.

A small exception list is not automatically a problem. A mystery list is a problem.

What to clean up first

If time is tight, fix these before anything more decorative:

PriorityWhy it matters
Devices not checking inYou cannot prove patch state for a silent device
Unsupported OSThis is a fast way to weaken the whole control
Unknown app ownershipThird-party software often slips through because nobody owns it
Weak exception handlingDelays happen, but they need dates, owners, and a plan
Browser driftBrowsers are high exposure and easy to forget

This is also where some honesty helps. If you still have a small legacy island, document it properly and reduce exposure. Pretending it is fine burns more time than admitting it needs treatment.

References

Related notes

Need help mapping this to your own tenant, controls, or assessment timeline?

© 2026 Magrathean UK Ltd. All rights reserved.