How to Turn UEM Data Into SOC 2 Audit Evidence

A unified endpoint management (UEM) platform already holds a wealth of information about your endpoint fleet. It can report encryption, passcode, and policy compliance status for enrolled devices, provide patch and update visibility for Windows and macOS, and configure or integrate with supported endpoint protection solutions. For teams using a UEM platform, much of the endpoint data relevant to a SOC 2 audit is already available.

The challenge is that managing endpoints and demonstrating compliance are two different things. A UEM platform shows the current state of your fleet, while SOC 2 auditors need historical evidence that controls operated consistently throughout the audit period. Turning operational data into audit-ready evidence requires more than screenshots and dashboard exports.

In this guide, we explain where a UEM platform fits into SOC 2 evidence collection and how to transform endpoint data into evidence that can withstand auditor scrutiny.

What SOC 2 auditors actually want at the endpoint layer

For an organization that has already completed a SOC 2 Type I examination, the most important distinction is the one that makes endpoint evidence challenging. A Type I report evaluates whether controls are suitably designed as of a specified date. A Type II report evaluates whether those controls were suitably designed and operated effectively throughout a defined review period, which is often several months.

The focus therefore shifts from “Is this configured correctly?” to “Did this control continue to operate effectively throughout the period?”

A time dimension

An auditor may select a sample of devices and ask the organization to demonstrate that each selected device met the relevant control requirements at different points during the review period. The objective is to determine whether the control operated consistently over time, rather than only on the date the evidence was collected. A current-state console may not preserve enough historical information to answer these requests on its own.

A defensible population

Before a coverage figure is meaningful, the auditor must understand the population from which it was calculated. Evidence showing that 40 laptops are encrypted has limited value unless those 40 laptops represent the complete population of devices that should be encrypted, rather than only the devices included in a particular report.

Keep these two concepts in mind: duration and population. Many weaknesses in endpoint evidence can be traced back to insufficient historical coverage or an incomplete device population.

The controls where your UEM is the system of record

A material share of the SOC 2 Common Criteria relates directly to the state of employee devices, which makes the UEM the de facto system of record for proving them. The mappings below reflect the common shape of that relationship.

Disk encryption

FileVault on macOS and BitLocker on Windows help support compliance with SOC 2 Common Criteria CC6.1 and CC6.7 by protecting data at rest on hardware that routinely leaves the building.

What the auditor wants here isn’t confirmation that encryption is enabled today. They want the encryption status of every in-scope device, sampled across the audit period. Increasingly, auditors also distinguish between encryption being enabled and recovery keys being escrowed.

FileVault without an escrowed Personal Recovery Key can make recovery more difficult, although recovery may still be possible when an Institutional Recovery Key or another valid recovery method is available.

Screen lock and passcode policy

This supports SOC 2 Common Criterion CC6.1 by enforcing logical access controls that prevent unauthorized access to unattended devices. What the auditor wants isn’t a policy stating that screen lock should be enabled. They want evidence that the setting is actually enforced on each device.

EDR agent

An endpoint protection agent that is installed and actively running supports SOC 2 Common Criterion CC6.8, which focuses on preventing, detecting, and responding to unauthorized or malicious software. “Installed” alone doesn’t prove that the control is operating. The agent has to be running and checking in regularly. An agent whose last check-in was 40 days ago isn’t protecting anything, which is why auditors look at the last-seen timestamp, not just whether the agent exists.

Patch enforcement

This supports SOC 2 Common Criterion CC7.1, which requires organizations to identify, assess, and remediate vulnerabilities in a timely manner. The control isn’t that patches exist; it’s that they are installed within the remediation window to which the organization has committed.

If the policy requires critical patches to be installed within 30 days, the evidence must show when the patch became available and when it reached the device. A UEM reports patch release information, scan timestamps, and whether applicable updates are installed, missing, failed, or pending. Confirm that a per-device installation timestamp is available before using it to demonstrate remediation within a defined SLA.

Device inventory

Inventory management and remote wipe both support SOC 2 Common Criterion CC6.1. An organization can’t enforce logical access controls for devices it doesn’t know exist, and it needs the ability to revoke access when a device is lost, stolen, or no longer under its control.

One important note: These mappings are illustrative, not official. SOC 2 doesn’t publish a canonical control-to-criteria mapping, and how a control aligns with the Trust Services Criteria depends on how your organization defines and scopes it. Think of these pairings as common industry practice rather than a prescribed crosswalk.

Why raw UEM data isn’t SOC 2 evidence (yet)

When the evidence request arrives, the instinct is obvious: open the console, find the compliance view, and export or screenshot what it shows. That instinct fails for four reasons, and they compound.

The dashboard describes the present

A UEM compliance view is built to answer one operational question: Is the fleet healthy right now? To answer it, the view recomputes the current state. Many platforms retain little history or only a rolling window of it. That’s appropriate for operations but disqualifying as evidence. If the auditor’s sample lands on a date that was never captured, that state isn’t merely slow to retrieve; it no longer exists. The system never wrote it down, and an assurance that the device was surely compliant is the one thing an auditor cannot accept in place of a record.

The population is incomplete by design

A UEM knows only the devices enrolled in it. The contractor on a personal MacBook, the machine that was reimaged and never re-enrolled, and the laptop issued outside the standard process – each touches production data, but none appears in the console. Coverage from the UEM alone can therefore describe every managed device flawlessly and still leave the auditor’s real question unanswered: How do they know there aren’t more? The population can’t be established inside the tool that has the blind spot. The fix has to come from outside it.

A screenshot has no provenance

It’s an image produced manually, and once a person sits between the system and the artifact, the auditor has to account for what that selection could hide: a filtered device list, a view scoped to one operating system, or compliant machines shown while failing ones scroll past. Evidence has to come from the system itself, exported with its source and timestamp intact, or an auditor may discount it regardless of whether it happens to be accurate.

A spotless record reads as a broken sensor

This is the inversion of the other issues. A clean run of 400 devices over 12 months with zero drift looks like the goal but may read, to an experienced auditor, like a monitor that isn’t running. Real fleets drift: agents lapse, reboots are deferred, and devices go offline. A working monitor surfaces exceptions. Their absence may suggest that nothing was watching, rather than that nothing went wrong.

How to convert UEM data into SOC 2 audit evidence: 5 steps

Each failure above describes, in the negative, something the evidence must do. Turn those failures into positive requirements, and the result is a definition of audit-grade evidence and the sequence that produces it. The goal at every step is the one Sprinto describes in its own work on audit-grade evidence collection: evidence that is organized, time-stamped, complete, and traceable to a control.

Step 1: Map each control to a specific, named signal

Decide, control by control, exactly which report, status field, or export demonstrates it for example, the named compliance report showing encryption status for each device, with serial numbers attached. Fix this before fieldwork so that, when an auditor names a device and a date, you know where the proof lives instead of improvising under pressure. This is also where each signal is tied back to the criterion it satisfies, so the auditor isn’t left to reverse-engineer the connection.

Step 2: Establish and reconcile the population

Pull the full managed-device list and reconcile it against independent sources: your identity provider, such as Okta or Entra, and your HR system. The reason this is genuinely difficult, rather than a simple lookup, is that the three systems don’t share a common key. The UEM uses a device serial number or hardware UUID, the IdP uses user identity, and the HRIS uses an employee ID. Reconciliation therefore requires joining data across systems that don’t agree on what a row represents.

The resulting mismatches are where the work begins:

• An IdP account with no managed device is a gap to investigate.
• A person in the HRIS with no device is a question to answer.
• A managed device that maps to nobody is probably a machine to wipe.

Not every mismatch is a failure. A personal phone under app-level management rather than full enrollment, or a shared kiosk with no assigned user, may represent a legitimate scoping decision. However, each one has to be a decision you can name, not a row you never saw.

What you’re building is a denominator you could defend out loud: every device that should be managed, proof that it is managed, and a documented reason for anything deliberately left out of scope. Settle this before the auditor does, because discovering the gap may widen the sample and increase scrutiny of everything else.

Step 3: Capture state over time as the period passes

Decide, for each control, how continuous operation will be demonstrated through periodic point-in-time captures, status histories, or change logs recording when a device entered and left compliance. Capture this evidence while the period is underway rather than attempting to reconstruct it afterward, because the underlying state may not have been preserved for reconstruction.

In Hexnode, schedule periodic compliance reports for email delivery or manually export PDF or CSV reports to preserve point-in-time evidence. Use Action Reports and Audit Logs for documented historical actions, and mention API-based compliance extraction only when a specific supported endpoint has been verified.

A program that exports monthly compliance snapshots throughout the year can answer requests relating to those captured periods. A program that pulls a report only at audit time can answer only for the present, which is the one date the auditor isn’t asking about.

Step 4: Preserve provenance

Favor evidence that the system generates and timestamps over anything captured manually. A report exported directly from the platform, carrying its source and time, is far stronger than a screenshot of the same numbers.

Where a manual capture is genuinely unavoidable, record what produced it, when it was produced, and where it came from. The closer an artifact comes to demonstrating that “the platform produced this, at this time, without curation,” the less an auditor has to discount it.

Step 5: Document exceptions openly

For every device that drifted, show the detection, the remediation, and the dates that bracket the event. If you described a control that catches drift and remediates it within a defined window, the documented exception is proof that the control works as described.

Present the trail rather than hiding it. This is the answer to the broken-sensor problem described above, and it turns the messiness of a real fleet from a liability into the strongest evidence you can show.

One practical question sits underneath all five steps: How often does evidence for each control need to be captured? The cadence should at least match the auditor’s sampling granularity and ideally exceed it, so that no sampled date falls into a gap. The appropriate interval varies by control:

Stable configuration states, such as disk encryption or screen-lock policies, change relatively rarely, so monthly snapshots usually suffice.

Agent health can drift faster and benefits from weekly or continuous capture, since an EDR agent can stop reporting on any given day.

Patch compliance should track your remediation SLA. If you commit to 30 days, monthly capture is the minimum, while continuous capture is the safer choice because you have to prove that you closed the window, not merely that you eventually installed the patch.

The population should be reconciled often enough to ensure that a late-enrolled or newly issued device is not left unaccounted for on a date the auditor may select.

Producing evidence continuously

You can run all five steps by hand, and they work for one cycle. The method is sound, but it captures a single moment, while the fleet continues to change. Settle the population in January, and people join, leave, and swap machines throughout February. Capture clean encryption coverage in spring, and a contractor onboards in summer using a device that nobody enrolled. The evidence was accurate on the day you assembled it, but the next audit period requires you to assemble it again for a fleet that no longer looks the same.

This is structural, not a matter of effort. Endpoints churn faster than anything else in your scope – they are issued, wiped, lost, returned, and re-enrolled while servers remain stable and access reviews run quarterly. A record built at a single moment is always chasing a population that has already changed, and doing it by hand means rebuilding your evidence from scratch during every cycle, in the weeks before fieldwork. That’s the scramble.

The way out is to produce evidence as the fleet changes rather than reconstructing it afterward – the shift from point-in-time to continuous compliance. Here, an endpoint platform and a compliance layer split the work cleanly. Hexnode monitors enrolled devices and reports compliance, policy, patch, and action status based on device check-ins and scans.

A platform like Sprinto holds that stream to the five-point specification defined by the steps above – capturing signals as they occur, timestamping them at the source, continuously reconciling the population against your identity and HR systems, and surfacing drift as it appears. Hexnode supplies the observations; Sprinto reconciles, captures, and timestamps them as evidence.

This is also where the broken-sensor problem resolves in your favor. Because continuous monitoring records each instance of drift and its remediation as they occur, it produces a credible detection-and-remediation trail that proves a control is genuinely operating – the living record an auditor trusts over a suspiciously clean sheet.