Photo by MDM security policies every growing company needs
MDM security policies translate board-level risk appetite into device settings your fleet actually runs—not PDF requirements that IT interprets differently each quarter. Growing companies typically need five foundational policies aligned with what SecureSlate Asset Management monitors: HD Encryption, Anti-Virus, Password Policy, Screen Policy, and Firewall.
These five policies form the endpoint baseline for most SOC 2, ISO 27001, and enterprise security reviews. MDM enforces them; SecureSlate proves they operate continuously across your observation window.
This guide covers:
- How written policy connects to MDM configuration profiles
- Recommended policy language for each of the five checks
- A policy pack summary table for quick reference
- Rollout workflow from draft to audit-ready enforcement
- Evidence and review cadence GRC teams need
GIF via GIPHY
Related guides:
- MDM for compliance
- What is MDM? Basic endpoint security
- Endpoint security checks explained
- Common MDM security check failures and fixes
- Screen lock policy best practices
Key takeaways
- Five MDM security policies cover the baseline most frameworks expect: encryption, AV, password, screen lock, firewall.
- Policy and MDM profile must match—auditors compare written standard to sampled device configuration.
- Growing companies should adopt these before Type II observation, not during pre-audit scramble.
- SecureSlate Asset Management maps each policy to pass/fail checks and stores approval + evidence.
- Annual review with IT sign-off keeps policies current as OS and threat landscape evolves.
Policy vs MDM enforcement
A common audit finding: policy says one thing, MDM enforces another. Avoid the gap with a clear chain:
| Layer | Purpose | Owner |
|---|---|---|
| Policy document | Management-approved requirements | GRC + Legal |
| Standard / procedure | Technical implementation details | IT Security |
| MDM configuration profile | Enforced settings on device | IT Endpoint |
| Compliance monitoring | Pass/fail verification | SecureSlate + IT |
| Remediation procedure | Non-compliance response | IT + GRC |
Written policy alone does not prove operating effectiveness. Auditors triangulate: approved policy version, MDM profile export, sample device state, and remediation records when failures occur.
If your policy requires 15-minute screen lock but MDM allows 60 minutes, fix the MDM profile—not the auditor's interpretation.
HD Encryption policy
Policy intent
All corporate-owned and in-scope BYOD endpoints must encrypt data at rest using platform-native full-disk encryption (BitLocker on Windows, FileVault on macOS).
Recommended requirements
- Encryption enabled before device accesses production data
- Recovery keys escrowed in MDM (not stored by end users alone)
- Encryption cannot be disabled without IT approval
- Lost or stolen devices reported immediately; remote wipe initiated
MDM enforcement
| Setting | Windows (BitLocker) | macOS (FileVault) |
|---|---|---|
| Require encryption | Yes | Yes |
| Escrow recovery key | Azure AD / MDM | MDM escrow |
| Block access if off | Conditional access | Conditional access |
| Compliance rule | Encrypted = compliant | FileVault on = compliant |
Align with hard drive encryption compliance for technical depth.
Anti-Virus policy
Policy intent
All in-scope endpoints run organization-approved anti-malware with real-time protection and automatic definition updates.
Recommended requirements
- Approved product list maintained by IT Security (no consumer trials)
- Real-time scanning enabled; users cannot disable protection
- Definitions updated at least daily when device is online
- Malware detections reported per incident response procedure
MDM enforcement
| Setting | Requirement |
|---|---|
| Required AV product | Deploy via MDM or verify installed |
| Real-time protection | Must be on |
| Definition age | Fail if >7 days stale (stricter teams use 3 days) |
| Unapproved AV | Block or alert |
MDM verifies presence and state—it does not replace enterprise AV licensing and incident response.
Password Policy
Policy intent
Device login credentials meet minimum strength requirements and are not shared across users or systems.
Recommended requirements
- Minimum 12 characters (or passphrases per NIST-aligned guidance)
- Complexity enabled unless passphrase-only standard adopted
- No password reuse across corporate and personal accounts (user guidance)
- Local accounts discouraged; prefer directory-authenticated login
MDM enforcement
| Setting | Typical value |
|---|---|
| Minimum length | 12+ characters |
| Complexity | Enabled (or passphrase minimum 15 chars) |
| Maximum age | 90 days or no rotation with MFA (document choice) |
| Failed attempts | Lockout after 10 attempts |
Ensure MDM password payload matches written policy—see ISO 27001 password policy for policy structure examples.
Screen Policy
Policy intent
Devices lock automatically after inactivity and require authentication to resume—protecting unattended endpoints in open offices, co-working spaces, and travel.
Recommended requirements
- Maximum inactivity before lock: 15 minutes (many SOC 2 programs use 5–15)
- Password, PIN, or biometric required to unlock
- No "never lock" configuration without CISO-approved exception
- Clear screen / visible display policies for sensitive environments optional
MDM enforcement
| Setting | Typical value |
|---|---|
| Idle timeout | ≤15 minutes |
| Password on wake | Immediately |
| Screensaver | Required with lock |
See screen lock policy best practices for rollout tips and exception handling.
Firewall policy
Policy intent
Host-based firewall enabled on all endpoints for all network profiles—domain, private, and public (Windows) or equivalent (macOS).
Recommended requirements
- OS firewall enabled; users cannot disable without approval
- Inbound connections restricted to approved use cases
- Developer or lab exceptions use segmented networks—not disabled firewall on production devices
- Periodic verification via MDM compliance rules
MDM enforcement
| Setting | Windows | macOS |
|---|---|---|
| Firewall state | On all profiles | Enabled |
| Inbound default | Block unless rule | Block unless rule |
| Compliance rule | All profiles on | Firewall enabled |
When firewall check failures appear, they often trace to developer local testing—address with network segmentation, not policy exceptions on corporate laptops.
Policy pack summary
Use this table as a one-page reference when drafting or reviewing your endpoint security policy suite:
| Policy | Minimum standard | MDM check | SOC 2 / ISO theme |
|---|---|---|---|
| HD Encryption | BitLocker / FileVault on; keys escrowed | HD Encryption | CC.6.7 / A.8.24 |
| Anti-Virus | Approved AV; real-time on; defs current | Anti-Virus | CC.6.8 / A.8.7 |
| Password Policy | ≥12 chars; complexity or passphrase | Password Policy | CC.6.1 / A.5.17 |
| Screen Policy | Lock ≤15 min idle; auth on wake | Screen Policy | CC.6.1 / A.7.4 |
| Firewall | Enabled all profiles | Firewall | CC.6.6 / A.8.20 |
SecureSlate Asset Management scores each device X/5 against these policies—giving auditors a direct line from written standard to device state.
Rollout workflow
Rolling out MDM security policies is a three-track project: document, enforce, prove.
Track 1: Document (Weeks 1–2)
- Draft or update endpoint security / mobile device policy incorporating all five areas.
- IT Security documents MDM profile specifications matching each requirement.
- Legal and executive approval with version control in SecureSlate policy module.
- Communicate to all employees: enrollment deadline and expectations.
Track 2: Enforce (Weeks 2–6)
- Build MDM baseline profile bundle (all five checks).
- Enroll devices; block production access until 5/5 (via conditional access).
- Handle exceptions through formal risk acceptance—not Slack approvals.
- Train IT on remediation workflow.
Track 3: Prove (Ongoing)
- Connect MDM to SecureSlate Asset Management.
- Weekly evidence sync; monthly leadership dashboard.
- Quarterly policy review with IT attestation that profiles match policy.
- Include policy + evidence in pre-audit PBC package.
| Milestone | Success criteria |
|---|---|
| Policy approved | Version in repository; annual review scheduled |
| Profiles deployed | 100% in-scope smart groups assigned |
| Fleet compliant | ≥95% devices at 5/5 |
| Evidence live | SecureSlate sync verified for observation period start |
Evidence and review cadence
| Activity | Cadence | Owner | Output |
|---|---|---|---|
| Policy approval / review | Annual or on material change | GRC + Legal | Signed policy version |
| MDM profile audit | Quarterly | IT Security | Profile export matches policy |
| Fleet compliance report | Weekly | IT + GRC | X/5 dashboard |
| Exception register review | Quarterly | CISO / GRC | Risk acceptances current |
| Remediation metrics | Monthly | IT | MTTR, open failures |
| Pre-audit PBC | Before fieldwork | GRC | Endpoint evidence package |
Auditors expect policy approval before the observation period begins—not drafted during fieldwork. If policy version 2.0 shipped in month four of a twelve-month window, be prepared to show compliance under both versions or scope the sample accordingly.
Enforce policies with SecureSlate
SecureSlate connects MDM security policies to compliance operations:
- Policy library — draft, approve, and version endpoint security policies
- Asset Management 5/5 checks — HD Encryption, Anti-Virus, Password Policy, Screen Policy, Firewall
- Control mapping — link policies and device evidence to SOC 2 and ISO 27001 controls
- Continuous monitoring — replace point-in-time attestation with scheduled MDM sync
- Remediation tracking — failures become tasks with owners before auditors sample
- Audit exports — policy approvals + fleet status + remediation samples in one PBC package
Policies define the standard. MDM enforces it. SecureSlate proves it operated—week after week, device after device.
For the full platform story, see how SecureSlate MDM and compliance work together.
FAQ: MDM security policies
Do we need separate policies or one endpoint security policy?
One consolidated endpoint security or mobile device policy with sections for each check is common and easier to maintain. Avoid five disconnected documents that contradict each other.
What if our framework does not name these controls explicitly?
SOC 2 CC.6.x and ISO 27001 Annex A themes map cleanly to the five checks. Customer questionnaires ask the same questions regardless of framework label.
Can we use weaker settings for executives or developers?
Only with documented risk acceptance and CISO approval. Undocumented exceptions fail audits and breach programs.
How do BYOD devices fit?
BYOD typically gets lighter profiles or selective controls. Document scope in policy and BYOD policy; exclude unmanaged personal devices from production access.
When should we adopt these policies?
Before MDM enrollment at scale—and definitely before a Type II observation window starts. Retroactive policy backdating is a red flag for auditors.
How does SecureSlate help if we already have policies?
SecureSlate links approved policies to live MDM check status and evidence—closing the gap between "we have a policy" and "we can prove it operates."
How often should MDM profiles be updated?
Review quarterly and after major OS releases. Apple and Microsoft updates can change profile keys; stale profiles cause silent check failures.
Disclaimer (legal note)
SecureSlate is not a law firm, and this article does not constitute legal advice or create an attorney-client relationship. Security and compliance obligations vary by industry, contract, and jurisdiction—consult qualified counsel as needed.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
Find compliance gaps in 30 seconds
