Mobile Device Management Policy Template — What to Include and How to Write One

A mobile device management policy defines the rules, expectations, and procedures for every device your organization manages — who owns it, how it is enrolled, what is allowed, what is monitored, and what happens when something goes wrong. The policy is not the MDM console configuration. It is the human-readable document that explains what the configuration enforces and why.

This post covers the 10 sections every MDM policy should include, with template language you can copy and customize for your organization. Each section includes what to write, why it matters, and which compliance frameworks require it. Bracketed placeholders — like [COMPANY], [X DAYS], and [IT CONTACT] — indicate values you need to replace with your own.

What Is an MDM Policy and Why Does Your Organization Need One?

An MDM policy is the organizational document that governs how mobile devices are used, managed, and secured. It serves three audiences: employees (what is expected of them), IT (what they are responsible for), and auditors (evidence that controls exist and are communicated).

Without a written policy, MDM enforcement feels arbitrary. A passcode requirement without an explanation generates helpdesk calls. A restricted website without a documented rationale generates complaints. A remote wipe on a lost device without a defined threshold generates lawsuits. The policy prevents surprises, and surprises are what drive resistance.

MDM best practices recommend defining the device policy before choosing MDM software. The MDM implementation guide positions the policy document as the first deliverable in Stage 1. This template gives you the document for both posts.

10 Sections Every Mobile Device Management Policy Should Include

1. Purpose and Scope

“This policy defines the rules for managing mobile devices — smartphones, tablets, laptops, and ruggedized endpoints — owned by [COMPANY] or used by [COMPANY] employees, contractors, and third parties for work purposes. It applies to all individuals who access [COMPANY] resources from a mobile device, regardless of device ownership.”

Scoping prevents ambiguity. If the policy does not explicitly name contractors and third parties, those groups will assume it does not apply to them. If it does not name laptops alongside smartphones, the IT team will face questions about whether laptops are covered. Name every device type and every user group in the scope statement.

2. Device Ownership Models

Your policy should define which ownership models the organization supports and what each model means for the employee. Include only the models your organization actually uses.

BYOD template language: 

“Employees may use personal devices for work purposes. [COMPANY] will manage only corporate data and applications on the device through a work profile or managed app container. [COMPANY] does not access, view, or collect personal apps, photos, browsing history, or messages on BYOD devices.”

COPE template language: 

“Devices purchased by [COMPANY] remain company property. Employees may use COPE devices for personal purposes in accordance with the Acceptable Use section below. [COMPANY] retains full management control of the device, including the ability to remotely configure, update, lock, or wipe it.”

CYOD template language: 

“Employees select a device from [COMPANY]’s approved device catalog. [COMPANY] purchases, owns, and manages the device. Employees may use the device for personal purposes within the guidelines defined in this policy.”

3. Acceptable Use Rules

“Employees using managed devices must adhere to the following acceptable use standards:

• Personal applications may be installed on COPE and CYOD devices provided they do not conflict with security policies or consume excessive storage.

• Jailbreaking, rooting, or circumventing any security control on a managed device is prohibited and will result in immediate device quarantine.

• Connecting managed devices to unsecured public Wi-Fi networks without an active VPN connection is prohibited.

• Storing classified, confidential, or regulated data (PHI, CJI, PCI data) locally on a device is prohibited unless full-disk encryption is verified and the device is enrolled in [COMPANY]’s MDM platform.

• Sharing device unlock credentials (PIN, password, biometric enrollment) with any other person is prohibited.

• Installing applications from sources outside the official app store or [COMPANY]’s Enterprise App Store is prohibited.”

Acceptable use rules set boundaries. Without them, employees make reasonable assumptions that may conflict with organizational security requirements. A rule that exists in the MDM console but not in the written policy is unenforceable from a human resources perspective.

4. Enrollment Requirements

“All devices accessing [COMPANY] resources must be enrolled in [COMPANY]’s MDM platform. Enrollment must be completed within [X] business days of device assignment or employment start date.

• Corporate-owned devices (COPE/CYOD): enrolled automatically via zero-touch enrollment (Apple ADE, Windows Autopilot, Android Zero-Touch). No manual configuration required.

• Employee-owned devices (BYOD): enrolled via QR code or enrollment link provided by IT. A work profile will be installed to separate corporate and personal data.

Devices that are not enrolled in [COMPANY]’s MDM platform cannot access corporate email, applications, file shares, or network resources. Refusal to enroll a personal device is the employee’s right — but unenrolled devices will not have access to [COMPANY] systems.”

Enrollment is the point of entry for MDM. The policy must state what happens if enrollment is refused — not as a threat, but as a factual consequence. Employees who understand that unenrolled devices simply cannot access corporate resources make informed decisions about whether to enroll.

5. Security Requirements

“All enrolled devices must meet the following security requirements at all times:

• Passcode: minimum [X] characters, alphanumeric, no sequential or repeated patterns. The passcode must be changed every [X] days. Device locks after [X] failed attempts.

• Encryption: full-disk encryption must be enabled on all enrolled devices. Devices that do not support encryption cannot be enrolled.

• VPN: access to [COMPANY]’s internal network requires an active VPN connection. VPN profiles are pushed automatically by the MDM platform.

• OS updates: devices must run a supported operating system version. Updates must be installed within [X] days of release. Devices running unsupported OS versions will be quarantined until updated.

• Screen lock: devices automatically lock after [X] minutes of inactivity.

• Biometric authentication: fingerprint or face recognition is [required / recommended / optional] for device unlock.”

Security requirements are the most heavily audited section of any device policy. HIPAA requires encryption at rest and access controls. CJIS requires advanced authentication and encryption in transit. NIST SP 800-124 provides mobile device security baselines. PCI-DSS requires encryption and access controls for devices handling payment data. Reference the applicable framework in your policy.

6. Application Management

“[COMPANY] may install, update, configure, or remove corporate applications on enrolled devices without prior notice. Employees access approved applications through the Enterprise App Store.

On BYOD devices, corporate applications operate within a managed container. Data cannot be copied, shared, or transferred from corporate applications to personal applications.

Installation of applications from sources outside the official platform app store or [COMPANY]’s Enterprise App Store is [permitted on personal devices only / prohibited on all managed devices].”

Application management rules define the boundary between IT-controlled and user-controlled software. For BYOD devices, the data separation statement is critical — it is the contractual basis for preventing corporate data from leaking into personal apps. For COPE devices, the silent install clause means IT can push critical updates without waiting for user approval.

7. Monitoring and Privacy

“[COMPANY] monitors the following on enrolled devices: compliance status (passcode, encryption, OS version), installed corporate application inventory, device health (battery, storage, last check-in), and device location (for corporate-owned devices and when required by compliance).

On BYOD devices with work profiles, [COMPANY] can see only corporate application activity and compliance status within the managed container. [COMPANY] cannot and does not see personal applications, personal photos, personal browsing history, personal email, text messages, or call logs.

[COMPANY] does not use MDM to monitor employee productivity, track personal movements outside work hours, or access any personal content on BYOD devices.”

This section assesses employees’ trust in the MDM program. Vague language (“IT may monitor device activity”) creates fear. Specific language (“IT cannot see personal apps, photos, or messages on BYOD devices”) builds trust. Be explicit about what IT can see, what IT cannot see, and what IT will never do. Employees who trust the privacy boundary enroll willingly. Those who do not trust it resist, unenroll, or avoid using their devices for work.

8. Lost, Stolen, or Compromised Device Procedures

“Employees must report a lost, stolen, or suspected-compromised device to [IT CONTACT / HELPDESK EMAIL / PHONE] within [X] hours of discovery.

Upon receiving a report, IT will:

• Immediately remotely lock the device

• Attempt to locate the device using GPS tracking (corporate-owned devices only)

• If the device is not recovered within [X] hours: perform a remote wipe

    – Corporate-owned devices: full factory reset

    – BYOD devices: selective wipe (corporate data and work profile only; personal data is not affected)

• Notify the employee’s manager and [SECURITY TEAM / COMPLIANCE OFFICER]

If a device is confirmed stolen or confirmed compromised by malware, IT will perform a remote wipe immediately, regardless of recovery timeline.”

The lost/stolen procedure must define thresholds — how many hours before lock, how many before wipe, and the difference between “lost” (might be found) and “stolen” (wipe immediately). Without thresholds, a panicked admin wipes a device from the employee’s other bag. With thresholds, the response is measured and documented.

9. Offboarding and Device Return

“When employment or contract engagement ends, the following applies:

• Corporate-owned devices (COPE/CYOD): the employee must return the device to [IT DEPARTMENT / MANAGER] on or before their last day. IT will perform a full factory reset and re-provision the device for the next user.

• Employee-owned devices (BYOD): IT will remove the work profile and all corporate data via selective wipe on the employee’s last day. Personal data, personal applications, and personal accounts are not affected.

Failure to return corporate-owned devices will be treated as [loss of company property / payroll deduction per company asset policy / reported to legal].

Corporate email, VPN access, and Enterprise App Store access will be revoked on the employee’s last day, regardless of device ownership model.”

Offboarding is where data leaks happen. If the policy does not define what happens to the device when the employee leaves, corporate data is left behind. The selective wipe clause for BYOD is especially important — employees need to know that offboarding removes only corporate data, not their personal photos and messages. This assurance reduces resistance to BYOD enrollment in the first place.

10. Policy Review and Updates

“This policy will be reviewed and updated [quarterly / semi-annually / annually] by [IT DEPARTMENT / SECURITY TEAM / POLICY OWNER]. Reviews will evaluate whether policy requirements remain aligned with current compliance frameworks, operating system capabilities, fleet composition, and organizational needs.

Revisions will be communicated to all employees via [email / intranet / onboarding system]. Employees are required to acknowledge receipt and understanding of updated policies within [X] business days of publication.”

A policy that is never reviewed becomes obsolete. OS versions change. Compliance frameworks update. The fleet grows from 200 devices to 2,000. Quarterly reviews catch drift before it creates gaps. MDM best practices recommend a quarterly cadence as the minimum.

How to Customize This Template for Your Organization

Replace all [BRACKETED] placeholders with your organization’s specific values: company name, passcode length, update deadlines, inactivity timeout, contact information, recovery timelines, and ownership models. Every placeholder represents a decision your organization needs to make before the policy is distributed.

Remove sections that do not apply. If your organization does not support BYOD, remove the BYOD paragraphs from Section 2 and the BYOD-specific privacy language from Section 7. If you do not manage kiosks or shared devices, remove those references. A shorter policy that covers your actual use cases is more effective than a comprehensive policy that covers scenarios you will never encounter.

Add compliance-specific language. If your organization is subject to HIPAA, add PHI handling rules to Section 5 (encryption requirements for devices storing PHI) and Section 6 (app-level DLP for healthcare applications). If you are subject to CJIS, add CJI access controls and audit requirements. The template provides the structure. Your compliance framework provides the specifics.

Bento MDM’s compliance templates for CIS, NIST, and CJIS map directly to the security requirements in Section 5. The MDM console enforces what the policy document describes — so the written policy and the technical configuration stay aligned.

Compliance Mapping — Which Sections Are Required by Which Frameworks?

The table below maps each policy section to four major compliance frameworks. “Required” means the framework explicitly mandates that topic in the device management policy. “Recommended” means the framework addresses the topic but does not mandate a specific policy section for it.

Policy Section	HIPAA	CJIS	NIST 800-124	PCI-DSS
1. Purpose and Scope	Required	Required	Recommended	Required
2. Device Ownership Models	Recommended	Required	Recommended	Recommended
3. Acceptable Use	Recommended	Required	Recommended	Recommended
4. Enrollment Requirements	Required	Required	Required	Required
5. Security Requirements	Required	Required	Required	Required
6. Application Management	Required	Recommended	Required	Required
7. Monitoring and Privacy	Required	Required	Required	Recommended
8. Lost/Stolen Procedures	Required	Required	Required	Required
9. Offboarding	Required	Required	Recommended	Required
10. Policy Review	Required	Required	Recommended	Recommended

If your organization is subject to multiple frameworks, start with the sections marked “Required” across all applicable columns. Those sections form the non-negotiable baseline of your policy. Add “Recommended” sections based on your risk assessment and organizational needs.

Frequently Asked Questions

What should a mobile device management policy include?

An MDM policy should include 10 sections: purpose and scope, device ownership models (BYOD, COPE, CYOD), acceptable use rules, enrollment requirements, security requirements (passcodes, encryption, VPN, OS updates), application management, monitoring and privacy disclosures, lost/stolen/compromised device procedures, offboarding and device return, and policy review cadence. Each section addresses a specific governance need — from defining who the policy covers to documenting what happens when an employee leaves.

Do I need separate policies for BYOD and corporate-owned devices?

You do not need separate documents; you just need separate language within the same policy. Sections 2 (ownership models), 4 (enrollment requirements), 7 (monitoring and privacy), 8 (wipe procedures), and 9 (offboarding) all require different language for BYOD versus corporate-owned devices. The template above provides separate paragraphs for each ownership model within the relevant sections. One policy document with ownership-specific clauses is cleaner and easier to maintain than multiple parallel policies.

How long should an MDM policy be?

Most effective MDM policies are 3 to 5 pages in a standard Word document format. The goal is completeness without verbosity — every sentence should either define a rule, explain a procedure, or set an expectation. Remove marketing language, remove redundant explanations, and remove sections that do not apply to your organization. A policy that employees actually read is more valuable than a comprehensive one they ignore.

Who should approve the MDM policy?

The MDM policy should be reviewed by IT (technical accuracy), legal (compliance and liability), HR (employee relations and enforcement), and executive leadership (organizational authority). Final approval typically sits with the CIO, CISO, or VP of IT. The approving executive’s name and signature on the document signal organizational commitment, which matters when auditors review the policy during compliance assessments. Bento MDM’s onboarding team reviews customer policies during deployment to ensure the console configuration aligns with the documented policy.

How often should the policy be reviewed?

Quarterly at a minimum. Review the policy whenever a major change occurs: a new OS release that affects security controls, a compliance framework update, a significant fleet expansion, a shift in ownership models (adding BYOD to a previously corporate-only fleet), or a security incident that exposes a policy gap. Each review should produce a documented revision with a changelog and employee acknowledgment requirement.