Why this matters
Your SOC 2 report covers the systems that hold customer data. Those systems run on laptops. An engineer exports a customer file to a desktop. An analyst keeps a snapshot in a local test database. The auditor knows this and will ask how you control those machines.
The relevant criteria sit in CC6 and CC7: logical access to devices, protection from malware, detection of misconfiguration and vulnerabilities, and monitoring. In practice the auditor asks four things. Which machines exist? Are they encrypted? Are they patched? Can you wipe one tomorrow?
Endpoint controls are also the cheapest part of compliance to automate. Encryption, screen lock and patching are settings in a management tool. Set them once and they produce their own evidence every month. Audits sample, though: the auditor picks a few laptops and asks for proof as of a date, often months back. If you enrolled devices last month, scope the claim to the period you can prove. Overstating the window is where findings come from.
Before you start
Build a device list you trust. Export from your identity provider, your asset tracker, whatever management tool you run today, and your card spending. Reconcile by hand. The gaps are the story: machines nobody owns, a contractor on a personal MacBook, an old laptop in a drawer.
Pick a baseline. CIS Benchmarks and the hardening guides from Apple and Microsoft are defensible starting points. You do not have to apply every item. Record which ones you applied and why you skipped the rest, because a documented decision survives an audit better than silence.
Set scope by device class, not by person. Company laptops are in without argument. Contractor machines either enroll or get a written rule that they cannot reach production data. Personal devices are the hard case: if they can touch customer data, manage them or block them.
Choose tools before you write policy. You need mobile device management (Jamf, Kandji, Intune, Mosyle and similar) plus endpoint detection and response (CrowdStrike, SentinelOne, Microsoft Defender). Budget for the enrollment work, not only the license. Someone has to chase the last few machines.
How to do it
Write a one-page endpoint standard first. Every company laptop enrolled, full disk encryption on with keys escrowed, screen lock after a set idle time, OS patches inside a defined window, endpoint detection running, local admin by exception only. Name an owner and a review cadence.
Then work in the order below. Inventory comes first because a policy pushed to a half-known fleet creates false confidence. Enrollment is the real project. The settings take an afternoon.
Two things will drag. Developers who want local admin, and old laptops that were never enrolled. Handle both with a written exception: owner, reason, end date, compensating control. For admin rights that might mean endpoint detection is mandatory and the machine gets checked weekly.
Test remote wipe on a spare machine before you depend on it. You want to learn the flow on hardware you do not need.
- Build the inventory. Export from your identity provider, asset tracker and card statements into one sheet with a named owner per device. Use serial number or hardware ID as the join key, since people rename laptops.
- Enroll every laptop in MDM. Use zero-touch enrollment where you can: Apple Business Manager or Windows Autopilot. For machines already in the field, send a one-click link and set a deadline.
- Turn on disk encryption. FileVault on macOS, BitLocker on Windows. Escrow recovery keys to the management tool or your password vault, and restrict who can read them.
- Set screen lock and password rules. Lock after a short idle period and require a password or biometric to resume. Keep the idle time short enough to matter and long enough that people do not disable it.
- Automate patching. Set a patch deadline by severity and cover browsers, the endpoint agent and the management agent alongside the OS. Show users a countdown so updates do not land mid-call.
- Deploy endpoint detection and response. Install the agent, turn on tamper protection so users cannot switch it off, and route alerts to someone who reads them. An agent nobody monitors is a license, not a control.
- Remove local admin rights. Make standard user the default and run an exception process for engineers. If you keep admin, require the endpoint agent and a shorter patch window on those machines.
- Enable remote lock and wipe. Turn the feature on and give two people the rights to use it, so offboarding does not stall when one is away. Log every wipe with who, when and why.
- Report monthly. Pull a compliance report on the first working day of each month and file it with the date in the filename. That archive becomes your evidence pack at audit time.
How to check it worked
Rehearse the audit request. Pick a date two months back, pull that day's compliance report, and choose three devices at random. For each, assemble the inventory record, encryption status, last patch date, agent status and any open exception. If that pack takes an hour, you are in decent shape.
Test the alarms. Switch off the endpoint agent on a test machine or unenroll it, then wait a day. If nobody notices, the monitoring part of CC7 exists on paper only.
Reconcile counts. Compare devices enrolled, devices in the inventory, and devices bought. Anything bought and never enrolled is a finding waiting for a sampling day. Run the check monthly and keep the output.
Read the standard against reality. If it promises patches within a week and the report shows machines a month behind, either fix the fleet or change the standard to what you actually meet. Silent drift between policy and practice is the finding.
Mistakes to avoid
Treating the tool purchase as the project. Enrollment never finishes: agents go stale, laptops get rebuilt, contractors leave. Without a named owner and a monthly check, your fleet report is fiction by audit time.
Claiming a control for a period you cannot prove. Compliance reports carry dates, so keep the monthly exports from the day the control went live and store them where the auditor's request list can be answered without digging through chat.
Patching the OS and stopping there. Browsers, the endpoint agent, the management agent and meeting clients all get exploited. Point the policy at applications too.
Leaving local admin as the default for anyone who asks, with no exception list. And keeping evidence as undated screenshots scattered across email, chat and someone's desktop.
If you want a second opinion before the auditor sees the fleet, the Cloudverg SOC 2 readiness assessment runs three weeks at $7,500/month and includes scoping, a gap assessment against the Trust Services Criteria and a policy and evidence inventory. It is one option among several. Teams with a working management tool and a patient IT lead often do this work themselves.
Frequently asked questions
Do laptops need to be in scope for SOC 2?
Yes, if they can reach systems that hold customer data, which covers most work laptops. Include them in your system description and apply the endpoint controls in your standard. A machine that only opens public marketing pages is the narrow exception.
Does SOC 2 require mobile device management?
The Trust Services Criteria do not name a specific tool. What they require is that you control access to devices, keep them patched and detect problems. Most teams meet that with a management tool because manual tracking does not survive sampling.
What will the auditor ask for on endpoint controls?
Usually the device inventory, a compliance report from a specific date, encryption status, patch history and evidence of malware protection. They will also ask who reviews those reports and how exceptions get approved, so keep the review notes.