BYOD Policy: The Essential 2026 Guide for ISO 27001

A BYOD policy is the document that decides what happens when your company’s data ends up on a phone your company does not own. Most organisations already have that situation — email on a personal handset is bring-your-own-device whether anyone called it that or not. What they usually lack is a written position on it, which is exactly what an ISO 27001 auditor asks for first.

This guide covers what a BYOD policy has to contain, which ISO 27001:2022 controls it satisfies, where the privacy line sits, and the enforcement decision that determines whether the policy is real or decorative.

What a BYOD policy is actually for

The purpose is not to list rules. It is to resolve, in advance, a conflict between two legitimate interests: the organisation needs to protect information on devices it does not control, and the employee owns the device and everything else on it.

Every difficult BYOD question comes back to that tension. Can you wipe the device? Can you see what apps are installed? What happens when someone leaves? A policy that does not answer those questions has not done its job, and one that answers them only in the organisation’s favour tends to collapse the first time it is tested.

The practical test is simple. If an employee resigned tomorrow with three years of company email on their own phone, does your documentation tell you what you are entitled to do about it? If the answer is “we would have to ask a lawyer”, you need a BYOD policy.

The ISO 27001 controls a BYOD policy satisfies

ISO 27001:2022 has 93 Annex A controls arranged in four themes. Bring-your-own-device is not one control — it sits across several, which is why organisations that try to handle it inside a general acceptable use document tend to leave gaps.

Control A 8.1 is the anchor. The standard expects you to have considered personally owned devices explicitly, including the question of separating organisational and private use, and to have addressed the ownership of information created on a device the organisation does not own.

That last point catches people out. If an employee drafts a proposal on their own tablet, who owns the file? The answer should be written down before it matters, not negotiated afterwards.

What to put in a BYOD policy

A workable document covers nine things. Anything less and an auditor will find the gap; anything much more and nobody reads it.

1. Scope. Which devices, which roles, which data classifications. It is entirely legitimate to permit BYOD for email and calendar while prohibiting it for anything classified confidential.
2. Eligibility and approval. Who may enrol a personal device, and who signs it off.
3. Minimum device standards. Supported operating system versions, patch currency, no jailbroken or rooted devices, screen lock and encryption enabled.
4. Enrolment and management. What software the employee must install, and precisely what visibility that software gives the organisation.
5. Permitted use. Which corporate services may be accessed, and what may be stored locally versus accessed only in session.
6. Prohibited actions. No forwarding to personal accounts, no unapproved cloud sync, no shared family use of an enrolled device.
7. Loss and incident reporting. A named channel and a stated time limit, because a lost phone is only manageable if you hear about it quickly.
8. Exit and remote wipe. Exactly what is removed, by what mechanism, and whether personal data can be affected.
9. Employee acknowledgement. A signature, recorded and retained. This is the part auditors sample.

The acknowledgement matters more than it looks. This is one of the few security documents that changes the legal relationship between employer and employee, and consent that was never explicitly given is difficult to rely on later.

Full MDM or containerisation: the decision that defines the policy

There are two credible enforcement models, and choosing between them shapes everything else in the document.

Full device management gives the organisation control over the whole handset — configuration, app installation, and the ability to wipe it entirely. It is straightforward to administer and deeply unpopular. It also means a departing employee’s personal photographs sit inside the blast radius of your offboarding process.

Containerisation, sometimes called a work profile, keeps corporate applications and data in a managed partition. The organisation controls and can wipe the container; the rest of the device is untouched and largely invisible to IT. It is the model most organisations should choose for personal devices, and modern mobile platforms support it natively.

Write the document to match what you actually deploy. A document promising employees that their personal data is out of scope, enforced by a full-wipe MDM profile, is a broken promise with an audit trail.

The privacy problem your BYOD policy has to solve

Managing a personal device means processing the employee’s personal data, and under GDPR an employment relationship is a poor basis for relying on consent, because consent given by an employee to an employer is rarely considered freely given. Legitimate interests is usually the sounder basis, which means doing the balancing test and writing it down.

Three commitments make the difference between a policy people accept and one they quietly evade:

• State what the management software can and cannot see. If it cannot read personal messages or browsing history, say so plainly — this is the single most common employee fear.
• Commit to selective wipe rather than full wipe wherever the technology allows it.
• Say what happens to personal data if a full wipe is ever unavoidable, and get that acknowledged in advance.

Handle this well and enrolment stops being a fight. Handle it badly and you get shadow IT, which is the outcome this policy exists to prevent.

Keeping it enforceable

A policy nobody reviews decays quietly. Mobile platforms change their management capabilities every year, and a clause describing what your MDM can see is usually the first thing to go out of date. Review annually at minimum, and additionally whenever you change management platform or extend access to a new class of data.

Three practices separate documents that survive an audit from those that do not. Keep a register of enrolled devices, because A 8.1 is hard to evidence without knowing which devices are in scope. Keep an exceptions register, because there will always be an executive with an unsupported phone and an undocumented exception is a finding where a documented, time-limited and approved one is not. And re-collect acknowledgements when the policy materially changes, since a signature against a superseded version proves very little.

Auditors sample all three. They will ask for the device register, pick two or three entries, and trace them back to an approval and a signed acknowledgement. If that chain holds, the control is evidenced. If the register is a spreadsheet last touched eighteen months ago, the conversation goes differently.

Where a BYOD policy fits in your ISMS

It is a subordinate policy, not a top-level one. It sits under the information security policy, references the asset management and access control policies, and is called out in your Statement of Applicability against the controls listed above. Our guide to the mandatory documents ISO 27001 requires shows where subordinate policies sit in the wider document set, and the ISO 27001 policy templates guide covers how many separate policies you actually need.

If you are still deciding how the 2022 control set maps to what you already have, the ISO 27001:2022 changes are worth reading alongside this.

Frequently asked questions

Is a BYOD policy mandatory for ISO 27001?

Not as a named document. ISO 27001 requires the risk to be addressed, not a specific file. But if personal devices touch organisational information and you have no documented position, control A 8.1 is difficult to evidence, and auditors will raise it.

Can we remotely wipe an employee’s personal phone?

Only if they have agreed to it in advance and the capability is technically in place. That agreement is the acknowledgement clause in the BYOD policy. Wiping a personal device without a documented basis creates a legal problem considerably larger than the data you were protecting.

Should we pay a stipend for BYOD?

It is a business decision rather than a security one, but it has a security effect: paying a contribution strengthens the case that use of the device for work is a genuine arrangement with agreed terms, which makes the policy easier to enforce.

What about contractors and temporary staff?

Cover them explicitly. They are the population most likely to use unmanaged devices and least likely to have signed anything. Either bring them inside the BYOD policy with the same acknowledgement, or prohibit personal device access for them outright.

Does a BYOD policy replace an acceptable use policy?

No. Acceptable use governs behaviour across all devices; the BYOD policy governs the specific conditions attached to devices the organisation does not own. They cross-reference, and both should exist.

Where to start

Decide the enforcement model first — container or full management — because every clause about wiping, visibility and offboarding follows from it. Then write the scope, get the acknowledgement wording reviewed by whoever handles your employment contracts, and record signatures from day one.

Our ISO 27001 Toolkit includes a BYOD policy alongside the acceptable use, remote working and asset management documents it depends on, all mapped to the 2022 Annex A controls and editable to your environment.

Control references verified against ISO/IEC 27001 as published by ISO, August 2026.