Mobile device policy

ISO/IEC 27017 Clause 6.2.1 requires you to adopt a mobile device policy plus supporting security measures that manage the risks created when mobile devices access cloud services. Operationalize it by defining allowed device types and enrollment rules, enforcing strong authentication and device security baselines, protecting cloud data on-device, and maintaining the ability to remotely wipe or revoke access. ¹

Key takeaways:

• A “policy” alone is not enough; you need technical controls that enforce it for cloud access from mobile devices. ¹
• Scope must cover both corporate and personal mobile devices if they can reach cloud services, including email, SaaS, and admin consoles.
• Keep audit-ready evidence: the policy, an enforced baseline, enrollment/exception records, and remote wipe/access revocation proof.

Mobile devices are now a primary path into cloud services: email, collaboration suites, customer data platforms, ticketing tools, and sometimes even cloud provider admin consoles. ISO/IEC 27017 Clause 6.2.1 addresses the resulting risk: lost or stolen devices, weak device passcodes, unpatched operating systems, insecure Wi‑Fi, shared devices, and unmanaged personal phones accessing sensitive cloud data.

For a Compliance Officer, CCO, or GRC lead, the fastest way to implement this requirement is to treat it as an access-control and data-protection problem with a policy wrapper. Your “mobile device policy” must clearly define what devices may access which cloud services, under what security conditions, and what happens when a device becomes noncompliant. Then you must back it with security measures that are real and testable: authentication controls, encryption and screen lock requirements, device management and health checks, and remote wipe or rapid access revocation.

This page translates the clause into implementable steps, concrete artifacts to retain, and the exam questions you should prepare for, using only the requirement text and its plain-language intent. ¹

Regulatory text

ISO/IEC 27017:2015 Clause 6.2.1: “A policy and supporting security measures shall be adopted to manage the risks introduced by using mobile devices to access cloud services.” ¹

Operator meaning: you must (1) publish an approved mobile device policy that covers cloud access, and (2) implement security measures that actually reduce mobile-originated risk for cloud services (for example authentication, data protection, and remote wipe capability). ¹

Plain-English interpretation (what the requirement is really asking)

A compliant program answers these questions clearly and enforces the answers technically:

• Which mobile devices may access our cloud services? Corporate-owned only, or also BYOD.
• Which cloud services are in scope? SaaS apps, IaaS/PaaS consoles, SSO portals, and any cloud-hosted data repositories.
• What must be true before access is granted? Strong user authentication, a secure device state (screen lock, encryption, patch level), and a way to remove data or cut off access if the device is lost or the user leaves.
• How do we manage exceptions? A controlled process, time-bounded approvals, and compensating controls.

The clause is intentionally outcome-based. Auditors will look for alignment between the written policy and the controls in your identity provider, MDM/MAM, endpoint security, and cloud app configurations. ¹

Who it applies to

In-scope entities

• Cloud service providers (CSPs): You must manage your workforce and administrative access paths to the cloud services you operate, including staff/admin mobile access to production management planes. ¹
• Cloud service customers (CSCs): You must manage how employees and contractors use mobile devices to access your cloud-hosted business systems and data. ¹

Operational contexts that typically trigger scrutiny

• BYOD access to corporate SaaS (email, file sharing, chat, CRM).
• Mobile access to sensitive datasets (customer records, regulated data, secrets).
• Mobile access to privileged functions (admin portals, IAM consoles, CI/CD approvals).
• Third-party support staff using phones/tablets to access your cloud environment.

What you actually need to do (step-by-step)

1) Set scope and ownership

• Name an executive owner (often Security or IT) and a policy owner (often Security/GRC).
• Define “mobile device” for your environment (phones, tablets; decide on laptops separately).
• Inventory cloud services reachable from mobile devices: start with SSO logs and app catalogs.

Deliverable: Mobile Device Policy scope statement + list of in-scope cloud services.

2) Write the mobile device policy as enforceable rules

Include, at minimum:

• Allowed device categories: corporate-owned; BYOD allowed/not allowed; special handling for shared devices.
• Enrollment requirement: which devices must enroll in management (MDM/MAM) before access.
• Authentication requirements: MFA for cloud access; restrictions for high-risk or privileged apps. ¹
• Device security baseline: screen lock, encryption, OS supportability, patching expectations, jailbreak/root prohibition, secure configuration.
• Data handling rules: local storage limits, copy/paste restrictions where appropriate, approved apps only for certain data classes, prohibition on personal cloud backups for corporate data (define your standard).
• Loss/theft response: user reporting expectations; remote wipe or selective wipe triggers; access revocation steps. ¹
• Privacy and monitoring notice: what the company can see/do on corporate devices vs BYOD (this reduces HR/legal friction).
• Exceptions: who can approve, required compensating controls, documentation, and review cadence.

Tip for speed: write the policy to match what your tools can enforce. If your IdP supports device compliance checks, state that compliance is required for access to specified cloud apps.

3) Implement supporting security measures (controls that prove the policy is real)

Map each policy requirement to a technical control and an evidence source:

• Identity and access
  • Enforce MFA for cloud services accessed via mobile. ¹
  • Apply conditional access: block noncompliant devices; step-up auth for risky sign-ins; restrict privileged access from mobile where feasible.
• Device management
  • Deploy MDM/MAM and require enrollment for access to sensitive cloud apps.
  • Configure compliance checks (encryption on, passcode/biometric set, OS version supported, not rooted/jailbroken).
• Data protection
  • Require device encryption and screen lock.
  • Use app protection policies for corporate data (containerization, prevent “open in” to unmanaged apps) where needed.
• Incident readiness
  • Ensure remote wipe (full or selective) and rapid token revocation are operational and tested. ¹

Minimum bar auditors expect: you can show that an unmanaged or noncompliant phone cannot access sensitive cloud services, and that a lost phone leads to fast containment.

4) Operationalize: onboarding, offboarding, and ongoing compliance

• Joiner process: new users receive instructions; enrollment is validated; access is granted only after compliance.
• Mover process: role changes trigger re-evaluation (especially for privileged access).
• Leaver process: revoke sessions/tokens; wipe corporate data; confirm closure in the ticketing system.
• Ongoing monitoring: review noncompliant device reports; chase remediation; disable access for persistent noncompliance.

5) Test the control set (prove it works)

Run tabletop and technical tests:

• Attempt cloud access from a non-enrolled device.
• Mark a device as noncompliant (disable passcode/encryption in a test device) and confirm access is blocked.
• Execute remote wipe/selective wipe and confirm corporate app data removal and session revocation. ¹

Capture screenshots, logs, and tickets as evidence.

Required evidence and artifacts to retain

Keep artifacts that connect policy → configuration → operation → verification:

• Approved Mobile Device Policy (versioned, with approval record).
• Standards/baselines: mobile configuration baseline; encryption and screen lock requirements; approved OS versions.
• MDM/MAM configuration exports or screenshots showing compliance rules.
• IdP/SSO conditional access policies for mobile (screenshots/exports).
• MFA enforcement evidence for cloud services. ¹
• Enrollment records: device inventory, ownership classification (corporate/BYOD), and user mapping.
• Exception register: request, risk acceptance/compensating controls, approver, and review notes.
• Incident artifacts: lost/stolen tickets, wipe/revocation logs, and closure evidence.
• Testing results: periodic control test scripts and outcomes.

If you use Daydream to run your control evidence program, store the policy, system exports, and test results as a single requirement packet so audits do not turn into screenshot hunts.

Common exam/audit questions and hangups

• “Show me the policy, and show me where it is enforced.”
• “Which cloud services can be accessed from mobile devices, and how do you know?”
• “Do personal devices access corporate cloud data? If yes, how do you protect it and remove it?”
• “Walk through a lost phone scenario. Who does what, and what is the containment mechanism?” ¹
• “How do you prevent a rooted/jailbroken device from accessing cloud services?”
• “How are exceptions approved and reviewed?”

Hangup: teams present an acceptable policy but cannot show conditional access, MDM compliance gates, or wipe capability in practice.

Frequent implementation mistakes (and how to avoid them)

1. Policy says BYOD is allowed, but there is no MAM/MDM path for BYOD.
   Fix: either prohibit BYOD for sensitive apps or implement selective wipe and app protection controls.

2. No definition of “cloud services.”
   Fix: scope cloud services via SSO/app catalog and include high-risk admin portals explicitly.

3. Remote wipe exists “in theory” but is not tested.
   Fix: run a controlled wipe/revocation test and retain evidence. ¹

4. Privileged access allowed from any mobile device.
   Fix: restrict privileged actions to managed devices, or disallow mobile for admin functions where practical.

5. Exception process is informal (Slack approvals, no expiry).
   Fix: require ticketed approvals, named owner, and explicit compensating controls.

Enforcement context and risk implications

No public enforcement cases were provided for this specific ISO/IEC 27017 clause in the source catalog. Practically, the risk is still clear: mobile access expands the attack surface for cloud services, and failures tend to show up as unauthorized access, data exposure through unmanaged apps, and slow containment after loss or theft. The clause’s “policy and supporting security measures” language makes enforcement-like audit findings straightforward: gaps are easy to demonstrate with a single noncompliant device test. ¹

Practical 30/60/90-day execution plan

Because no time-based requirements are specified in the provided sources, treat this as phased execution you can complete as your environment allows.

First 30 days (Immediate)

• Confirm in-scope cloud services and access paths (SSO logs, app inventory).
• Draft or refresh the Mobile Device Policy with enforceable rules.
• Identify current control gaps: MFA coverage, conditional access availability, MDM/MAM coverage, wipe capability.

Next 60 days (Near-term)

• Turn on or tighten MFA for cloud access from mobile. ¹
• Roll out MDM/MAM enrollment for the first wave of users and high-risk apps.
• Implement conditional access: block noncompliant devices for sensitive cloud apps.
• Stand up the exception register and approval workflow in your ticketing system.

Next 90 days (Operationalize and prove)

• Expand controls to remaining cloud services in scope.
• Run a lost/stolen device drill: wipe/selective wipe and token revocation, then archive evidence. ¹
• Formalize ongoing monitoring: noncompliance review, exception reviews, and periodic control tests.
• Package evidence per requirement in Daydream (policy + configs + tests + exceptions) so audits and renewals are repeatable.

Frequently Asked Questions

Do we need to manage BYOD phones under ISO/IEC 27017 mobile device policy?

If BYOD devices can access cloud services, they introduce the same category of risk and should be in scope. Your policy can allow BYOD with constraints (for example, app protection and selective wipe) or prohibit it for sensitive services, but you must enforce the rule with supporting measures. ¹

What counts as “supporting security measures” beyond the written policy?

Measures are the controls that reduce and contain mobile-originated risk for cloud access, such as MFA, device compliance gating, encryption/screen lock requirements, and remote wipe or access revocation. Auditors expect evidence from systems that enforce these rules, not only a document. ¹

Is remote wipe mandatory, and what if we can’t wipe a personal device?

The provided summary explicitly calls out remote wipe capability as part of addressing mobile risks, so you should have a wipe or selective wipe option for corporate data, plus the ability to revoke cloud sessions quickly. If you cannot wipe BYOD devices, restrict BYOD access to low-sensitivity services or require app-level containment that supports selective removal. ¹

How do we prove compliance to an auditor without over-collecting personal data?

Focus evidence on control enforcement outcomes: device compliance status, conditional access decisions, MFA enforcement, and wipe/revocation logs. Your policy should state what device telemetry you collect and what you do not collect, especially for BYOD, and you should retain approvals for that approach. ¹

Does the policy need to cover contractors and third parties?

Yes if they access your cloud services from mobile devices. Treat contractors and other third parties as in-scope identities, apply the same enrollment and conditional access rules, and document exceptions where contractual or technical limits exist. ¹

What’s the fastest way to get audit-ready on this requirement?

Publish the policy, enforce MFA and conditional access for your most sensitive cloud apps, require MDM/MAM enrollment for those apps, and run a documented lost-device test that shows wipe or access revocation. Then store the policy, configs, and test evidence together (for example, in Daydream) for repeatable audits. ¹

Footnotes

1. ISO/IEC 27017:2015 Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services