Cyber Essentials Patch Evidence

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

The requirement says in-scope software must be licensed and supported, have automatic updates enabled where possible, and be updated within 14 days of release when the update fixes critical or high-risk issues, addresses vulnerabilities with a CVSS v3 base score of 7 or above, or when the vendor does not provide severity details. That is a lot clearer than the old "we patch regularly" line that turns into mush under scrutiny.

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:

Question	What 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:

Priority	Why it matters
Devices not checking in	You cannot prove patch state for a silent device
Unsupported OS	This is a fast way to weaken the whole control
Unknown app ownership	Third-party software often slips through because nobody owns it
Weak exception handling	Delays happen, but they need dates, owners, and a plan
Browser drift	Browsers 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

• Microsoft Learn: Windows Update for Business reports overview
• Microsoft Learn: Microsoft Intune Reports
• Microsoft Learn: Supported versions of Windows client