Patching is one of the controls teams are most confident they do and least able to prove. Laptops update themselves, servers are rebuilt from fresh images, managed databases are patched by the provider. Then the auditor asks for evidence that systems were kept patched throughout the period, and the answer turns out to be four different things in four different places, none of them dated.
The difficulty is that "patching" means something different for each kind of asset. A screenshot of one laptop's update screen does not show that the fleet is current, and it says nothing about containers or the database.
This article covers what auditors are looking for, why the inventory comes first, what evidence holds up for each asset type, how to show patching over a period rather than on one day, how to handle what cannot be patched, and how to package it.
What patch evidence has to show
Vulnerability findings show what was wrong and when it was fixed. Patch evidence shows something broader: that systems are kept current as a matter of routine, before a scanner finds anything. Your remediation windows are covered in vulnerability management SLAs auditors accept. This article is about proving the routine.
The framework references are short. PCI DSS v4.0 Requirement 6.3.3 requires critical patches within one month of release and others on a timeline you set. ISO 27001:2022 Annex A 8.8 covers managing technical vulnerabilities, which includes patching. NIST SP 800-53 Rev. 5 SI-2 covers flaw remediation, and NIST SP 800-40 Rev. 4 is a useful guide to planning enterprise patch management. SOC 2 covers patching through CC7.1, and patches deployed to production are also changes under CC8.1, which is why many teams define routine patching as a pre-approved standard change.
In every case, the auditor wants to see three things: a policy saying how quickly each kind of system is patched, a complete list of the systems it applies to, and evidence that those systems met the policy across the period.
Start from the inventory
You cannot evidence patching for assets you do not know about. Before collecting any patch reports, list the asset types in scope and who is responsible for patching each:
Endpoints: laptops and desktops used by staff
Long-lived servers and virtual machines: patched in place
Container images and immutable instances: patched by rebuilding
Managed cloud services: patched by the provider, with some settings yours
Network and security appliances: firmware updates, if you run any
Application dependencies: libraries your code imports
Build the inventory from systems rather than memory: resource listings from each cloud account, the device management or endpoint agent console, the container registry, and the list of managed services on your cloud bill. Then reconcile it with what your patch tooling reports. An asset that appears in the inventory but has no patch report is either outside your patching process or no longer exists. Both answers are worth knowing before the auditor asks.
Each type needs its own evidence. A report that covers servers well usually says nothing about containers, and the auditor will notice the gap if the inventory includes both.
Evidence that holds up, by asset type
The strongest patch evidence is generated by a system, covers the whole population, and carries a date. The table below sets out what that looks like for each type.
| Asset type | How it is patched | Evidence that holds up |
|---|---|---|
| Endpoints | Enforced automatic OS updates | Per-device export of OS version and last update date, compared with the current supported version |
| Long-lived servers | Scheduled patch automation | Patch compliance report per host, and the patch job logs |
| Containers and immutable hosts | Rebuild from an updated base image | Base image build dates, age of images running in production, pipeline logs of rebuilds |
| Managed services | Provider maintenance | Your configured maintenance windows and engine versions, plus the provider's assurance report |
| Application dependencies | Update pull requests merged | Merged update changes and dependency scan results over time |
Two of these deserve a note.
Immutable infrastructure changes the question. If you never patch a running host, "show me the patch report" has no direct answer. The equivalent evidence is that base images are rebuilt on a schedule, that the rebuild picks up current packages, and that nothing in production runs an image older than your policy allows. An image age report is the artifact an auditor can test.
Managed services shift responsibility, not accountability. The provider patches the database engine. You chose the version, the maintenance window, and whether minor upgrades apply automatically. Keep evidence of those settings, and keep the provider's assurance report, which describes their side of the arrangement.
Show it over the period, not on one day
For a SOC 2 Type II report or an ISO 27001 surveillance audit, a single report pulled the week before fieldwork is weak. It shows the fleet is current now. It does not show it was current in March.
The fix is a recurring snapshot. Each month, export the patch status of each asset type and keep it, dated, in your evidence store. Twelve monthly reports answer a question one report cannot. They also expose drift: a server that stopped receiving updates in May shows up in the June snapshot, not in the audit.
Types of audit evidence and which is strongest explains why a system-generated export carries more weight than a screenshot or a written attestation of the same facts.
Handling what cannot be patched
Every environment has some asset that cannot meet the policy: a vendor appliance waiting on firmware, a legacy system the business still needs, a laptop that cannot run the current OS version.
Treat each one as an exception, not a gap:
Record it with the asset, the reason, and the date it fell out of policy.
Apply a compensating control. Network isolation, removal of internet access, extra monitoring, or restricted users.
Get approval from the person your policy names for risk acceptance.
Set an expiry or a retirement date, and review it when it arrives.
For endpoints, decide in advance what happens to a device that falls behind: an automated reminder, then a deadline, then restricted access to company systems until it is updated. Writing that sequence into the policy makes enforcement routine rather than personal.
Packaging it for the auditor
When the request arrives, it is usually phrased broadly: "Provide evidence that systems are patched in accordance with policy." Answer it with a structured set rather than a single file:
The patching policy, with windows per asset type
The asset inventory for the period, by type
The monthly snapshots for each type
The exception register, with approvals
For managed services, the configuration evidence and provider report
A structured answer reduces follow-up questions, which is most of the time cost of an audit request. The PBC list: handling auditor requests covers how to organize responses across the full set of requests.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the cloud and endpoint systems you connect and routes failures to their owners. On laptops, the device agent reports patching posture alongside encryption, firewall, and screen lock, so the endpoint row of the table above is collected rather than assembled.