What Safeguard 4.12 asks for on mobile devices and why it is hard to prove
If your staff read corporate mail or run line-of-business apps on personal phones and tablets, Safeguard 4.12 asks you to keep those enterprise apps and data in a workspace separate from personal apps and data, wherever the device supports it. CIS gives Apple Configuration Profiles and Android Work Profiles as examples of how to do this. The Safeguard sits in the Data asset class and the Protect security function, and it is assigned to Implementation Group 3 only, so it applies to enterprises that already run security specialists and handle regulated, sensitive assets. The core risk it targets is data leakage between the two sides of a device: a corporate attachment opened in a personal app, a copy-paste from a work document into a consumer messaging app, or a personal cloud backup that captures enterprise content.
The difficulty is proof. A policy saying staff must use work profiles does not show that any device actually has one. The CIS Controls Assessment Specification measures this Safeguard through mobile device management software, counting capable mobile devices that have authorized, properly configured MDM software separating the enterprise workspace. That means your evidence is MDM records and device coverage, not a document. Confirm with your MDM vendor which profile or policy settings produce the separation on each platform, how the console reports compliance per device, and whether unsupported or unenrolled devices appear in the count. Also confirm which devices your organization treats as capable, because the Safeguard applies only where the device supports a workspace.
Start by reconciling your mobile asset inventory (Safeguards 1.1 and 2.1 and the secure configuration process in 4.1 feed the measurement) against MDM enrollment, so every in-scope phone and tablet is either separated or documented as an exception. Export compliance reports on a schedule and keep them as dated evidence. Where a self-hosted platform is in use, you can script checks against enrollment data, but you should confirm each platform's current capabilities with its documentation before relying on it. An implementation partner can prepare the configuration and evidence pipeline, while the organization owns the decision and an independent assessor judges the result.
Which devices, apps, data and teams fall under Safeguard 4.12
Safeguard 4.12 reaches further than the phone itself. It touches the devices people carry, the enterprise apps and data on them, the teams that run device management and the third parties that supply the tooling. The scoping decisions below determine how much of that work applies to your organization.
Corporate-owned mobile end-user devices
Enterprise-owned phones and tablets are the simplest case because the organization controls the hardware, the operating system version and the management enrollment. Start with an inventory from Safeguard 1.1 and confirm which devices are assigned to an end user and which are shared or kiosk devices. Check that each device supports an enterprise workspace on its platform, then record which ones are enrolled in MDM with a separated workspace configured. Devices without that separation are exceptions that need a documented reason.
Bring-your-own-device phones and tablets
Personal devices that access enterprise email, chat or files fall in scope when they hold enterprise data. The workspace approach keeps enterprise apps and data in a separate container, so the organization manages only that container and leaves personal apps alone. Decide which apps and data are allowed on personal devices before enrollment, and document the privacy boundary with employees. Expect the BYOD policy, consent wording and workspace controls to be reviewed together.
Enterprise apps and data inside the workspace
The workspace must hold the enterprise apps and data that the Safeguard protects, such as corporate email, calendar, messaging, document stores and internal line-of-business apps. Build a list from the software inventory required by Safeguard 2.1 and from the data inventory under Control 3, then map each item to the workspace. Items left outside the workspace, such as a file downloaded to the personal photo library, are the gaps assessors and attackers both look for.
Teams that own MDM and offboarding
Ownership usually splits across endpoint engineering, which runs MDM policy, the service desk, which handles enrollment and exceptions, and HR, which triggers departures. Name one owner for each workspace setting and one for each exception. Offboarding is the step most often missed: the workspace must be removed or wiped when someone leaves, and that action depends on a timely HR-to-IT handoff. Document that handoff in the secure configuration process so it can be tested.
MDM vendors and other third parties
If an MDM platform, a hosting provider or a managed service operates the device fleet, that party is a service provider whose handling of device data and configuration needs review. Ask which vendor staff can change workspace policy, where device inventory and compliance data are stored, and how the vendor reports failing devices. Self-hosted MDM keeps this data inside your own environment, which changes the review but does not remove it.
Devices that cannot support a workspace
Some older devices, unsupported operating system versions and certain kiosk or specialized handsets cannot run a separated workspace. Safeguard 4.12 applies only where the device supports it, so record each such device with its platform version, the reason it cannot be separated and the compensating control, such as restricted apps, network limits or retirement from enterprise access. Review this list on a fixed cycle, because platform support changes over time.
Whether IG3 applies to your enterprise
Safeguard 4.12 is assigned to Implementation Group 3 only. CIS defines IG3 for enterprises with security specialists and regulated or sensitive assets facing sophisticated, targeted attacks. Smaller organizations may not need this Safeguard as a requirement, though CIS allows any organization to adopt it voluntarily. Before scoping work, confirm your IG with your own risk assessment, and check whether a regulator, customer or contract requires IG3 safeguards by name.
How the CIS assessment specification measures 4.12 through MDM
The CIS Controls Assessment Specification for v8.1 measures Safeguard 4.12 through mobile device management software. The assessor's question is how many capable mobile end-user devices are enrolled in authorized MDM software that is configured to separate the enterprise workspace from personal apps and data. The specification sets out six measures for this count, so the number of devices that pass is the figure to track, not whether an MDM product is installed somewhere in the estate. A device that is enrolled but lacks the workspace separation settings does not count toward the result.
Three other Safeguards supply the data this measurement depends on. Safeguard 1.1, the enterprise asset inventory, tells you which mobile devices are in scope at all. Safeguard 2.1, the software inventory, shows which apps run on them and whether the enterprise apps are the ones you expect. Safeguard 4.1, the secure configuration process, defines the approved configuration baseline that the workspace settings must match. If the device inventory is incomplete or the configuration baseline is undocumented, the numerator and denominator of the 4.12 count cannot be produced with confidence, so an assessor will usually check these records first.
CIS states that the Controls define what to measure, not how to measure it. The assessment specification does not tell an assessor which MDM reports to pull, which sampling method to use or how to treat devices enrolled in a bring-your-own-device program. Confirm these points with your auditor before fieldwork: the device population used for the denominator, the evidence format for MDM reports, whether the assessor will test a sample of devices or the full population, and how exceptions are recorded. The answers determine how much preparation the count requires.
How an assessor tests Safeguard 4.12 and what they ask for
This table maps each step an assessor is likely to take against the six measures in the CIS Controls Assessment Specification for Safeguard 4.12, the evidence they will request, and the findings that commonly come up. Read it as a preparation checklist: the evidence column is what to have ready before the assessor asks, and the findings column shows where the gaps usually appear.
| Test step | Evidence requested | Common findings |
|---|---|---|
| Device population against the asset inventory | Asset inventory extract for mobile end-user devices, reconciled with the MDM device list and the Safeguard 1.1 process | Mobile devices in the MDM that are absent from the inventory, or inventory entries with no MDM record |
| MDM enrollment coverage of capable devices | Count of capable devices, count of enrolled devices and the rule used to decide which devices are capable | Capable devices that were never enrolled, or devices excluded from scope without a documented reason |
| Separation settings applied to enrolled devices | Exported configuration profile or work profile policy, with the assignment groups it applies to | Policy assigned to a group but not received by devices, or separation settings that cover only part of the enterprise data set |
| Sample of devices checked for separation | Screenshots or MDM reports for a sampled set of devices showing the enterprise workspace is distinct from personal apps and data | Enterprise apps that open or store data in personal areas, or personal apps that can read enterprise containers |
| Written secure configuration process from Safeguard 4.1 | Current process document covering mobile devices, its review date and approval record | Process omits mobile devices, has no annual review, or does not name the mobile profile or work profile settings |
| Exceptions for unsupported devices | Register of devices that cannot support a separate workspace, with owner, compensating controls and approval | Exceptions with no expiry or owner, or unsupported devices carrying enterprise data with no compensating control recorded |
Implementing enterprise workspaces step by step
This sequence moves Safeguard 4.12 from an inventory of mobile devices to a documented workspace policy, an enrolled and reported fleet, and a recorded list of exceptions that an assessor can review. Each step produces a record that the next step depends on.
Confirm the mobile device inventory
Start from the enterprise asset inventory produced under Safeguard 1.1, and filter it to mobile end-user devices, both enterprise-owned and personally owned devices that access enterprise data. Record the operating system, version and ownership model for each device, since Apple Configuration Profiles and Android Work Profiles apply to different platforms and versions. The output is a reviewed mobile subset of the inventory with an owner named for each record. The step is done when every mobile device that touches enterprise data appears in the inventory with its platform and ownership model, and the inventory owner has signed off on the list.
Align with the secure configuration process
Check the documented secure configuration process from Safeguard 4.1 and confirm that it covers mobile end-user devices, their operating systems and the applications that run on them. Add or update the mobile baseline so that workspace settings sit inside the approved configuration standard rather than in a separate, undocumented setup. The output is an updated configuration process section for mobile devices, with the approval record and review date. The step is done when the process names the mobile platforms in scope and the person accountable for changes to the mobile baseline.
Select an MDM that supports both platforms
Choose mobile device management software that can deploy Apple Configuration Profiles to iOS and iPadOS devices and Android Work Profiles to Android devices, and that can report on enrollment and policy status for each. Ask the vendor to show how the product separates managed apps and data from personal ones on each platform, and confirm which OS versions are supported. Where the MDM is hosted by a third party, review its data handling terms in the same way as any other service provider. The output is a written selection record listing the platforms covered, the reporting features confirmed in a demonstration and any gaps. The step is done when the record shows the product meets the platform requirements for every device group in scope.
Define the workspace policy
Write the workspace policy that states which apps, accounts and data belong in the enterprise workspace, which personal apps and data must stay outside it, and how the boundary is enforced on each platform. Cover account setup, app installation rules, data sharing between workspaces, copy and paste or file movement limits where the platform allows them, and what happens to enterprise data when a device is retired or its user leaves. Assign an owner to the policy and link it to the risk decision that justifies the design. The output is a versioned workspace policy document with an approval record. The step is done when each policy rule maps to a configuration setting that the MDM can deploy and report on.
Pilot the workspace on a device group
Enroll a small, representative group of devices that covers each platform and ownership model in scope, and deploy the workspace configuration to them. Test sign-in, app installation, data separation and removal of the workspace, and record any device that fails a policy check or a user workflow. Adjust the configuration and the policy wording where the pilot shows a gap between what the policy says and what the device enforces. The output is a pilot test record with pass and fail results per device and per policy rule, plus a list of configuration changes made. The step is done when every policy rule has a tested result and the pilot owner has approved the rollout settings.
Roll out and enroll the fleet
Deploy the approved workspace configuration to the remaining devices in controlled waves, and require enrollment before enterprise apps or data are released to a device. Communicate the steps to users, including what personal data stays untouched and how to get help. Track enrollment against the inventory from the first step so that each device is either enrolled, scheduled for enrollment or on the exception register. The output is an enrollment report that matches devices to the inventory, with dates and status. The step is done when every in-scope device is enrolled or has an approved exception, and no enterprise app is available on an unenrolled device.
Handle unsupported devices through exceptions
Some devices will not support a workspace, either because the operating system is too old, the device is not enrolled in the MDM, or the platform cannot separate the workspace. For each one, record the reason, the compensating control (for example, blocking enterprise access from that device), the risk owner who accepts the exception and a review date. Keep the register in the same system as the inventory so that the two can be reconciled. Ask the MDM and the risk function to confirm which exceptions remain open at each review. The output is an exception register with an accepted risk owner, a compensating control and a review schedule for each entry. The step is done when no unsupported device can reach enterprise data without an approved, dated exception.
Set up recurring compliance reporting
Schedule recurring reports from the MDM that show, for each platform and device group, how many capable devices have the workspace configured and how many are out of policy. Set up a review that compares these reports with the inventory and the exception register, and that routes non-compliant devices to a named owner for action. Keep the reports and review records as evidence that the workspace operates over time, not only at rollout. Confirm with the assessor which report format and retention period they expect before the first cycle. The output is a recurring report schedule, a dated review record and a remediation log. The step is done when the first review cycle has closed with each finding assigned, and the reports can be reproduced from the MDM on request.
Who owns the workspace controls and who can help
The organization owns Safeguard 4.12. Someone accountable must decide which mobile devices are in scope, which apps and data belong in the enterprise workspace, and what personal data the organization will not touch. That accountability does not transfer to a partner or an auditor, even when outside specialists build the configuration.
- Policy owner: Approves the mobile device policy, defines what counts as enterprise data and records which device ownership models (corporate-owned or personal with enterprise access) are allowed.
- MDM administrators: Operate the mobile device management platform, maintain the Configuration Profiles or Work Profiles, and review compliance reports for capable devices.
- HR and offboarding owners: Tell IT when staff leave or change roles so enterprise workspaces are removed promptly, and confirm that personal content is left alone.
- Asset and software owners: Supply the device inventory and approved app list that the measurement depends on, drawn from the work behind Safeguards 1.1 and 2.1.
Before engaging anyone outside, confirm internally who signs off the policy and who answers an auditor's questions about it.
An implementation partner can prepare the systems and evidence that show Safeguard 4.12 is in place. Partners such as DeployOpen work in the client's own environment on fixed, written scopes. The partner builds and documents the setup; it does not decide the organization's risk position and does not issue any report or certificate.
- MDM configuration: Deploying and configuring the open-source or commercial MDM platform the client has chosen, inside its own infrastructure, with the settings the client approved.
- Profile build: Creating Apple Configuration Profiles or Android Work Profiles that separate managed apps and data from personal ones, and testing them on representative devices.
- Evidence pack: Exporting configuration baselines, compliance reports, change records and test results in a form an assessor can sample.
- Documentation: Writing the procedures for enrollment, enforcement and removal so the client's own staff can operate the setup after handover.
Ask any partner for the written scope, the named deliverables and who on the client side approves each one. Costs typically depend on the number of platforms, the MDM tool and the device ownership models in scope, so request a quote that itemizes them.
An independent auditor, assessor or certification body tests the control and reaches a conclusion. Depending on the framework a customer or regulator requires, that may be an internal audit function that is independent of the operators, an external CIS Controls assessor, or a certification body for a standard such as ISO/IEC 27001. The auditor samples evidence, interviews staff and observes how the control works.
- Design review: Checking that the mobile policy and Configuration Profiles or Work Profiles address the workspace separation the Safeguard describes.
- Operating effectiveness: Sampling capable devices from the MDM inventory and confirming that the separation is enforced on each sample.
- Exceptions: Reviewing devices that cannot support a separate workspace and how the organization documented and handled them.
- Reporting: Issuing the opinion, findings or certificate under its own name and independence rules.
Confirm with your customer or regulator which assessor they accept. Check whether the chosen assessor has a conflict with the party that built the configuration, because a partner that also tests its own work weakens the result.
Evidence that passes a Safeguard 4.12 review
An assessor testing Safeguard 4.12 wants to see that capable mobile devices are enrolled, that the enterprise workspace is actually separated, and that the records behind those facts are complete and current. The cards below cover the artifacts that connect the MDM platform, the device inventory, the written standard and the exceptions. Keep them dated and linked to one another so a reviewer can trace any device from policy to enrollment to compliance result.
MDM enrollment reports with device counts
Export enrollment reports from the mobile device management platform showing how many mobile end-user devices are enrolled, grouped by platform and ownership model. The assessment specification measures Safeguard 4.12 by counting capable devices with authorized, properly configured MDM software that separates the enterprise workspace, so the denominator matters as much as the numerator. Check that the report counts every capable device, not only those that happen to check in. Confirm the platform version and its enrollment method so the report can be reproduced later.
Exported configuration profiles or work profile policy
Keep copies of the actual workspace policy: Apple Configuration Profiles for iOS and iPadOS, or Android Work Profile policy for Android, as CIS gives both as examples. A screenshot of the console is weaker than the exported profile, because the export shows the settings that were pushed to devices. Confirm that the profile restricts copying data between managed and personal apps and that it is version-controlled. Record which profile version was in force on each date of the audit period.
Written mobile workspace standard
A written standard states which devices must use a separated workspace, which apps and data belong inside it, how personal data is kept out, and who approves changes. It should reference Safeguard 4.1, the secure configuration process, so the mobile baseline sits inside the documented configuration process rather than beside it. Assessors look for a current version, an owner, an approval record and a review date. Confirm that the standard is the one the MDM policy actually implements.
Asset inventory linkage
Safeguard 4.12 depends on knowing which mobile devices exist. Link each enrolled device to its record in the enterprise asset inventory, which the assessment specification lists as a prerequisite through Safeguard 1.1. Each record should carry the device identifier, owner, operating system version and enrollment status. Devices in the MDM console with no inventory record, or inventory records with no MDM enrollment, are the gaps an assessor will find first.
Compliance reports for passing and failing devices
Compliance reports show, for each enrolled device, whether the workspace policy is applied and whether the device passes or fails its checks. Retain both the pass results and the failures, because a report with no failures invites questions about whether failing devices were excluded. Fleet policies, which ask yes or no questions of devices through osquery queries, show which devices on each fleet pass or fail a given policy. Ask the platform owner how a device that goes out of compliance is flagged and how long it stays flagged.
Exception and change logs
Exception records document each device or user allowed to operate without a separated workspace, with the reason, the approver, the compensating control and an expiry date. Change logs record every edit to the workspace profile, the MDM configuration and the standard itself. Together they show that the control was not quietly weakened. Review open exceptions at each assessment cycle and close any that no longer have a documented justification.
What meeting Safeguard 4.12 costs in money and effort
This table compares the cost components of meeting Safeguard 4.12, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to keep it down. No supplied fact gives a price or duration, so use it to shape your quote requests rather than as a budget. The main takeaway is that licensing is only one line, and profile engineering, enrollment and evidence upkeep usually drive the total.
| Cost component | One-time or recurring | Cost drivers | How to reduce it |
|---|---|---|---|
| MDM licensing or self-hosted operation | Recurring (commercial licence) or recurring internal operations (self-hosted) | Number of capable mobile devices, vendor licence model, hosting and staff time to run the server | Use open-source MDM where it fits your platforms, and confirm that it supports separated work profiles on both iOS and Android before selecting it |
| Engineering time to build profiles | One-time, with periodic revision | Number of device platforms and OS versions, number of app and data separation rules, and how many user groups need different workspaces | Start from one standard workspace policy for each platform, then add groups only where a documented need exists |
| Device enrollment effort | One-time per device, plus recurring for new hires and replacements | Share of personal devices (bring-your-own-device), staff turnover, and how many devices need manual steps | Enroll company-owned devices before issue, and write a short user guide for personal devices |
| Evidence upkeep | Recurring | Frequency of reporting, number of devices that must be tracked, and how often profiles change | Schedule automated compliance reports and keep the policy version history in version control |
| Remediation of failing devices | Recurring | Devices that drop out of compliance, unsupported OS versions, and users who remove the workspace | Set a clear escalation path and retire unsupported devices from the enterprise workspace |
| External review or testing | Periodic, and optional | Scope of the review, whether a third party tests workspace separation on sample devices, and report depth | Ask for a fixed-scope test of a small device set, with the deliverables agreed in writing before work starts |
| Auditor sampling | Periodic, paid to the independent auditor | Number of devices and policies sampled, and whether the auditor needs to observe a live enrollment | Keep a current device list and profile export ready so that sampling does not require manual reconstruction |
Where open-source tooling fits for mobile and endpoint evidence
Open-source tools do not separate enterprise and personal workspaces on a phone. That separation comes from the MDM platform that enrolls the device and pushes the Apple Configuration Profile or Android Work Profile settings. What tools such as Wazuh and Fleet can add is independent endpoint configuration evidence that sits alongside the MDM record, so an assessor sees more than the MDM console's own report. Before relying on either tool for mobile devices, confirm in writing which device platforms, OS versions and checks it actually covers, because the Wazuh Security Configuration Assessment is documented around endpoint policies and the Fleet policy model is built on osquery, and neither should be assumed to read MDM profile state on iOS or Android without verification.
Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies that check files, directories, registry keys and running processes, and it recommends remediation. Its policies are shipped mostly based on CIS benchmarks and can be extended with custom policies. For Safeguard 4.12, the practical use is on the desktop and server estate that sits next to the mobile fleet, plus any custom policy your team writes to check a configuration item that the MDM does not expose. Ask the vendor or your own test lab whether a given mobile operating system is supported by the agent and which policies apply to it, then record the result for each platform in your evidence file.
Fleet policies are yes or no questions asked of devices as osquery queries, and the policies page shows which devices in each fleet are passing or failing each policy. This gives a device-level pass or fail view that can be exported as evidence of a recurring check. The decision to make is whether a policy can answer the question that matters for Safeguard 4.12, such as whether a device is enrolled in MDM with the work profile in place, and whether the answer is reliable on the platforms you run. If no reliable query exists, the evidence should come from the MDM platform instead, and Fleet results should be treated as supporting data rather than proof of separation.
Common questions about Safeguard 4.12 cost, effort and audit
How much effort does Safeguard 4.12 take to implement?
The effort depends mostly on how many mobile devices are in scope, how many device types and operating system versions they run, and how many enterprise apps must sit inside the managed workspace. Effort is front-loaded in the design phase, where you decide which profile or work profile model fits each platform, and then recurs as devices, OS releases and apps change. CIS does not publish hours or cost figures for this Safeguard, so ask any implementation partner for a fixed-scope estimate based on your device counts, platforms and existing MDM licensing. Keep in mind that the Safeguard is measured through MDM software, so an MDM platform with working enrollment and policy enforcement is a prerequisite for most of the work.
Can an organization implement Safeguard 4.12 in-house?
Yes, if the team has the skills to design and operate mobile device management, write and test configuration profiles, and produce evidence an assessor can follow. The Safeguard itself is short, but it depends on Safeguards 1.1, 2.1 and 4.1 being in place, because the assessment specification uses the enterprise asset inventory, software inventory and documented secure configuration process as inputs. Teams without that foundation often spend most of their effort there. A useful self-assessment question is whether your team can show, for every mobile device, that the enterprise workspace is separated and that the configuration is authorized and still in effect. Organizations that cannot answer that confidently often bring in outside help for design, testing and evidence preparation, while keeping ownership of the policy decisions.
How long does it take to be ready for a 4.12 review?
Readiness depends on the state of your inventory and MDM tooling when you start, not on the Safeguard alone. An organization with an accurate device inventory, an MDM platform already enrolling most devices and a written secure configuration process will move faster than one still deciding which devices are corporate-owned. No timeline figure is supplied for this work, so ask for a phased plan with dated milestones in a written scope before committing. A practical readiness check is whether the MDM console can report, at any time, which capable devices have the workspace profile applied and which do not.
What does Safeguard 4.12 need from IT and HR?
IT owns the technical controls: MDM enrollment, configuration profiles or work profiles, app management, inventory reporting and exception handling. HR and legal define who is eligible for managed devices, what employees must accept, how offboarding works and how personal data is treated during a wipe. Both functions need to agree on what happens when an employee leaves, because the separation Safeguard 4.12 describes must hold through the device lifecycle, not only at enrollment. Document these responsibilities in the secure configuration process so an assessor can trace each decision to a named owner.
Can Safeguard 4.12 cover BYOD devices?
It can, where the device platform supports a separate work profile or workspace, which is the model CIS points to with Android Work Profiles and Apple Configuration Profiles. The practical limit is that the organization cannot manage the whole personal device, so the policy must be built around the enterprise workspace, not the entire handset. Expect extra work on user consent, privacy notices, data residency questions and the limits of remote wipe, which should target only the enterprise container. Devices that do not support a workspace separation, or that users refuse to enroll, should be recorded as exceptions and assessed against your risk decisions rather than silently excluded from the count.
What should a partner deliver for Safeguard 4.12?
A partner should deliver a written scope naming the devices, platforms, MDM tooling and integrations in play, plus a design for the workspace separation and the configuration profiles or work profiles that implement it. Ask for test results on representative devices, a runbook for enrollment and exceptions, and the evidence set mapped to the six measures in the assessment specification. DeployOpen prepares systems, controls and evidence; it does not issue audit reports or certifications, and the organization owns the policy and its operation. Confirm with the partner which deliverables are one-time and which require a retainer for ongoing support.
Which evidence will an assessor ask to see for 4.12?
An assessor will look for the MDM inventory of capable mobile devices, the configuration profiles or work profiles in force, proof that they are authorized and properly configured, and a reconciliation showing which devices are compliant and which are exceptions. Expect to show change records for the policy and periodic reports that match the device inventory. The assessment specification defines the measures; the exact evidence format should be confirmed with your assessor, and the CIS Controls Assessment Specification is the right reference for the measures themselves.
Where organizations fall short on mobile workspace separation
Most gaps under Safeguard 4.12 are not missing profiles. They are places where the workspace exists on paper but cannot be proven on a specific device, for a specific user, at a specific point in time. Each card below names one such gap and the fix that closes it.
No MDM coverage for BYOD
Personal devices that access corporate email or files often sit outside mobile device management entirely, so no workspace is ever created. The CIS assessment measures capable devices with authorized, properly configured MDM software that separates the enterprise workspace, so an unenrolled device counts as a gap. Fix: decide which personal devices may access enterprise data, enroll them into a work profile or managed container, and block access from anything unenrolled through conditional access.
Profiles deployed but not verified
A configuration profile can be pushed successfully and later removed, disabled or left in a failed state. Assessors look for evidence that the separation is in force on the device, not only that a policy was sent. Fix: report on installed profile status per device, alert on removal, and review failed deployments on a set schedule.
Missing link to the asset inventory
Safeguard 4.12 depends on knowing which mobile devices exist. The assessment specification lists Safeguards 1.1 and 2.1 as prerequisites because they produce the device and software data the measurement needs. If the MDM device list does not reconcile with the enterprise asset inventory, the denominator of capable devices is wrong. Fix: reconcile MDM enrollment against the asset inventory each review cycle and investigate any device found in one list but not the other.
No exception process for unsupported devices
Some handsets or operating system versions cannot host a managed workspace, and teams often allow them quietly. The Safeguard applies only where the device supports it, so the gap is an undocumented exception, not the device itself. Fix: record each unsupported device model, the business reason for access, the compensating limits such as blocked downloads, and an expiry date for the exception, with approval from a named owner.
Offboarding that leaves enterprise data behind
When a user leaves, the enterprise workspace can remain on a personal device after account disablement, especially where the profile was removed from the MDM console but the data was not. Safeguard 4.11 covers remote wipe, and Safeguard 4.12 expects the enterprise workspace to be separable from the personal side. Fix: make workspace removal and enterprise data wipe part of the offboarding checklist, and test it on one device per platform before relying on it.
Policy with no owner on the device side
Written mobile policies often name an MDM administrator but not the people who approve device eligibility, review exceptions or accept the risk of a personal device carrying enterprise data. The assessment is easier to pass when the process is documented and the owners are named. Fix: assign an accountable owner for mobile workspace separation, document the review cadence, and keep the approvals with the MDM records so the evidence is in one place.
How DeployOpen works on this
DeployOpen plans and implements the mobile workspace controls that Safeguard 4.12 asks for, inside your own infrastructure, and prepares the configuration and evidence an assessor can test. The organization owns the control, and only an independent auditor or assessor can issue findings or certification.
How we scope
- The written scope names the mobile device platforms, ownership models and MDM software in use before any work starts.
- We confirm which devices support a separate enterprise workspace, such as Apple Configuration Profiles or Android Work Profiles, and which do not.
- Prerequisite data from the enterprise asset inventory, software inventory and secure configuration process is checked for Safeguards 1.1, 2.1 and 4.1.
How we build
- We configure the MDM software to deploy and enforce the enterprise workspace on in-scope mobile devices, within your own infrastructure.
- Workspace settings are tested on representative devices to confirm enterprise apps and data stay separate from personal apps and data.
- Configuration is kept under version control so changes to the workspace policy can be traced and reviewed.
How we hand over
- You receive documentation of the workspace configuration, its scope and the device population it covers, mapped to the assessment measures for Safeguard 4.12.
- Evidence exports show which capable devices have authorized, properly configured MDM software enforcing the separation, ready for an assessor to review.
- Known gaps, such as unsupported devices or unmanaged exceptions, are listed with owners so your team can decide how to address them.
How we support
- Ongoing support, upgrades and continuous testing of the workspace configuration are available as a retainer after handover.
- Changes to mobile operating system versions or MDM software are reviewed against the documented configuration before rollout.
- Your team confirms the final scope, classification of devices and any mapping to other frameworks with your auditor or assessor before relying on it.
