SOC 2 endpoint security and device management, what auditors check

What SOC 2 expects for SOC 2 endpoint security

A customer questionnaire or contract that asks for endpoint controls before a SOC 2 report exists usually needs two things answered. Under CC6.7, the organization must restrict how data is transmitted and protect endpoint devices and removable media. Under CC6.8, it must prevent, or detect and act on, the introduction of unauthorized or malicious software. In both cases, the controls must operate and leave evidence across the whole audit period, not only on the day the auditor looks. The auditor tests and reports on these controls. DeployOpen does not. The controls, their owner and the evidence stay with the organization, and an implementation partner can only help prepare the systems and records the auditor will request.

The criteria name no product, no minimum device count and no particular operating system. What an auditor expects depends on the environment. A company with a dozen office laptops on one operating system faces a different job from a company with contractors on personal machines, mixed macOS and Windows fleets, or production servers that engineers reach from home. Start by listing every device class that touches company data or systems, including servers, and every place removable media could carry data out. Then read the customer's questionnaire line by line, since many of its endpoint questions go further than the criteria require, and decide which of them the organization can answer with evidence.

Once the device inventory and questionnaire are settled, decide who owns each control: disk encryption, malware protection, software installation rules, removable media handling and disposal. Write down the evidence each one will produce and how often it is collected, because a control that is only checked once at the start of the period is hard to defend in a Type 2 examination. Ask the auditor early which evidence they will accept, how they want device samples selected, and whether the population of devices must be complete. Those answers set the scope of any endpoint tooling, and they should be confirmed with the auditor, not assumed from a vendor's documentation.

Which endpoint controls an auditor will sample

SOC 2 does not prescribe a particular endpoint product. Auditors test whether the organization's own controls over laptops, servers and removable media exist, are applied consistently and leave records that can be sampled. The cards below cover the controls that most often appear in endpoint testing and the evidence that shows each one working.

Disk encryption and screen lock

Auditors sample laptops and check that full-disk encryption and an automatic screen lock are enabled and enforced by policy, not left to the user. The device record is the proof: a list of managed devices with encryption status and lock settings, pulled from the device manager at a point in time and again across the observation period. Ask the organization to confirm which settings it enforces centrally and which depend on user choice, because the second group is hard to evidence. Exceptions need a documented reason and an owner.

Removable media restrictions

The criteria point to protecting removable media, so auditors ask whether USB storage is restricted or monitored and whether the rule is written down. Evidence includes the policy, the configuration that applies it to managed endpoints, and a sample of exceptions with approvals. Ask how the organization handles data copied to external media and whether it can show the restriction applied to a sampled device. Where removable media is allowed for business reasons, the approval record matters more than the default setting.

Anti-malware and detection coverage

CC6.8 expects controls that prevent or detect malicious software, and its points of focus name antivirus and anti-malware software directly. Auditors check that every sampled endpoint runs the agent, that definitions or detections are current, and that alerts reach someone who acts on them. The inventory of endpoints compared against the agent console is the usual test. Confirm whether the organization uses a commercial endpoint detection product or open-source tooling, and what it produces as evidence for each device.

Software installation control

Under CC6.8, auditors look for restrictions on installing software and for detection of unauthorized changes to software and configuration. A typical test pulls a list of installed applications from a sample of devices and asks who approved each one. Query results from osquery or a similar tool can serve as the population, but the organization must show what it does with unapproved software it finds. Ask for the approved-software list, the review cadence, and the ticket trail for a removed application.

Server configuration baselines

Servers fall under the same change and configuration expectations as laptops, and auditors often sample them separately. They look for a defined baseline, a scan or check against it, and a record of deviations that were fixed or accepted. Wazuh's configuration assessment compares monitored systems against YAML policies, mostly based on CIS benchmarks, and produces findings with remediation advice. The evidence is the policy in use, the scan results over time, and the tickets that show remediation. Confirm which benchmarks the organization adopted and who signs off on exceptions.

Asset return and wipe at offboarding

CC6.5 addresses removing data and software from assets before they leave the organization's control. Auditors sample leavers and compare the offboarding ticket with the device record: was the laptop returned, and was it wiped or its disk destroyed before reissue? Evidence is the completed offboarding checklist, the return or disposal record, and the wipe confirmation. Ask how long devices sit in storage before reissue, whether the process covers personal devices used for work, and who signs the disposal record.

Which tool produces which endpoint evidence

osquery is the query layer. It exposes operating system state as SQL tables, so a question such as which processes are running, which kernel modules are loaded, which network connections are open, which browser plugins are installed, what hardware events have occurred or what a file's hash is can be answered with a query rather than a manual check. The osqueryd daemon runs scheduled queries on each host, which is what turns a point-in-time look into repeatable evidence across an entire fleet of endpoints.

Process and module visibility: Tables for running processes and loaded kernel modules let you show what was executing on a device at the time of a query.
Network and software inventory: Open network connections and browser plugins give you data for CC6.8 points of focus on unauthorized software and communications.
File hashes: Hash queries let you compare binaries and configuration files against an approved baseline and detect unauthorized change.
Scheduled collection: osqueryd runs queries on a schedule, so results accumulate over time rather than existing only at audit time.
Open license: osquery is published under Apache-2.0 OR GPL-2.0-only, so confirm with your legal team which option applies to your distribution.

Before relying on osquery for evidence, confirm which tables your operating systems expose, how results are stored and retained, and who reviews them.

Detecting unauthorized software and changes

CC6.8 asks the organization to prevent, or detect and act on, unauthorized or malicious software on its systems. For laptops and servers, that means two things must be provable: you know what software should be present, and you notice when something appears or changes outside that baseline. Before any tool is deployed, the organization has to decide what counts as authorized software, who approves additions, and how exceptions are recorded. An auditor will test the tool output against that written decision, so the decision comes first.

The point of focus on a defined change control process maps directly onto the software inventory. An osquery scheduled query can list installed applications and running processes across the fleet, and Fleet policies can ask yes or no questions such as whether a prohibited agent is present or whether a required endpoint protection product is running. Wazuh's Security Configuration Assessment can check files, directories, registry keys and processes against YAML policies and recommend remediation. Alerting on new or modified binaries and on changed configuration parameters covers the point of focus on detecting unauthorized changes. Confirm the exact tables and policy formats for your operating systems in the current osquery and Wazuh documentation before you write them into the control matrix.

The point of focus on scanning information assets from outside the entity is easy to skip on internal endpoints. Document which external scans cover your public hosts and how their findings reach the endpoint team. Vulnerability processing then closes the loop: Fleet's guidance describes how vulnerability findings are triaged and routed to remediation, and the auditor will look for a ticket, a fix date and a re-check for each high-impact finding. Keep exception records with an owner, a reason, a compensating control and an expiry date, because an exception without an end date is usually the first thing an assessor questions.

How endpoint controls move from policy to audit evidence

This sequence turns a written device and removable media policy into endpoint checks that run across the audit period and produce samples an auditor can test. Each phase hands a defined output to the next, so gaps show up before fieldwork rather than during it.

Define endpoint scope and asset inventory
Start by listing every laptop, desktop and server that stores, processes or can reach in-scope systems, including personal devices used for work if they are allowed. The operations or IT lead owns this list, and the security lead checks it against the system description. The output is an asset inventory with owner, device type, operating system and the user or service it belongs to. You know the step is done when every in-scope system appears once in the inventory and each entry has a named owner.
Write the device and removable media policy
Draft a policy that states which endpoint protections are required, how removable media is allowed or blocked, how software may be installed, and how devices are wiped or destroyed when retired. Management approves it, and the policy references the control points it supports, including the points of focus under CC6.7 and CC6.8. The output is an approved, dated policy that staff have acknowledged. Confirm with your auditor how they expect policy approval and acknowledgment to be recorded.
Deploy agents and baseline queries
Install an osquery agent on each inventoried device and load a baseline set of queries that report running processes, loaded kernel modules, open network connections, hardware events and file hashes. If you use Fleet, enroll the hosts so the queries run through its server rather than ad hoc. The output is a fleet view in which every inventoried device reports in and returns data. Check the inventory against the enrolled hosts and investigate any device that is missing.
Set pass or fail policies and remediation owners
Translate each policy requirement into a yes or no question, such as whether disk encryption is enabled, whether antivirus is running, or whether an unapproved application is present, and express it as a Fleet policy or a scheduled osquery check. Assign a remediation owner and a documented fix path for each failing result. The output is a policy set with a written owner per check and a record of how failures are resolved. Test each policy on a known-good and known-bad device before you rely on it.
Add configuration assessment and removable media checks
Where you need configuration hardening evidence, run Wazuh Security Configuration Assessment on endpoints using policies suited to your operating systems, and review the findings that check files, directories, registry keys and running processes. Add checks that show whether removable media is restricted and whether unauthorized software is detected. The output is a set of configuration assessment results and a list of accepted exceptions, each with an approver. Confirm which Wazuh policies match your platforms and extend them where your standard differs.
Run continuous collection through the audit period
Keep the agents, policies and scans running for the whole audit period, and capture results on a schedule that matches your control matrix. Track failing devices to closure, and record every exception and its approval. For a Type 2 engagement, this is what supports operating effectiveness over the period. The output is a dated, retained series of policy results, remediation tickets and exception records. Ask your auditor which frequency and retention they expect before you set the schedule.
Hand samples to the auditor
Before fieldwork, pull the evidence the auditor selects, which typically includes policy results for sampled devices, remediation records and disposal certificates for retired hardware. Organize it by control and by device so each sample can be traced to the inventory and the policy that governed it. The output is a sample package the auditor can test directly without reconstructing history. Note that the auditor, not DeployOpen or your team, decides what sufficient evidence is and issues the report.

What must be in place before the auditor samples devices

An auditor samples devices only after the organization can show what it owns, what rules apply to those devices, and how exceptions and departures are handled. The six items below connect so that each sampled laptop or server can be traced from inventory to policy, enrollment, remediation and disposal.

Complete asset inventory

Every laptop, desktop, server, virtual machine and removable drive that touches in-scope systems needs a record with an owner, a location and a status. Auditors often start from a population list and pick samples from it, so an incomplete list undermines every later test. To check it, compare the inventory against identity provider accounts, cloud instance lists and the osquery host count reported by the fleet, and ask who is responsible for devices that appear in one source but not the other.

Documented endpoint policy

A written endpoint policy states which devices are permitted, which operating system versions are supported, how disks are encrypted, which software is prohibited, and how removable media is handled. It gives the auditor the control design to test against. To check it, confirm the policy names the same thresholds that the tooling enforces, and that the approver and review date are recorded.

Enrolled devices with agents

Each in-scope device should report to a management or query agent, such as osqueryd, under a configuration that the organization controls. Devices that are unenrolled or silent cannot show posture. To check it, pull the list of hosts that have not checked in within the period the organization defines, and confirm that each one has a documented reason and an owner.

Defined exception and remediation process

Some devices will fail a policy, such as an outdated patch level or a disallowed application. The organization needs a process that records the failure, assigns an owner, sets a remediation deadline, and records any approved exception with a reason and an expiry. To check it, select failing devices from the policy dashboard and trace each one to a ticket with a closure or approved exception.

Offboarding wipe or return records

When a device leaves the organization's control, through reassignment, repair or retirement, the data and software on it must be removed first, and the disposal must be recorded. Auditors commonly sample leavers and check both the account removal and the device handling. To check it, match each departed employee to a return or wipe record with a date, method and person who signed it off.

Tested evidence export

Screenshots taken on the day of the audit are weak evidence. The organization should be able to export policy results, device lists and remediation tickets for a chosen date range, and show that the export produces the same figures as the live console. To check it, run the export before fieldwork, compare totals against the dashboard, and keep the query or report definition with the output.

Who owns endpoint controls, who builds them and who tests them

The organization owns its endpoint controls. Management decides what the endpoint policy requires, who approves exceptions, who is accountable for each laptop and server, and whether the controls are operating. No outside party can take that accountability over, and the CPA firm will expect management to make written representations about the system description and controls. For endpoints, that means the organization must be able to explain its device inventory, its removable media rules, its anti-malware approach and its software approval process in its own words.

Policy ownership: Approve the endpoint security, acceptable use, removable media and asset disposal policies, and review them on a defined cycle.
Device owners: Name a person responsible for each laptop, workstation and server, including who takes action when a device fails a check.
Exception approval: Record who may approve an exception to a control, the reason, the compensating measure and the end date.
Unauthorized software decisions: Decide which software is allowed, who may request an addition, and how removals are enforced.
Management assertion: Sign the representations that describe the endpoint controls as designed and operating.

Before the audit, check that every control in the endpoint section names an owner who can explain it without the implementation partner in the room.

Endpoint gaps that cause exceptions in the report

Auditors test endpoint controls by sampling devices and dates, so a gap in one laptop or one unowned policy can become an exception in the report. The five gaps below recur across SOC 2 engagements, and each one has a check you can run before the auditor arrives.

Unmanaged personal devices

Staff who read customer data or push code from personal laptops or phones create endpoints the organization does not inventory, patch or monitor. Under CC6.7, auditors ask how devices that access company systems are identified and protected, so an unlisted device is hard to defend. Check that every device with access to production, email or source code is enrolled in your device inventory, and that access is blocked for devices that fail posture checks. Confirm the exception path with your auditor before relying on it.

Agents on some hosts only

An osquery or Wazuh agent that covers most servers but silently misses a few leaves a population the auditor cannot test as complete. Coverage gaps usually come from newly provisioned instances, autoscaling groups and machines rebuilt outside the standard image. Compare your agent inventory against your cloud and directory inventory, then ask the auditor how they will confirm completeness of the population they sample from.

Policies without an owner

Device policies such as disk encryption, screen lock or required antivirus need a named owner who reviews failing devices and decides on exceptions. A Fleet policy that shows failing hosts but has no one assigned to act on them is a control that runs without accountability. Record an owner, a review cadence and a remediation route for each policy, and keep the review record so the auditor can see the control operating over the period.

Removable media left uncovered

USB drives and external disks are a common route for data to leave an organization, and the criteria expect controls over them as well as over the laptop itself. Gaps appear when the policy says removable media is restricted but no device control enforces it, or when a laptop is retired with data still on its drive. Decide which media is permitted, enforce the decision on endpoints, and keep disposal records that show data was removed before a device left your control.

Evidence that cannot be reproduced

A Type 2 examination samples a device on a specific date, and the auditor needs the state of that device on that date, not today. If your tool only shows the current status, the sampled date cannot be shown and the test becomes an exception. Ask your tooling vendor or implementation partner whether historical results are retained, how long, and where they can be exported, and test one sampled date end to end before fieldwork.

Questions buyers ask about SOC 2 endpoint requirements

Does SOC 2 require a specific antivirus product?

No. The criteria do not name a product or vendor. CC6.8 asks the organization to prevent, or detect and act on, the introduction of unauthorized or malicious software, and one of its points of focus mentions antivirus and anti-malware software as one way to do that. Auditors look for a control that fits your environment, is applied to the devices in scope, and produces records. The choice depends on your operating systems, your threat model and what you can monitor. Document why you selected a tool, show that it is deployed to every in-scope device, and keep the alert or remediation history your auditor will sample.

Does osquery alone satisfy CC6.8?

Not on its own. osquery is a query engine that exposes running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes as SQL tables. That data can show you unauthorized software or configuration drift, which supports the detection side of CC6.8, but the criterion also expects a defined process for acting on what you find. You still need a software installation policy, an approved list or baseline, a change control path and records of how detections were investigated and closed. Ask your auditor which combination of tooling and procedure they will accept for your scope.

Does Fleet's free tier cover what the auditor needs?

It depends on which evidence your auditor will test. Fleet's policies page shows which devices are passing or failing each yes or no osquery check, which can support device posture evidence. Fleet lists OS update enforcement and the audit activity log as Fleet Premium features on its pricing page, so confirm current edition contents on that page before you plan around them. Check the license terms in the fleetdm/fleet repository as well. Map each control you claim to a feature in the edition you will run, and ask the auditor whether screenshots, exports or API output are acceptable as evidence.

How long must endpoint evidence be kept for SOC 2?

The criteria set no number of days or years. What matters is that the evidence covers the period your auditor tests. For a Type 2 report, that means records spanning the observation window, and the auditor will sample from it. Decide a retention period with your auditor based on your observation window, your policy and any customer or contractual requirements, then apply it consistently to device inventories, policy results, scan outputs, remediation tickets and disposal records. Write the retention rule into your policies so the period is defensible.

Can our team run SOC 2 endpoint controls without outside help?

Often yes, if you have staff who can operate the tools, write policies and sample evidence. The organization owns its controls and the auditor issues the report, so an internal team can do the work. The effort usually comes from deploying agents across every in-scope device, keeping inventories current, documenting exceptions and collecting records on a schedule. Teams that lack spare engineering time, or that need the evidence structured for a first audit, often bring in an implementation partner to prepare systems and evidence under a written scope. That partner does not issue the report.

What drives the effort and cost of endpoint controls?

The main drivers are the number and variety of devices, whether you run macOS, Windows and Linux, how many people work remotely, and how much of the stack you must build or integrate. Costs split into one-time work (selecting tools, deploying agents, writing policies, mapping controls) and recurring work (maintaining the fleet, reviewing alerts, patching, and supplying evidence each audit period). Tool licensing, hosting and staff time are separate line items. When you request a quote, ask for the scope in writing, the devices and platforms included, the evidence the partner will prepare, and which items are one-time versus recurring.

Which endpoint evidence will the auditor sample?

Auditors typically sample from device inventories, posture or policy results, antivirus or malware detection logs, removable media restrictions, encryption status, software change records and disposal certificates. For each sample they check that the control operated as described during the period. Keep records that show the device was enrolled, the check ran, failures were acted on and the outcome was recorded. Ask your auditor which artifacts they want in advance, because the format of the evidence matters as much as the control itself.

How DeployOpen prepares endpoint controls for audit

DeployOpen plans, implements and hardens osquery, Fleet or Wazuh inside your own infrastructure, under a fixed scope and deliverables agreed in writing before work starts. In practice that means deploying the agents to laptops and servers in your cloud accounts, data centers or air-gapped network, writing the queries and policies that match your endpoint standard, configuring the reporting that shows which devices pass or fail, and documenting how each piece maps to the control points you have chosen to test. The tools run in your environment and the data stays there, so the evidence they produce belongs to you from the start.

The evidence side is where preparation earns its keep. We help you define which device posture checks the auditor will see, such as disk encryption, endpoint protection, unauthorized software detection and removal of data before disposal, then capture dated exports, policy definitions and remediation records in a form the independent CPA firm can sample. Confirm with your auditor which populations, date ranges and formats they need before configuration begins, since that choice shapes how the queries and reports are set up.

Two limits matter for planning. DeployOpen prepares systems, controls and evidence, but it does not issue reports, attestations or certifications, and only an independent CPA firm can express an opinion on your controls. Nor can we guarantee an outcome, because the result depends on how your team operates these controls day to day. Your organization keeps ownership of its controls, its policies and its decisions about what counts as acceptable device posture, and it should ask any implementation partner to state those responsibilities in the written scope.

SOC 2 endpoint security and device management