Can we use personal laptops and phones (BYOD) for SOC 2?

The criteria do not forbid it, but every personal device that reaches company data is in scope for the same controls, and those controls are harder to evidence on a device you do not own. Decide up front whether personal devices are allowed at all, for which systems, and what the owner must attest. The generated Endpoint and Workstation Security Policy lets a personally owned device reach production only when it meets the company baseline and is either enrolled in your MDM or covered by a signed attestation. Ask your CPA firm early how it treats unmanaged devices.

What do auditors ask for when we have no MDM?

Expect questions about how you know each laptop is encrypted, locked and patched without a console to show it. The answer is a device inventory, a written baseline checklist filed for each device at issue, quarterly attestations with screenshots or command output, a review record, and offboarding records showing the device came back and was erased. Exactly what a firm samples varies, so the checklist on this page is a starting point to adjust after your first conversation with them.

Is having no MDM an exception in the SOC 2 report?

Not by itself. The auditor tests the controls you describe against what you actually do. If your policy promises central enforcement and you have none, that gap can show up as an exception. If your policy describes a manual baseline and attestation, and the records show you ran it, the control is described accurately. Writing the deviation down as an approved, time-limited exception with compensating controls, and keeping it current, is the safer record. How a firm words anything in its report is its decision.

What does the generator write if I leave the MDM field blank?

It switches the Endpoint and Workstation Security Policy, the Encryption policy and several others to a manual path: a written baseline checklist before a device is issued, a quarterly attestation with evidence, recovery keys held in an encrypted store the Security Owner controls, and a secure erase recorded at return. The table on this page is rendered from those templates. The Asset Management Policy also says adopting a device management platform is a tracked security objective, and the exception register seeds a draft exception from the same answer.

Which MDM should we buy?

Policyseed does not recommend a product, and the right one depends on your operating systems, whether devices are company-owned, and your budget. Compare them on what you need as evidence: a compliance report you can export, retained history of device status, coverage of every operating system you use, a way to lock and wipe a device remotely, and enrollment that can run before the first day of work. Ask each vendor to show the report you would hand an auditor.

Does a Type II report change the device evidence?

Yes, in volume. A Type I report looks at whether the controls are designed and in place on one date. A Type II report covers an observation period, so the device checks have to be repeated and recorded throughout it: every quarterly attestation, every new hire's baseline, every returned laptop. Manual evidence is workable over a short period for a small fleet, and it is where a console that reports automatically starts to save time.

Does SOC 2 require MDM? What auditors look for on laptops and phones

Updated 25 October 2026

No. SOC 2 does not name MDM as a requirement. The Trust Services Criteria expect endpoint controls (disk encryption, patching, screen lock, malware protection and a way to remove a device's access) and evidence that those controls operate. An MDM tool is one common way to get that evidence, because it reports the state of every device in one place. A small team can also meet the same criteria with a written baseline, a device inventory, dated attestations and a recorded plan, if the CPA firm accepts it. This guide shows the evidence, the no-MDM path, how personal devices fit and when buying a tool saves more time than it costs.

Short answer: the criteria describe outcomes, not products

A SOC 2 report is written by a CPA firm after it examines your controls against the Trust Services Criteria. The criteria say what has to be true, for example that you protect systems against unauthorized or malicious software, and leave the means to you. One BYOD guide (Agency) makes the same point, saying the framework "does not explicitly mention BYOD or MDM", while arguing that criteria such as CC6.1 and CC6.8 create device requirements in practice. Jamf, which sells MDM, presents its product as a way to support a remote workforce under SOC 2, not as something the framework demands. Both are vendor sources describing their own products, so read them as one side. The practical question is not "do we need the tool" but "how will we show an auditor that every device meets the baseline?"

The criteria device controls support

The generated Endpoint and Workstation Security Policy maps to three criteria, and the devices you manage come up under each:

CC6.6 covers security measures against threats from outside your system boundary. Laptops and phones that connect into your systems are part of that boundary.
CC6.7 covers restricting how information is transmitted, moved and removed, which is why disk encryption and limits on removable media appear in the policy.
CC6.8 covers preventing and detecting unauthorized or malicious software, which is where endpoint protection, patching and standard user accounts come in.

The device inventory and offboarding steps also feed the access criteria under CC6, since a returned laptop that is never erased is access that was never removed.

The evidence an auditor may ask for

What a firm samples varies, but the requests tend to cluster around the same five questions. Each can be answered from an MDM console or from records you keep yourself.

Disk encryption. Is FileVault, BitLocker or LUKS on, on every laptop? Evidence: a compliance report from a console, or a status screenshot or command output per device, and where the recovery keys are held.
Patching. Are updates applied within the time your policy sets? Evidence: operating system version per device at a point in time, and the update setting.
Screen lock. Do devices lock after the idle time the policy sets? Evidence: the setting, per device.
Endpoint protection. Is real-time malware protection on and the host firewall enabled? Evidence: the status screen or report per device.
Removing access. When someone leaves or a device is lost, can you cut it off and show it was done? Evidence: the offboarding checklist with the device return, the erase or wipe record, and the sessions revoked in your identity provider.

One BYOD guide lists the same families of evidence: a device inventory compared with the employee roster, encryption, screen lock timeout, update settings and remote wipe logs matched to offboarding dates (Agency). It assumes an MDM console produces them, which is the author's view, not a rule in the criteria.

What the generated policies say with and without MDM

The generator asks which device management tool you use, if any, and changes the wording of the Endpoint and Workstation Security Policy, the Encryption policy and the Asset Management Policy to match. The excerpts below are not written by hand. They are rendered from the policy templates for the Northwind Cloud Inc sample intake twice, once with an MDM named (shown here as a placeholder) and once with the field blank, so they change when a template does. In the no-MDM text the company name is the sample company's.

How the baseline is enforced (Endpoint and Workstation Security Policy, 4.3)

With an MDM named: Every company endpoint is enrolled in your MDM tool before it is issued, and enrollment may not be removed by the user. your MDM tool enforces the configuration in Sections 4.4 to 4.8 and reports compliance to the Security Owner.

With none named: Because Northwind Cloud Inc does not currently operate a mobile device management platform, every endpoint is configured against the written baseline checklist before issue, and each user attests quarterly that the configuration in Sections 4.4 to 4.8 remains in place, attaching system screenshots or reports as evidence.

Disk encryption and recovery keys (Endpoint and Workstation Security Policy, 4.4)

With an MDM named: Full-disk encryption (FileVault on macOS, BitLocker on Windows, LUKS on Linux and platform encryption on mobile devices) is enabled on every endpoint, with recovery keys escrowed in your MDM tool rather than held only by the user.

With none named: Full-disk encryption (FileVault on macOS, BitLocker on Windows, LUKS on Linux and platform encryption on mobile devices) is enabled on every endpoint, with recovery keys escrowed in an encrypted key store controlled by the Security Owner rather than held only by the user.

How compliance is verified (Endpoint and Workstation Security Policy, 5.3)

With an MDM named: Compliance verification. Each month the Security Owner reviews the your MDM tool compliance report, and any device out of compliance for more than seven days is blocked from company applications until remediated. Results are retained as evidence. Owner: Security Owner. Cadence: monthly.

With none named: Compliance verification. Each quarter every user completes the endpoint attestation form and attaches evidence of encryption status, operating system version and screen lock settings. The IT/Operations Lead reviews the responses within ten business days and follows up on any gap; access is suspended for anyone who has not attested within 30 days of the request. Results are retained as evidence. Owner: Security Owner. Cadence: quarterly.

Return and reassignment (Endpoint and Workstation Security Policy, 5.7)

With an MDM named: Return and reassignment. On offboarding or replacement, the user returns the device to the IT/Operations Lead, who confirms receipt on the offboarding checklist, triggers a wipe through your MDM tool, and updates the inventory. Devices are not reassigned until the wipe is recorded. Owner: IT/Operations Lead. Timing: within five business days of return.

With none named: Return and reassignment. On offboarding or replacement, the user returns the device to the IT/Operations Lead, who confirms receipt on the offboarding checklist, performs a secure erase and reinstall, and updates the inventory. Devices are not reassigned until the wipe is recorded. Owner: IT/Operations Lead. Timing: within five business days of return.

Encryption on laptops and phones (Encryption and Key Management Policy, 4.9)

With an MDM named: All laptops and mobile devices used for company work have full-disk encryption enabled, enforced and reported through your MDM tool. Approved removable media is encrypted with AES-256.

With none named: All laptops and mobile devices used for company work have full-disk encryption enabled. Approved removable media is encrypted with AES-256.

Encryption check without an MDM (Encryption and Key Management Policy, 5.7)

Endpoint verification. Each quarter every person attests that full-disk encryption is enabled on their devices; People Operations tracks completion and escalates non-compliance to the Security Owner within 7 days.

The pattern is the same in every case: where an MDM would enforce and report, the manual version asks for a checklist at issue and a dated attestation with evidence afterward. The Physical and Remote Work Security Policy and the Vulnerability and Patch Management Policy carry similar wording for lost equipment and monthly patch reviews.

Without MDM: manual evidence plus a dated plan

If you do not have a tool yet, do not describe one. Your policy should say what you actually do, then you do it and keep the records. A workable no-MDM set for a small fleet:

Device control	What you do without MDM	Evidence it leaves
Inventory	Keep one sheet with serial number, assigned user, operating system and issue date. Reconcile it with the HR roster each quarter.	The dated sheet and a signed reconciliation note.
Baseline at issue	Configure each device against a written checklist (encryption, screen lock, automatic updates, endpoint protection, firewall, standard user account) before handover.	The completed, dated checklist per device, filed with the inventory.
Disk encryption and recovery keys	Turn on FileVault, BitLocker or LUKS. Store recovery keys in an encrypted store the Security Owner controls, not only with the user.	A status screenshot or command output per device, and a record of where each key is held.
Screen lock and updates	Set the lock timeout and automatic updates at issue. Review vendor security bulletins on a fixed cadence and tell people when an update is due.	Settings screenshots, operating system version per device, and the bulletin review log.
Quarterly attestation	Each person confirms the baseline still holds and attaches fresh evidence. Someone other than the user reviews the answers and chases gaps.	The returned forms with attachments, the reviewer's sign-off, and follow-up on any gap.
Offboarding and return	Collect the device, erase and reinstall it by hand, and revoke the user's sessions in your identity provider.	The offboarding checklist with the erase method, date and serial number, and the updated inventory.
Lost or stolen device	Report it at once, revoke sessions, rotate credentials the device held and open an incident record.	The incident record with timestamps and the credential rotation notes.

The onboarding and offboarding checklist has the device steps; with no MDM named, its device rows become this manual check and the recorded erase. To see where devices sit among your other gaps, run the free readiness assessment, which asks whether you can prove encryption, screen lock and updates across the fleet.

Record the gap as an approved exception

The manual path is the control. The missing tool is a deviation from the ideal, so write it down. An exception names the requirement, the reason, the compensating controls above, who approved it, and an expiry date. The generated policies say exceptions are approved in writing, recorded in a register and kept to no more than 12 months. Your Asset Management Policy goes further when no tool is named:

Production, source code and customer data are accessed only from devices in the register that meet the security baseline. Until a device management platform is adopted, the IT/Operations Lead verifies the baseline at issue and at each quarterly reconciliation, and adopting one is a tracked security objective.

The free policy exception register seeds a draft "no device management platform" exception from the same generator answer, quoting the policy sentence it comes from and leaving placeholders for the reason and the target date. Fill in the facts only you know, get it approved, and review it before it expires. The Audit Kit ($59, one time) includes the register and request form in its governance folder.

Personal devices (BYOD)

Personal devices are in scope as soon as they read company email or reach company data. The generated policy lets a personally owned device reach production only with Security Owner approval and only if it meets the same standard as a company device, enrolled in the MDM where there is one or covered by a signed attestation where there is not. Practical choices, from strictest to loosest:

Company devices only for production, source code and customer data. This is the easiest to evidence and the cheapest to explain to an auditor.
Personal devices for email and chat only, with approval, a passcode and encryption attested, and no local copies of customer data.
Managed personal devices, which means enrolling a phone or laptop the employee owns. This raises privacy questions, so scope what the tool can see and wipe, and say so in writing.

A written BYOD rule with no way to check it is documentation rather than a control, as the Agency guide argues, and an auditor can test it by asking you to show the evidence. Venn, a vendor in this space, says controls can be applied to a protected workspace on the device so full management is not needed (Venn). That is the vendor's claim and it does not cite a criterion for it. Whichever route you take, confirm with your CPA firm that it will accept it.

When buying MDM saves more time than it costs

Manual evidence works for a handful of company laptops. It gets expensive in the ways below, and any of them is a reason to look at a tool:

You are heading into a Type II observation period and every quarterly attestation has to be collected and reviewed on time.
The fleet is remote or hybrid, so nobody can check a device in person, and new hires are shipped laptops.
Customers or their questionnaires ask for fleet-wide encryption and patch reports you cannot produce in an afternoon.
Offboarding means chasing laptops and you want a remote lock and wipe for the ones that do not come back.
You allow personal devices and need to separate company data from personal data.
The person collecting attestations is spending a visible share of their week on it.

When you do compare tools, judge them on the report you would hand an auditor: can it be exported, does it keep history, does it cover every operating system you use, can it lock and wipe a device remotely, and can enrollment happen before the first day. Policyseed does not recommend a product. Once you have one, type its name into the generator and the policies switch to the enforced wording above, and your endpoint policy and your records should match what the tool actually does.

To practice the question before a CPA firm asks it, the Audit Kit's mock audit flags a missing device management tool as a likely line of questioning and checks your answers against your own policies. It uses runs from an Audit Kit key ($59) and is practice, not an audit.

Frequently asked questions

Does SOC 2 require MDM?: No. The Trust Services Criteria do not name MDM or any other product. They describe outcomes, such as protecting systems from unauthorized or malicious software and restricting how data leaves your control, and the auditor tests whether your own controls achieve them. For laptops and phones that usually means encryption, screen lock, patching, endpoint protection and a way to cut off a lost or returned device, each with evidence that it operated. An MDM tool is one common way to produce that evidence. A written baseline checklist plus dated attestations is another, and the CPA firm decides whether it is enough for your system.
Can we use personal laptops and phones (BYOD) for SOC 2?: The criteria do not forbid it, but every personal device that reaches company data is in scope for the same controls, and those controls are harder to evidence on a device you do not own. Decide up front whether personal devices are allowed at all, for which systems, and what the owner must attest. The generated Endpoint and Workstation Security Policy lets a personally owned device reach production only when it meets the company baseline and is either enrolled in your MDM or covered by a signed attestation. Ask your CPA firm early how it treats unmanaged devices.
What do auditors ask for when we have no MDM?: Expect questions about how you know each laptop is encrypted, locked and patched without a console to show it. The answer is a device inventory, a written baseline checklist filed for each device at issue, quarterly attestations with screenshots or command output, a review record, and offboarding records showing the device came back and was erased. Exactly what a firm samples varies, so the checklist on this page is a starting point to adjust after your first conversation with them.
Is having no MDM an exception in the SOC 2 report?: Not by itself. The auditor tests the controls you describe against what you actually do. If your policy promises central enforcement and you have none, that gap can show up as an exception. If your policy describes a manual baseline and attestation, and the records show you ran it, the control is described accurately. Writing the deviation down as an approved, time-limited exception with compensating controls, and keeping it current, is the safer record. How a firm words anything in its report is its decision.
What does the generator write if I leave the MDM field blank?: It switches the Endpoint and Workstation Security Policy, the Encryption policy and several others to a manual path: a written baseline checklist before a device is issued, a quarterly attestation with evidence, recovery keys held in an encrypted store the Security Owner controls, and a secure erase recorded at return. The table on this page is rendered from those templates. The Asset Management Policy also says adopting a device management platform is a tracked security objective, and the exception register seeds a draft exception from the same answer.
Which MDM should we buy?: Policyseed does not recommend a product, and the right one depends on your operating systems, whether devices are company-owned, and your budget. Compare them on what you need as evidence: a compliance report you can export, retained history of device status, coverage of every operating system you use, a way to lock and wipe a device remotely, and enrollment that can run before the first day of work. Ask each vendor to show the report you would hand an auditor.
Does a Type II report change the device evidence?: Yes, in volume. A Type I report looks at whether the controls are designed and in place on one date. A Type II report covers an observation period, so the device checks have to be repeated and recorded throughout it: every quarterly attestation, every new hire's baseline, every returned laptop. Manual evidence is workable over a short period for a small fleet, and it is where a console that reports automatically starts to save time.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.