Open source endpoint security for SOC 2

What SOC 2 asks of endpoints and how open source answers it

SOC 2 security criteria apply to every SOC 2 report, and for endpoints the relevant controls sit mainly in CC6.7 and CC6.8, with monitoring support from the CC7 series. CC6.7 expects you to protect endpoint devices, control removable media and secure transmission channels. CC6.8 expects you to prevent, or detect and act on, unauthorized or malicious software, including restricting software installation and detecting unauthorized changes to software and configuration. A company with laptops, servers and remote staff needs a defined way to show each of these controls working for every device in scope, not only on the day the examination starts.

The distinction that matters most is between a Type 1 and a Type 2 report. A Type 1 covers whether controls are designed suitably as of a date, while a Type 2 adds an opinion on operating effectiveness over a period, so the auditor will sample evidence from across the whole observation window. A single scan or a screenshot of a configuration at the start of the year will not carry the examination. Your endpoint evidence has to be generated continuously: Wazuh agent inventory and alerts, osquery-based Fleet policy results over time, and records of devices that failed and were remediated. Confirm with your auditor which sampling approach and evidence formats they expect before the period opens.

DeployOpen plans, implements and documents these controls and the evidence they produce, but it does not issue the SOC 2 report. That opinion comes from your independent CPA firm, which will also judge whether your system description and control design match what is actually running. Before you commit to a tool, list every device class in scope, decide which controls each one must evidence, and ask your auditor to review that mapping. The AICPA's Trust Services Criteria and their revised points of focus are the reference for that conversation.

Mapping CC6.5, CC6.7 and CC6.8 to endpoint controls

This table maps three SOC 2 common criteria to the endpoint functions an assessor will ask about, the configuration options in Wazuh, Fleet and disk encryption checks that can produce evidence, and what to confirm in your own environment. Read each row as a question to answer with a configuration, a schedule and a retained record, not as a statement that a tool satisfies the criterion on its own.

Requirement	What the endpoint function must do	How to configure Wazuh, Fleet and disk encryption checks
CC6.5: Remove data and software before assets leave control	Remove company data and unapproved software from devices before reuse, resale, return or transfer out of the organization's control	Use Fleet to record installed software and device inventory at retirement; use osquery queries for installed applications and user profiles; confirm wiping or retirement steps in your asset process and keep the wipe record
CC6.7: Restrict transmission of data	Limit where data can be sent from endpoints and enforce secure channels for data in transit	Use Wazuh File Integrity Monitoring and log collection to watch transfer tools and configuration; confirm network egress controls outside the agent scope; collect evidence of encrypted protocols in use
CC6.7: Encryption on endpoints	Encrypt endpoint storage that holds company data, including laptops and portable devices	Create a Fleet policy asking whether full-disk encryption is enabled on each platform (for example, BitLocker or FileVault status); review the pass and fail view and keep dated exports; confirm recovery key handling
CC6.7: Removable media and endpoint protection	Restrict or monitor removable media use and keep endpoint protection settings in place	Use osquery to list mounted USB storage; use Wazuh Security Configuration Assessment checks for hardening baselines; confirm which removable media controls your endpoint management platform enforces
CC6.8: Prevent or detect unauthorized software	Stop unapproved installations where possible and detect software that appears outside the approved set	Use Fleet policies or osquery queries to compare installed software with an approved list; use Wazuh alerts on new packages and unexpected processes; confirm the approved list is owned and reviewed
CC6.8: Detect unauthorized changes	Detect changes to software and configuration parameters on endpoints	Enable Wazuh File Integrity Monitoring on system binaries and configuration files; use Security Configuration Assessment policies to detect drift from the hardening baseline; confirm alert routing and ticket linkage
CC6.8: Change control and anti-malware	Tie approved changes to a defined change process and keep anti-malware active and current	Match Wazuh and Fleet change alerts to change tickets during the review period; use Fleet policies to check that anti-malware is running and up to date; confirm which anti-malware product is the system of record
CC6.8: Scan from outside the entity	Scan information assets from outside the organization in addition to internal monitoring	Use an external scanning service or a self-hosted scanner for internet-facing hosts; this is outside the endpoint agent scope, so confirm the provider, schedule and report retention with your assessor

How Wazuh, osquery and Fleet split the device evidence

Wazuh is the broadest of the three and the most likely system of record for alerts, configuration assessment and vulnerability findings. It is built from four components: the Wazuh indexer, which stores alerts in a full-text search and analytics engine, the Wazuh server, which analyzes agent data with decoders and rules, the Wazuh dashboard, and the Wazuh agents installed on endpoints. Agents run on Linux, Windows, macOS, Solaris, AIX and HP-UX, and agentless monitoring covers devices such as firewalls through syslog collection and periodic API probing.

Compliance views: The dashboard includes prebuilt views for PCI DSS, GDPR, HIPAA and NIST 800-53. These are framework mappings, not a SOC 2 report, so you still need to map them to the CC criteria yourself.
Security Configuration Assessment: Scans check hosts against hardening baselines and record pass or fail results over time, which can show configuration state across the period.
Vulnerability detection: Findings come from the software inventory agents collect, matched against the Wazuh CTI platform or an offline repository.
Central management: The server manages agent configuration and upgrades remotely, so change records for agents can be pulled from the server.
Deployment options: Installation can use Docker, Kubernetes, Ansible, Puppet or an offline guide, which affects where the evidence is stored.

Confirm with your own environment which Wazuh rules and assessment policies are enabled, and retain the configuration that produced each result so the evidence can be reproduced for the auditor.

Keeping endpoint evidence continuous across a Type 2 period

A Type 1 report tests whether controls are suitably designed as of a single date, while a Type 2 report adds an opinion on whether those controls operated effectively across the whole observation period. For endpoints, that difference changes the job. A well-configured Wazuh deployment and a Fleet policy set on the day of the auditor's walkthrough prove the design only. The Type 2 question is whether the same checks ran, returned results and were acted on in every month of the window, so evidence has to accumulate continuously rather than be assembled at the end.

Four record sets need to run unbroken across the period. Fleet policy results show which devices passed or failed checks such as disk encryption at each run, so the team should confirm how often results are exported or snapshotted and where history is kept. Wazuh agent inventories and alert records show which endpoints reported and what was escalated, and the Wazuh indexer retention settings determine whether early-period alerts still exist at audit time. Change tickets must link to software and configuration changes detected on endpoints. Auditors typically select samples from these populations across the period and test each sample, so gaps in any month, and unexplained devices that stopped reporting, are the findings most likely to matter.

Management's written representations under AT-C section 205 cover the system description and the controls it describes, so the endpoint controls written into that description must match what the tools actually do. The AICPA Auditing Standards Board exposed proposed revisions to its baseline attestation standards in February 2026, which would apply to engagements beginning on or after June 15, 2029. Ask your CPA firm how those proposals, if adopted, would affect your examination period and the representations you sign, and confirm this before you fix your evidence retention design.

What auditors ask to see for endpoints

Which devices are in scope for a SOC 2 endpoint review?

Any endpoint that can reach the system described in your SOC 2 report, including laptops, servers, virtual machines and containers hosts that store or process in-scope data or administer it. Auditors start from your system description and asset list, then check that each device class is either covered by an agent or policy or documented as an exception. Scope is set by your own architecture and by the auditor, so confirm the boundary with them early. Wazuh agents cover supported Linux, Windows and macOS systems, and Fleet enrolls macOS, Linux, Windows, ChromeOS, iOS and Android devices, so the in-scope list should map to the enrollment records these tools produce.

How do you keep the endpoint inventory complete over time?

The inventory is complete when the tooling can be compared against an authoritative source such as your directory, MDM or asset register, and gaps are reviewed on a schedule. Fleet collects user accounts, device health, installed software and security settings from enrolled devices, which gives you a host list to reconcile. Wazuh agent inventories and its server-side agent listing serve the same purpose for server estates. Keep dated exports of these lists as evidence, and record how devices that appear in the directory but not in the tool are handled. Confirm with your auditor how often they expect the reconciliation to run across the Type 2 period.

How is disk encryption status proven for each device?

Disk encryption is proven per device with a dated query result, not a policy document alone. Fleet policies are yes or no osquery questions, so a policy can ask whether full disk encryption is enabled on each host, and the policies page shows which devices pass or fail. Export the pass and fail results at regular points in the period and keep them with the policy definition. Failing devices should carry a ticket with the remediation date. Confirm with your auditor which encryption checks and sampling approach they will accept, since the evidence depends on how your tooling reads the encryption state on each operating system.

How are malware and unauthorized software detected and acted on?

Auditors look for a detection control, a documented response and records showing both ran during the period. Under CC6.8, the criterion expects controls that prevent, or detect and act on, unauthorized or malicious software. Three components can produce evidence here:

Fleet queries installed software and matches it against vulnerability sources such as the NVD and OSV, and its policies can flag prohibited software.
Wazuh collects inventories and alerts on configuration and integrity changes, with its Security Configuration Assessment checks available as documented capabilities.
Your anti-malware product, where you run one, supplies its own detection logs.

Keep the alert records, the triage tickets and the response actions together. Confirm with your auditor whether a dedicated anti-malware product is expected for your environment.

How are changes to endpoint configuration approved and recorded?

Each change to a baseline should trace back to an approved change request, and the monitoring tool should show that the change happened. CC6.8 points of focus include a defined change control process and detecting unauthorized changes to software and configuration parameters. Wazuh can monitor files and configuration on agents and manage agent configuration remotely, so change records can be matched against detected modifications. Fleet's audit activity log is a Premium feature and records administrative actions, which is useful when reviewing who changed a policy or script. Ask your auditor to sample a change from request to approval to detection.

How are endpoint control exceptions tracked and remediated?

Every failed policy or unmanaged device needs a recorded exception, an owner, a compensating control where one applies, and a remediation or review date. Auditors typically test whether exceptions are approved and whether they close on time, so an exception register is the core artifact. Fleet shows failing devices per policy, which gives the starting population for each exception. Wazuh vulnerability detection correlates agent software inventories with vulnerability data from its CTI platform or an offline repository, which feeds remediation tickets. Keep the register, the ticket history and the closure evidence in the same audit folder.

How are devices of terminated staff handled?

The evidence should show that access to the device was removed and that the device was recovered, wiped or retained under a documented process, within a timeline your own policy sets. The linked event is the leaver record in your HR or identity system, so the device record should be traceable to it. Fleet can show the device's last recorded user and health state, and Wazuh agent status shows whether a host is still reporting. Retain the removal ticket, the wipe or return confirmation, and the final inventory record. Confirm the required timeline and retention period with your auditor and your own policies, since neither is set by SOC 2 itself.

Can we produce this evidence ourselves, and what does a partner add?

Your team can produce the evidence if it has owners for the tools, a reconciliation routine and a folder structure matched to the criteria. Much of the effort is recurring: dated exports, exception reviews and sample pulls across the Type 2 period. A partner can implement and document the endpoint tooling, define the policies and evidence schedule, and prepare the packages your auditor requests. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure and prepares controls and evidence for compliance assessments, but it does not issue the audit opinion, which remains with the independent CPA firm. Work is typically fixed-scope and agreed in writing before it starts, and the quote follows from that scope.

Endpoint evidence auditors request and where it comes from

This table maps the endpoint evidence a SOC 2 examiner usually asks for to the control it supports and the open-source component that produces it. Read each row as a question to answer before fieldwork starts: what the auditor will sample, which system holds the record, and how long it must be kept. Confirm sampling populations, retention periods and the form of evidence with your auditor early, because a Type 2 period depends on evidence that exists for the whole window.

Evidence item	Control it supports	Producing component
Device inventory exports	CC6.1 and CC6.2 asset and access scope, CC7.1 asset visibility	Wazuh agent inventory, Fleet host list with enrolled devices and users
Fleet policy pass and fail history	CC6.8 and CC7.1 configuration and unauthorized software checks	Fleet policies page results, exported on a recurring schedule with dates
Disk encryption policy results	CC6.7 protection of endpoint devices and data at rest	Fleet yes or no policy for disk encryption status per device
Wazuh agent status and alert records	CC7.2 monitoring of system components, CC7.3 event evaluation	Wazuh indexer alert store and agent connection status history
File integrity or configuration assessment results	CC6.8 detection of unauthorized changes, CC7.1 configuration monitoring	Wazuh file integrity monitoring and Security Configuration Assessment reports
Change control tickets linked to endpoint configuration	CC8.1 change management, CC6.8 defined change control process	Ticketing system records matched to Fleet or Wazuh configuration change events
Vulnerability scan outputs	CC7.1 vulnerability identification, CC7.2 monitoring for anomalies	Wazuh vulnerability detection reports, Fleet vulnerable software lists
Access review records for endpoints and local admin rights	CC6.2 and CC6.3 access provisioning and removal	Exports of local administrator and user accounts from Fleet, reviewed and signed by the owner
Sampling and retention questions	Auditor sample size, period coverage and retention of exported records across the Type 2 window	Confirm with the auditor before fieldwork which dates, populations and file formats they will accept

Which open-source platforms fit the endpoint controls

SOC 2 endpoint evidence usually comes from several tools working together: one for agent telemetry and configuration checks, one for device posture questions, and one for the keys that protect data at rest. Each platform below covers a different part of that chain, and each leaves gaps that the design has to close on purpose.

Wazuh for agent monitoring

Wazuh is the core of most SOC 2 endpoint designs here. Its agents on Linux, Windows and macOS report to a server that runs security configuration assessment against benchmarks, correlates installed software with vulnerability data, and stores alerts in its indexer. Its core repository is licensed under GPL version 2, and the current release line is 4.14, with 4.14.9 released on 14 October 2026. Check agent coverage for every operating system in scope, and confirm how you will retain alerts across the audit period. Wazuh does not, by itself, prove disk encryption or device posture for every host.

Fleet policies for device posture

Fleet asks yes or no questions of enrolled devices, such as whether disk encryption is on or a screen lock is set, and shows which hosts pass or fail each policy. That pass or fail history is the kind of point-in-time evidence a Type 2 sampling exercise asks for. The core is MIT licensed, but code under ee/ requires a paid subscription for production use. The Free tier can be self-hosted, while label-based policy targeting and the audit activity log are Premium features. Confirm which features your evidence plan needs before choosing a tier.

osquery as the query engine

osquery exposes running processes, loaded kernel modules, open network connections, hardware events and file hashes as SQL tables, and its osqueryd daemon runs scheduled queries across a fleet. Both Fleet and Wazuh build on this kind of host telemetry, so osquery is often the layer that answers ad hoc questions about configuration. It is licensed under Apache-2.0 OR GPL-2.0-only. Ask who writes and maintains the query packs, how query results are retained, and how a query change is approved under your change control process.

Velociraptor and Falco as complements

Velociraptor adds hunting and collection on endpoints, and Falco adds runtime detection on Linux hosts and Kubernetes nodes. Neither is a substitute for the compliance evidence chain above, and both add operating scope that your team must staff and document. Include them only where a specific control gap needs them, such as forensic collection after an alert or runtime monitoring of container workloads. Confirm the operating system coverage and the response process for each before adding them to the control narrative.

OpenBao or Infisical for key material

If disk encryption keys, recovery keys or certificates are managed centrally, a secrets platform becomes part of the endpoint control set. OpenBao is licensed under MPL-2.0 and Infisical is MIT licensed except for content in ee directories, which carries a separate enterprise license. Auditors will ask who can read, rotate and recover keys, so document access and logging for the key store as carefully as the endpoints themselves. Neither tool encrypts a disk on its own, so confirm which endpoint platform performs the encryption and where its recovery keys are stored.

How the endpoint control rollout runs before the audit window opens

The sequence fixes the system boundary, puts controls and device evidence in place, and proves the evidence can be collected before the Type 2 observation period starts. Pacing depends on device count and scope confirmed in writing.

Define the in-scope systems and boundary
Your team and DeployOpen list the endpoint populations that fall inside the SOC 2 system description: corporate laptops, production and administrative servers, virtual machines and any remote or contractor devices that touch in-scope data. Each population is tied to the services and criteria it supports, and exclusions are written down with reasons. The step closes when management signs off on the boundary and the list of device owners, so the system description and the endpoint inventory agree.
Deploy agents and enroll devices
DeployOpen installs Wazuh agents on supported Linux, Windows and macOS hosts, and enrolls laptops and workstations into Fleet with osquery so device health and installed software are visible. Deployment uses your existing software distribution or configuration management, so changes go through the same path you already audit. The step closes when an inventory report shows each in-scope device as enrolled, reporting and tied to a named owner, with unreported devices listed as exceptions for follow-up.
Write endpoint policies for encryption, updates and malware
DeployOpen and your security team translate the control design into Fleet policies and Wazuh checks: disk encryption status, OS update currency, anti-malware presence, screen lock and restrictions on unapproved software. Each policy is written as a yes or no question with a stated owner, expected result and remediation path. Policy wording is reviewed with your auditors before go-live, since the design will be tested against it. The step closes when every policy is published, assigned to the right device groups and showing pass or fail results on the Fleet policies page.
Link software and configuration changes to change control
Your change management process defines how approved software and configuration baselines are recorded, and DeployOpen maps Wazuh file integrity and configuration alerts to that process. Unexpected installs or changes raise alerts that must reference a ticket, or be triaged as unauthorized. Ownership of exceptions is assigned in advance. The step closes when a test change, both approved and unapproved, produces the expected ticket linkage and alert trail that an auditor could follow from start to finish.
Set up alert handling and response ownership
Failed policies and Wazuh alerts are routed to a queue with named triage owners, severity levels and documented response actions such as isolating a host, reinstalling a device or requesting an exception. Where automated response is used, its scope is limited and approved in writing. Retention periods for alerts and policy history are confirmed with your legal and records teams before they are configured. The step closes when a test alert has been triaged, closed with notes and recorded in your ticketing system.
Run a dry-run evidence collection
Before the period starts, DeployOpen runs a full evidence pull as if the auditor had asked for it: device inventory, policy results, patch and encryption status, alert and ticket samples, and change records. Gaps are logged where a device, policy or record cannot be shown, and each gap is fixed or documented as an exception. Reviewers from your compliance team check that each evidence item maps to a control and a point of focus. The step closes when the dry run produces a complete, dated package with no unexplained gaps.
Start the observation period
The observation period begins only after the boundary, policies, change linkage and dry run are accepted in writing. Evidence collection continues on a recurring schedule, and any change to scope, tooling or policy is logged with the date and approver, since the Type 2 opinion covers operating effectiveness across the whole period. Confirm the period start and end dates, and the auditor's sampling approach, with your auditor in advance. The step closes when the first period-end evidence snapshot is stored under your retention rules.

What tooling alone does not satisfy

A SOC 2 report is an examination of how your organization designs and operates its controls over a period, not a list of tools that were installed. Wazuh, osquery-based Fleet policies and disk encryption checks produce device data, but the policies, owners, reviews and exception records that give that data meaning must come from your own control environment.

Written policies and named owners

Auditors expect a documented endpoint security policy, a defined change control process and a named owner for each endpoint control, such as the person who approves Fleet policy changes or Wazuh rule updates. A dashboard showing passing devices does not show who decided what "passing" means. Check that each control in your system description points to a written procedure, an owner and a review date that falls inside the Type 2 period.

Evidence of human review of alerts

Wazuh and Fleet generate alerts and failing-device lists continuously, and an auditor will ask who looked at them, when, and what happened next. Operating effectiveness depends on a repeatable triage record: the alert, the analyst, the disposition and the ticket. Confirm that someone reviews endpoint alerts on a defined cadence and that reviews leave a trace you can sample.

Unmanaged exceptions

Every endpoint that fails a Fleet policy, runs unsupported software or sits outside agent coverage needs either a remediation ticket or a documented, approved exception with an expiry date. Exceptions that accumulate without an owner are among the most common findings in device testing. Ask who can grant an exception, how long it lasts and how the exception list is reviewed.

Personal devices outside the boundary

If staff reach production systems or customer data from personal laptops or phones, those devices may fall inside the system boundary even though no company agent runs on them. Fleet can enroll some device types, but unmanaged devices produce no telemetry at all. Define which devices are in scope, how access is restricted for those that are not managed, and how the boundary is documented in the system description.

Dedicated anti-malware where the criteria call for it

CC6.8 asks for controls that prevent or detect and act on malicious software, and its points of focus include antivirus and anti-malware software. Wazuh can detect file changes, suspicious activity and vulnerable software, but whether it satisfies your anti-malware expectation depends on your design and your auditor's view. Decide early whether a dedicated anti-malware product is needed, and document the reasoning either way.

System description and management representation

A SOC 2 report depends on management's written description of the system and a signed representation letter that the description and controls are accurate. The platform cannot write either document. Your team must describe the endpoint population, tools, owners and data flows, and management must stand behind those statements. Plan for this document to be reviewed and maintained across the whole period, not only at the start.

What does open source endpoint security for SOC 2 cost and take?

What drives the cost of open source endpoint security for SOC 2?

The main drivers are the number of devices, the infrastructure that hosts the management and log tiers, the implementation scope, and the staff time needed to review evidence every period. Open-source licenses for Wazuh, osquery and Fleet's free tier carry no license fee, so the spend shifts to servers, storage, engineering time and any paid subscriptions you choose. Device count affects agent licensing only where a commercial tier is involved, but it also drives storage, query load and the number of policy results someone must review. Ask any partner for a quote that lists one-time work (design, deployment, policy build, evidence mapping) separately from recurring work (hosting, upgrades, evidence collection, support).

Can a team run SOC 2 endpoint security without outside help?

Yes, a capable internal team can deploy Wazuh agents, write osquery-based checks and collect evidence, provided it has time and clear ownership. The harder parts are usually not the tools but the recurring duties: reviewing failed policies, keeping a documented change process, proving the controls worked across the whole Type 2 period, and keeping the auditor's sample requests answered. Teams with thin IT staffing often find the review cadence is the constraint. A partner can cover some of that work under a written scope, but the control owner, the decisions and the sign-off remain with your organization.

How long does open source endpoint security for SOC 2 take to set up?

The timeline depends on how many endpoint types you have, how many already have agents, and whether the evidence process is defined before rollout. The setup phase covers inventory, agent deployment, policy design and a dry run of evidence collection. Because a SOC 2 Type 2 report covers an operating period, controls should run for that period before the auditor tests them, so the rollout should start well before the audit window opens. Ask a partner for a dated plan based on your device inventory rather than a generic duration, and confirm the start date of your observation period with your auditor.

Does SOC 2 endpoint monitoring need Fleet Premium for label targeting and audit logs?

Fleet's pricing page lists Free at $0 per host per month without support and Premium at $7.00 per host per month, and it places label-based policy targeting and the audit activity log in the Premium tier. Free can be self-hosted, so a team can run osquery-based policies without a subscription, but targeting policies by group and keeping a log of who changed what in Fleet may require Premium. Confirm current pricing and feature lists with Fleet before you decide, and test whether your evidence needs the audit log or whether your change records can live in your ticketing system.

What does an implementation partner deliver for SOC 2 endpoint evidence?

A partner typically delivers a written scope covering the systems in boundary, the endpoint controls to be built, the deployment and hardening of Wazuh and the chosen Fleet tier, the policy and rule content, and an evidence map that ties each control to a system report. Deliverables often include runbooks for the recurring review, a sample evidence pack, and training for the staff who will own the controls. Most engagements are fixed-scope and agreed in writing before work begins. DeployOpen prepares systems, controls and evidence for an assessment, but the independent auditor issues the report. Ask any partner which items are one-time and which are retained support.

What staff time does a SOC 2 endpoint program need each month?

Ongoing effort is mainly review work: checking failed device policies, confirming patch and encryption status, triaging Wazuh alerts that touch in-scope systems, and keeping change and exception records current. The volume depends on device count, how many policies you enforce, and how often devices drift out of compliance. Staff also need time for periodic access and configuration reviews and for pulling evidence when the auditor asks. Estimate this with your own device counts during planning, and ask any partner to show a sample review calendar with named roles for each task.

What costs appear later that buyers often miss?

Common surprises include upgrade work when Wazuh and Fleet release new versions, storage growth as retention periods lengthen, and the cost of rework when the auditor asks for evidence the team never collected. Disk encryption and malware evidence may need checks you did not plan for, and changes to the system description can force a rebuild of the evidence map. Ask whether upgrades, retention changes and auditor follow-up questions are included in the quote, and confirm how the support retainer is priced before signing.

Should a SOC 2 team choose build, partner or a commercial EDR product?

The choice depends on how many endpoints you have, how much in-house security engineering exists, and whether you need around-the-clock response. Building in-house keeps license costs low but puts the work of tuning, upgrades and evidence on your staff. A partner can deploy and document the stack and hand over runbooks, while your team keeps operational ownership. A commercial product can reduce the build effort but introduces its own license and integration costs. Compare the total cost of each option over the audit period, and ask vendors to list what evidence their product produces for CC6 and CC7.

What to ask an implementation partner before signing

Start with the mapping. Ask the partner to show, in writing, which CC6 and CC7 criteria each endpoint control is intended to support, and which points of focus they address and which they treat as out of scope. The points of focus under CC6.7 (protecting endpoint devices and removable media), CC6.8 (detecting unauthorized software and configuration changes) and CC6.5 (removing data from assets before they leave your control) are where endpoint evidence is most often questioned, so a mapping that stops at the criterion title is not enough. Ask who maintains the mapping after go-live and how it is updated when your system description changes, because the description is what the auditor tests against.

Next, ask how evidence leaves the platform and reaches the CPA. Ask for a sample export from Wazuh alerts, osquery-based Fleet policy results and disk encryption checks, showing the device identifier, timestamp, policy name and pass or fail state, and confirm that the export preserves the query history over the full observation period rather than a rolling window. Ask who reviews alerts each day, what the escalation path is, and how that review is recorded. An auditor will test whether alerts were acted on, not only whether they were generated. Also ask how exceptions are tracked: a device that fails a policy, a disk that is not encrypted or an agent that stopped reporting needs a ticket, an owner, a justification and a closure date. Ask for the ticket template and the reporting view before signing.

Finally, ask what is handed over and what you will still own. Request the runbooks for agent deployment, policy changes and exception handling, the configuration baseline under version control, and a written description of how the Fleet Premium features the design relies on are licensed, since EPSS and CVSS scoring, OS update enforcement and label-based targeting are listed as Premium capabilities. Confirm whether the partner will help prepare the observation period, including a dry run before the period starts, and what support is included when the auditor asks for clarifications. Ask the partner to state which parts of the evidence still depend on your staff, such as the daily review and the management review of exceptions, so the readiness plan reflects who does what.

How DeployOpen scopes and delivers SOC 2 endpoint evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the endpoint monitoring and device evidence that a SOC 2 examination may draw on. We prepare the systems, controls and evidence for your auditor, while the independent CPA firm performs the examination and issues the report.

How we scope

Engagements are fixed-scope, with the systems, endpoint populations and criteria agreed in writing before work starts
The written scope names which CC6 and CC7 controls, device types and operating systems are in the Type 2 period
Scope records which endpoints are excluded and why, such as hosts without agents or unmanaged devices
We confirm with your auditor which evidence formats and sampling periods they expect before configuration begins

How we build

We deploy Wazuh agents and Fleet device policies for disk encryption, OS updates and endpoint protection checks
We configure osquery queries and policy pass or fail reporting so each control produces repeatable device records
We document configuration baselines, change control steps and how exceptions are raised, reviewed and closed
We test the controls against deliberate misconfigurations so you know the evidence captures failures as well as passes

How we hand over

Handover includes runbooks, configuration records, a control-to-evidence map and the operating procedures for your team
We prepare evidence extracts and dashboards that map to the agreed criteria, for review by your auditor
Administrators are trained on policy changes, agent upgrades and how evidence is retained across the Type 2 period
You receive the documentation and access needed to operate the platform without DeployOpen in the loop

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope
Retainers can cover platform patching, Wazuh release upgrades and periodic review of Fleet policy coverage
We can support evidence requests during the audit period, within the scope agreed in writing
Quotes follow from the written scope, so ask for the retainer terms and support hours in the proposal