SOC 2 Patch Management Evidence: What Auditors Test

A patch dashboard is not patch evidence. An auditor will ask which devices, patched on which date, against which policy, and how you know about the ones your tooling never saw. Here is what holds up.

Does SOC 2 require a patching deadline?

No. SOC 2 sets no fixed patching window, but it does hold you to the one you write. PatchMon puts it plainly: there is no mandated 30-day window, but you must define your own patching SLA in your policy and your auditor will hold you to it.

Its example is a policy that promises critical patches in 14 days while servers sit unpatched for 60 days with no documented exception. That is a finding, and it is a finding about your own words rather than about the framework.

The practical consequence is that the policy is the first piece of evidence, and it should be a number you can actually meet. A 72-hour critical SLA you miss on a fifth of your fleet is worse than a 14-day SLA you meet and can prove. Write the number you can defend.

Which SOC 2 controls cover patching?

Two criteria carry most of the weight. CC7.1 covers detecting vulnerabilities, so it is where scanning cadence and scan output live. CC8.1 covers change management, and patching is usually mapped there.

PatchMon reports that the AICPA added a patch-related point of focus under CC8.1 in 2022: a process to identify, evaluate, test, approve and implement patches in a timely manner. Note that this wording is a point of focus, not a numeric requirement, and that a principles-based framework leaves the interpretation to your auditor.

That means the same patch can need evidence in two places:

• Detection (CC7.1): the scan that found the vulnerability, with date and affected device.
• Change (CC8.1): the approval, test and deployment record for the fix.
• Verification: a later scan or inventory check showing the vulnerability is gone.

None of these mappings is universal. Confirm yours with the auditor before the observation window opens, not after.

What patch evidence do SOC 2 auditors ask for?

Auditors ask for records that tie an action to a device and a date. PDQ's summary is blunt: auditors don't grade your vulnerability scanner, they grade your follow-through, and raw scanner output satisfies none of the requests on its own.

PDQ lists six evidence types auditors commonly request:

1. An asset inventory of managed devices in scope, with last-seen dates.
2. Vulnerability discovery records: CVE, severity, affected device, status.
3. Remediation history: what was deployed, when, to which devices.
4. Patch deployment records with per-device outcomes.
5. Exception documentation for accepted risk.
6. A mapping from each artifact to a named control.

PatchMon adds a test that is easy to automate on the auditor's side: logs showing patch deployment dates relative to CVE publication dates. If a critical CVE was published on the 3rd and your deployment log shows the 40th day, the arithmetic is the auditor's whole finding.

Hexnode's reporting guide suggests the same approach in a UEM context: the auditor can cross-reference the release date with the last successful scan to verify time to patch. Treat that as a vendor workflow rather than an audit requirement, but the underlying test is real: dates, devices, and deltas.

Why does a point-in-time patch report fail?

A snapshot proves one day. A SOC 2 Type 2 period covers months, and the auditor samples across it. A report exported the week before fieldwork says nothing about the device that was 45 days behind in March.

The failure pattern is consistent. The current state looks clean because the stragglers were fixed last week. The history shows the gap, and the history is what the sample draws from.

What you need instead is dated evidence for every period in scope:

• Per-device patch history, not a fleet percentage. A 98% compliance figure hides which 2%.
• Time-to-patch per vulnerability, computed from publication or detection date to verified fix.
• A record of the state at the time, such as a device's patch level on the day it was sampled.

The last item is the one teams lack. A UEM answers "what is the patch level now". An auditor asks "what was it on the 14th of May". If your tooling overwrites state rather than recording it, you cannot answer, and a reconstructed answer is weaker than a recorded one.

We made a similar argument about encryption in how to prove laptop disk encryption to a SOC 2 auditor: the control rarely fails, the evidence of it over time does.

How do you prove the device population is complete?

You cannot prove it from inside the tool that reports on it. Hexnode's own evidence guide says so: the population can't be established inside the tool that has the blind spot, because a device manager only sees the devices enrolled in it.

That matters for patching because every compliance percentage has a denominator. If the denominator is "enrolled devices", an unenrolled laptop or an unmanaged server is invisible, and it is usually the one that is behind.

The same guide recommends reconciling the managed-device list against independent sources such as the identity provider and the HR system. It also notes the join is real work, because the systems share no common key: serial numbers in one, user identities in another, employee IDs in a third.

Two mismatches are worth chasing:

• An account with no managed device. Either the device is unmanaged or the account is stale.
• A managed device that maps to no one. Probably a machine to retire, and a record to explain.

The guide's warning is worth repeating to leadership. Discovering a gap during fieldwork may widen the sample and increase scrutiny of everything else. Finding it yourself, early, with a ticket attached, is a far better position.

What happens when a patch misses its SLA?

A miss is not automatically a finding. An undocumented miss is. The exception record is what turns a missed SLA into a managed risk.

PDQ describes the content of a good exception: a business justification, an owner, an approval record, and a review date. The review date matters most. An exception with no end date reads as a permanent risk acceptance.

The same logic applies to software the vendor no longer patches. If a server cannot receive a fix, the evidence is an inventory entry, a named owner, a compensating control and a retirement plan. We covered that case in is end-of-life software a SOC 2 or ISO 27001 finding.

Hexnode's guide gives one more rule worth adopting: never hide offline or unpatched endpoints. A report that omits the awkward devices does not survive the first reconciliation.

What does a defensible patch evidence package look like?

NIST frames patching as a critical component of preventive maintenance and recommends an enterprise strategy to make it manageable, in SP 800-40 Rev. 4 (April 2022). A package that supports that strategy and survives sampling has five parts:

1. A policy with severity-based SLAs you meet in practice.
2. A reconciled inventory, checked against identity and HR records, with named exclusions.
3. Dated per-device history of detection, deployment and verification.
4. An exception register with owner, approval and review date.
5. Continuous observation of device state, so past dates are recorded, not reconstructed.

The fifth part is where infrastructure trust earns its keep. A sensor on the device reports patch level, support status and encryption as observed facts with timestamps, rather than as something inferred from a management console. When it cannot establish a fact, the honest output is "unknown", and unknown devices are exactly the population gap an auditor looks for. Remediation stays a human-approved action; the sensor's job is to give you the evidence trail, not to quietly change the fleet.

PDQ cites its own survey in which 51% of sysadmins name timely security patching as a top time drain. Evidence that is recorded as it happens removes the scramble, and the scramble is where most of that time goes.

Takeaway

• SOC 2 sets no patching deadline. Your auditor tests you against your own policy.
• Evidence ties a patch to a device and a date. Scanner output alone is not enough.
• Type 2 sampling needs history across the period, not a snapshot.
• The device population cannot be proven from inside the tool that reports on it.
• A missed SLA with an owner, approval and review date is managed risk. Without them, it is a finding.

See what your fleet's patch and device evidence looks like with a free SAUTERA trust assessment of up to 10 devices.