The auditor doesn't ask whether you take device security seriously. They ask you to prove it. "Show me that every laptop with patient data is encrypted." "Show me the wipe was completed on the device that left in March." "Show me your asset inventory as of last quarter." And in that moment, a 12-page MDM policy is worth nothing if you can't produce a report with a timestamp next to it.
That's the gap most teams hit with MDM compliance. The policy exists. The MDM is deployed. But when someone asks for proof, the answer is a scramble of screenshots and "we're pretty sure." Compliance frameworks were written for that exact moment, and they all converge on the same demand: not "do you have a control," but "can you prove it worked."
This guide maps the device-level requirements of HIPAA, GDPR, SOC 2, ISO 27001, PCI DSS, and FERPA to the specific MDM controls that satisfy them, and to the evidence each one produces. The goal isn't to make you a compliance lawyer. It's to make the audit boring.
What MDM compliance actually means
MDM compliance is the practice of using mobile device management to enforce, and document, the security controls that regulations require on endpoints. One quick disambiguation: here "MDM" is mobile device management (laptops, phones, tablets), not master data management. Different field, same acronym.
The "compliance" half is where teams underweight the work. Most read it as "configure the right policies." But a framework doesn't audit your configuration screen. It audits your ability to demonstrate that the control was in place, on the right devices, at the right time. MDM compliance is the bridge between a written policy and an auditable record.
That distinction changes what you build toward. You're not just turning on encryption. You're making sure that, six months later, you can pull a report proving encryption was on across the fleet, with device IDs and dates attached. The control and the evidence are two separate deliverables, and the second one is what fails audits.
Quick wins:
- For each control you already enforce, ask "could I export proof of this in five minutes?" The no's are your real gaps.
- Separate "configured" from "verifiable" in your own head. They're not the same compliance posture.
Which regulations actually govern your devices?
Not every framework applies to every organization, but the major ones all reach the endpoint. The trick is knowing which device-level requirement each one cares about, because they overlap heavily:
- HIPAA: healthcare. Protect electronic patient data on every device that touches it.
- GDPR: anyone handling EU personal data. Appropriate security measures, plus the ability to erase data.
- SOC 2: SaaS and service providers. Demonstrable access and security controls.
- ISO 27001: international security standard. Asset management and endpoint controls.
- PCI DSS: anyone handling cardholder data. Protect that data wherever it lives, endpoints included.
- FERPA: education. Protect student records on school-managed devices.
The good news for a lean team: you're rarely solving six puzzles. The device controls that satisfy HIPAA also do most of the work for GDPR, SOC 2, and ISO 27001. Encryption, access control, remote wipe, and a current asset inventory are the shared foundation. Build those well, with evidence, and you're most of the way to whichever framework binds you.
Quick wins:
- Identify your one binding framework first. Build for it, then map the overlap to the rest.
- Don't duplicate controls per framework. Map controls to requirements, not the other way around.
Framework by framework: control and evidence
Here's the part that's usually missing. For each framework, the device-level requirement maps to an MDM control, and that control produces a specific piece of evidence. The evidence is the part auditors actually ask for, so each one below pairs the control with the record it generates.
HIPAA
HIPAA's Security Rule expects encryption of patient data, access controls, and the ability to render data unusable on a lost device. In MDM terms: enforce disk encryption, confirm it's actually on, and keep remote wipe ready. The evidence that matters is a fleet-wide encryption report and, when a device goes missing, a documented wipe with a timestamp, not a memory of having done it. For the full healthcare picture, see how MDM supports HIPAA compliance.
GDPR
GDPR's Article 32 asks for "appropriate technical measures," and Article 17 gives data subjects a right to erasure. Encryption covers the first; remote wipe covers the second. The evidence is a deletion log you can point to when a regulator asks you to demonstrate that personal data on a device was actually removed.
SOC 2
SOC 2 is less prescriptive and more about proving your stated controls operate over time. Whatever you claim (managed devices, enforced encryption, access restrictions), you have to show it held continuously. That makes audit logging and a consistent device inventory the backbone. The auditor wants the trail, with dates.
ISO 27001
ISO 27001 leans hard on asset management: you can't protect what you haven't inventoried. The device control is a live hardware and software inventory tied to ownership, plus a baseline enforced across endpoints. The evidence is that inventory, current and timestamped, not a spreadsheet last touched a year ago.
PCI DSS
PCI DSS requires protecting cardholder data wherever it lives, and endpoints handling that data are in scope. Encryption and access control are the device-level core, and the evidence is a per-device compliance status you can produce for the assessor.
FERPA
For schools, FERPA protects student education records, including on the laptops and tablets in a 1:1 program. Tracking, remote lock, and wipe are the controls; the evidence is a per-device action and location history when a device is lost or a record might be exposed.
Quick wins:
- Build the evidence once. The same encryption report serves HIPAA, PCI, and ISO at the same time.
- For your binding framework, write the literal auditor question next to each control. If you can't answer it with an export, that's the work.
Building an MDM compliance policy that holds
A policy is only as good as your ability to enforce and prove it. Keep it tight and tied to controls you can actually evidence:
- Scope it to data, not devices. Define which devices touch regulated data, and apply the strictest controls there first.
- Write controls as enforceable settings. "Devices must be encrypted" becomes an enforced encryption policy with a status report, not a sentence in a PDF.
- Set the evidence cadence. Decide how often you pull encryption, inventory, and access reports, so the audit is a download, not a project.
- Wire it into onboarding and offboarding. Enrollment and policy on day one; lock and wipe as a closing step when someone leaves, with the action logged.
For the deeper mechanics of writing and evolving these rules, see how to build and enforce MDM policies that actually work.
Quick wins:
- Turn one policy line into an exportable report this week. Prove the model works before scaling it.
- Tie the policy to your device lifecycle, so compliance is enforced from deployment to decommission.
How do you prove MDM compliance to an auditor?
This is where most articles stop and most audits get tense. Configuration is invisible to an auditor. What they evaluate is evidence, and good device-level evidence has four parts:
- What: the control state (encryption on, device enrolled, access restricted).
- Which device: a device ID, not "the fleet" in the abstract.
- When: a timestamp, so the control is provably in place during the audit period.
- Who: the admin or system that enforced or executed the action.
A wipe command without those four is a story. A wipe record with them is evidence. The practical test for any MDM compliance setup is simple: pick a control, imagine the auditor asking for proof, and see whether you can produce a report that answers all four. The ones where you can't are your audit risk, regardless of how the policy reads. This is the heart of evidence-based compliance, and it's where device management earns its place in your control set, through compliance enforcement you can actually demonstrate.
Scenario: the SOC 2 encryption ask. Eight months after a device was deployed, an auditor asks your IT lead to prove it was encrypted throughout the period. Without MDM, that's a reconstruction job. With it, it's an encryption-status report filtered to that device, with dates. The control was the easy part. The evidence is what passed the audit.
Scenario: HIPAA and the lost laptop. A laptop with patient data goes missing. The breach question isn't only "did you wipe it," it's "can you prove the wipe completed, and when." A documented remote wipe with a timestamp turns a potential notification scramble into a closed, evidenced incident. Treat it as completing the offboarding of that device, not a fire drill.
Scenario: the ISO 27001 inventory check. During a surveillance audit, the assessor pulls three serial numbers at random and asks you to confirm they're tracked, assigned, and current. A live hardware and software inventory answers in one export; a stale spreadsheet turns it into a week of reconciliation. The control is the inventory. The evidence is that it's current, with dates and ownership.
Quick wins:
- Run the four-part test (what, which, when, who) against your top three controls this week. Anything that fails it is audit risk.
- Pre-build your audit exports while it's calm, so the request is a download, not a scramble.
How device management produces compliance evidence
Most of this article is vendor-neutral on purpose, because the controls matter more than the logo. But it's worth showing what "evidence-producing MDM" looks like in practice, because that's the lane Prey is built for.
Prey gives a lean IT or security team the device-level controls and the records that frameworks ask for, from one dashboard and across every major OS: Windows, macOS, Linux, Android, iOS, and Chromebook. Encryption management confirms BitLocker and FileVault are actually on and reports it. A live hardware and software inventory covers the asset-management requirement in ISO 27001. Remote wipe and remote lock produce the documented actions HIPAA and GDPR want when a device is lost. And always-on location plus an audit trail give you the per-device history that turns "we handled it" into "here's the record, with timestamps."
Two honest edges. Prey is a device security and management platform, not a full GRC or compliance-automation suite. It produces the device-layer evidence; your framework mapping and reporting live above it. And like any agent-based tool, it can't report on a device that's been fully wiped and reinstalled, which is exactly why fast action and logged evidence matter more than assuming persistence. For most teams, that trade is the right one: the device controls and the proof of them, without an enterprise GRC budget.
Quick wins:
- List the three reports you'd reach for in an audit (encryption, inventory, wipe history). Confirm your tool can export all three.
- If a control can't produce evidence, it isn't a compliance control yet. It's a setting.
Make the audit boring
MDM compliance comes down to one shift in thinking. The frameworks aren't grading your intentions or your policy document. They're asking whether you can prove a control was in place, on a specific device, at a specific time. Get the controls right (encryption, access, remote wipe, inventory), then make sure each one produces evidence you can export on demand. Do that, and the audit stops being an event and becomes a download.
Start with your one binding framework, list its device-level requirements, and mark which you can prove today versus which you can only claim. The gap between those two columns is your real compliance work.
Want device controls that produce the evidence auditors ask for? Start a free trial and see your fleet's compliance posture (encryption, inventory, and action history) from one dashboard.
Frequently asked questions about MDM compliance
What is MDM compliance?
MDM compliance is using mobile device management to enforce and document the security controls that regulations require on endpoints, like encryption, access control, remote wipe, and asset inventory, and being able to prove those controls were in place when an auditor asks.
Which regulations require mobile device management?
No regulation names "MDM" specifically, but HIPAA, GDPR, SOC 2, ISO 27001, PCI DSS, and FERPA all impose device-level requirements (encryption, access control, data erasure, asset inventory) that MDM is the practical way to enforce and evidence.
How does MDM help with HIPAA and SOC 2 compliance?
For HIPAA, MDM enforces encryption of patient data and enables documented remote wipe of lost devices. For SOC 2, it provides the audit trail and consistent device inventory needed to show your stated controls operated over time. In both cases, the value is the exportable evidence, not just the configuration.
What evidence do auditors expect for device compliance?
Records that answer four things: what the control state was, which device (by ID), when (a timestamp covering the audit period), and who enforced or executed it. An encryption-status report or a wipe confirmation with those details is evidence; a policy document alone is not.
What are the 4 types of MDM?
This usually refers to device enrollment and ownership models, commonly BYOD, COPE (corporate-owned, personally enabled), COBO (corporate-owned, business only), and CYOD (choose your own device). Each affects how much you can enforce and evidence on a device, which is why ownership model and compliance scope are linked.
