How to Prove EDR Is Running on Every Laptop (SOC 2)

"EDR is deployed everywhere" is a claim about intent. An auditor will ask which laptops, whether the sensor is alive on each of them today, and how you know about the machines the console has never seen. Here is the evidence that answers those questions.

How do you prove EDR is running on every laptop?

Produce a dated, device-level export showing each laptop's sensor version and last check-in, then reconcile it against an independent list of in-scope devices. Add exports from across the audit period, and explain every gap. A single dashboard screenshot proves none of those things.

The distinction that matters is installed versus running. Sprinto's guidance, published on Hexnode's blog, ties an endpoint protection sensor that is installed and actively running to SOC 2 Common Criterion CC6.8, the criterion about preventing and detecting malicious software. It adds that auditors look at the last-seen timestamp, not just whether the sensor exists. A sensor that last reported 40 days ago protects nothing, and the export should make that visible rather than hide it.

Which SOC 2 criterion does endpoint protection map to?

Most practitioners map it to CC6.8. The guide above links a running endpoint protection sensor to that criterion. SOC 2 does not name EDR as a required product, so the real requirement is whatever your own system description promises. If it says every company laptop runs endpoint protection, that sentence is what the auditor tests.

Write down only what you can show. A policy that promises "all endpoints, always" is harder to defend than one that defines the in-scope population, the expected check-in interval, and the response when a laptop goes quiet. The second version gives you something to measure, which is the whole point of evidence.

What does "running" actually mean?

Running means the sensor is present, reporting recently, and in a state you would call healthy. That is three separate facts, and each fails in its own way:

• Present. The software exists on the device. Most inventories answer only this.
• Reporting. The device checked in within your defined window. A stale check-in is the most common silent failure.
• Healthy. The sensor is on a supported version and reporting normal operation, not a degraded or disabled state.

Define the window in your policy before the audit. "Checked in within the last 24 hours" is a testable sentence. "Regularly" is not. When a laptop is off for two weeks of leave, the exception record should say so, with dates, instead of leaving an auditor to find a stale row.

Why is a console screenshot not enough?

A console shows the present. The Hexnode-hosted guide states the gap directly: a management console shows the current state of the fleet, while auditors need historical evidence that controls operated consistently throughout the audit period. A report pulled only at audit time can answer only for the present.

Most SOC 2 reports with an operating-effectiveness opinion cover a period, not a day, so the evidence has to as well. The practical fix is a recurring export, generated by the system and timestamped by the system. The same guide advises favoring evidence the system generates and timestamps over anything captured manually, because a screenshot without a source and a date is hard for an auditor to trust.

Store the exports somewhere central, with the metadata intact. If a file cannot show when and where it was produced, it is closer to an anecdote than a record.

How do you show the EDR population is complete?

Reconcile the EDR console against a second, independent source of devices: your identity provider's device list, your MDM roster, procurement records, or network observation. The question is not "how many devices does EDR see?" but "which devices exist that EDR does not see?"

Hexnode's example makes the stakes concrete: coverage evidence for 40 laptops has limited value unless those 40 represent the complete population that should be covered. A tool can only report on what it has been installed on, so the count it gives you can be accurate and still incomplete.

The same independence problem appears in encryption evidence and in patch evidence. In all three, the control's own console cannot establish the population. Something outside it has to.

Do auditors want proof that EDR is actually used?

Yes. Having sensors deployed is not the same as operating the control. JumpCloud's guidance on proving endpoints are secure says that just having EDR sensors is not enough, and that you need proof of active use. The evidence it recommends is dashboard reporting on how often threats are caught, how investigations progress over time, and which automated containment steps the tool has taken.

Konfirmity's SOC 2 endpoint guide goes further on response. It recommends sending EDR logs to a SIEM, defining playbooks for isolating infected endpoints and collecting forensic evidence, and keeping incident response records that show how alerts were handled.

Treat this as the second half of the package. Coverage proves the sensor is there. Alert history and handled incidents prove someone is listening to it.

Where does EDR evidence usually break?

Four failure modes account for most of the awkward audit conversations, and each is detectable before the auditor arrives:

• Orphaned devices. A laptop is reimaged or re-enrolled and appears twice, or not at all. The EDR count and the asset count drift apart, and nobody notices until reconciliation.
• Silent sensors. The service stops after an operating system update. The device still looks enrolled everywhere else, so only the last check-in reveals it.
• Unsupported versions. The sensor is reporting, but on a release the vendor no longer supports. Whether that counts as healthy is a decision your policy should make in advance, not an auditor's judgment call.
• Shadow laptops. A contractor or a spare machine touches production without ever being enrolled. It cannot appear in any export from the tool that never saw it.

Run the reconciliation monthly, not annually. A monthly cadence turns each of these into a small, dated, closed exception instead of a finding discovered mid-audit.

How should you prepare for sampling?

Auditors rarely read every row. They pull a population, select a sample, and trace each sample to its evidence. Your job is to make every traced path short and boring: pick a laptop from the inventory, find it in the EDR export for a given month, see a recent check-in, and see that any gap on that device has a closed exception.

Rehearse it yourself. Choose ten laptops at random from your asset list and try to produce, for each, the sensor version, the last check-in in three different months, and any exception record. Where you cannot, the auditor will not either. Confirm the population definition and the sample approach with your auditor early, since both vary by firm and by control.

What should a defensible EDR evidence package contain?

A package that survives sampling has five parts:

1. Scope statement. What counts as an in-scope device, and who owns the list.
2. Periodic exports. Per-device sensor version and last check-in, system-timestamped, covering the whole period.
3. Reconciliation. The EDR list compared with an independent device source, with unmatched devices explained.
4. Exception trail. Each stale or missing sensor, when it was detected, what was done, and when it closed.
5. Usage evidence. Alert history, investigations, and containment records.

Notice what is absent: a claim that nothing ever went wrong. A working monitor finds drift. A year with zero exceptions invites the question of whether anything was watching, so keep the trail and present it.

Where does continuous device evidence fit?

Spot exports are a stopgap. The durable answer is a record the devices produce about themselves, continuously, from a sensor on the host rather than from a person assembling a spreadsheet. SAUTERA is an infrastructure-trust platform built on that idea: it scores device posture from observed telemetry and reports "Unknown" when it cannot prove a state, instead of rounding a missing signal up to a pass.

That honesty is what auditors reward. A device whose EDR status cannot be established belongs in the exception list, not in the compliant count. The same logic underlies continuous monitoring on devices: define what to observe, observe it on a schedule, and keep the history. When a fix is needed, such as reinstalling a sensor on a quiet laptop, a person approves it and the action is recorded.

Takeaway

Installed is not running, and running is not used. Prove all three with system-timestamped exports across the period, a population reconciled against an independent source, an exception trail, and records of alerts actually handled.

Want to see which laptops your EDR has quietly lost? Start with a free SAUTERA posture assessment and get a device-level evidence record you can hand to your auditor.