BYOD Under ISO 27001: Personal Devices, Privacy and Audit Evidence

Allowing people to use personal phones, tablets or computers for work can improve flexibility, but it changes the organisation’s control boundary. The device is privately owned while corporate information, identities and services remain organisational responsibilities.

ISO/IEC 27001 does not impose one named bring-your-own-device document or a universal set of technical settings. The organisation should assess its risks, determine applicable controls and operate them. A sound personal-device programme therefore starts with business use and risk rather than a generic prohibition or blanket permission.

Direct answer: ISO 27001 does not ban personal devices or prescribe one BYOD control set. An organisation should define which personal-device uses are allowed, assess the related risks, apply proportionate safeguards, protect personal privacy, and retain evidence that access, incidents and offboarding are controlled in practice.

Define the operating model first

Personal-device access is not a single condition. Separate the models the organisation supports:

• Browser-only access: corporate services are reached through a managed web session, with little or no local storage.
• Managed work container: business applications and data are separated within a managed area on a personal device.
• Enrolled personal device: the organisation applies defined security settings and monitoring to the device or work profile.
• Remote desktop or virtual workspace: processing remains in a controlled environment while the personal device acts mainly as a display and input endpoint.
• Local processing: corporate files or applications are stored and processed directly on the personal device.

These models have different exposure, privacy implications and evidence. State which are authorised for each role, information type and service. Do not let convenience become an undocumented access model.

Start with eligibility and risk

Define which users, devices, operating-system versions, locations and business activities are eligible. Consider whether highly privileged administration, regulated processing, software development or access to sensitive information should require organisation-owned equipment.

Evaluate risks such as:

• loss or theft of the device;
• shared use by family or other unauthorised people;
• insecure applications or excessive permissions;
• unsupported operating systems;
• malicious software and credential theft;
• local storage, backup or synchronisation outside approved services;
• insecure networks;
• inability to collect evidence during an incident;
• delayed revocation when employment changes; and
• conflict between monitoring needs and personal privacy.

Record the affected service, information and consequence rather than treating “BYOD” as a complete risk statement. The risk score calculator can help teams test consistent likelihood and impact scales before applying the organisation’s approved method.

Establish clear participation terms

People need to understand the arrangement before enrolment. Participation terms should explain:

• eligible device types and permitted business uses;
• required security settings and supported versions;
• which corporate applications and information may be accessed;
• what the organisation can monitor or collect;
• which personal content remains outside visibility;
• circumstances that may lead to access restriction, lock or removal of corporate data;
• incident-reporting duties;
• user responsibility for backup of personal data;
• support boundaries and costs; and
• withdrawal, role change and departure steps.

Privacy and employment-law requirements vary. Involve legal, privacy and human-resources specialists where appropriate, especially when monitoring, location information, investigation or remote removal could affect personal data.

Consent alone may not resolve every privacy issue. Minimise collected data, explain purpose and retention, restrict access to administrative information, and select technology that separates business data from personal content wherever feasible.

Apply controls according to the access model

Identity and access

Use individual identities, strong authentication and conditional access appropriate to risk. Restrict personal devices from highly privileged functions unless the organisation can demonstrate adequate control. Define session lifetime, reauthentication and revocation behaviour.

The access-control governance guide explains how policy, approval, technical enforcement and review should align. The MFA evidence guide covers scope and testing for stronger authentication.

Device condition

Where justified, require supported software, screen locking, encryption, secure boot, protection against unauthorised modification and timely security updates. Device-attestation or mobile-management signals can support access decisions, but define how failures, false positives and temporary exceptions are handled.

Data separation and storage

Prefer designs that keep corporate data in managed services or a work container. Disable unmanaged export, backup, copy-and-paste or local download where risk warrants it. Define which information may never be stored on a personal device.

Applications and communications

Authorise the applications used for corporate information. Control risky integrations and unapproved synchronisation. Protect data in transit, validate certificates and avoid exposing internal services directly where a controlled access gateway can be used.

Logging and monitoring

Collect the minimum security information needed to detect misuse and investigate events. Possible records include enrolment, authentication, access decisions, device-compliance state, corporate application activity and administrative actions. Document who can see the data and how long it is retained.

The Annex A control lookup can help teams explore control purposes relevant to access, endpoints, logging, information transfer and incident management.

Integrate asset and identity records

Personal ownership does not remove the need to know which device or managed work profile is authorised. Maintain a record that connects the user, device or enrolment identifier, access model, approval, current state and last verification.

This need not collect unnecessary personal detail. Use a proportionate identifier and make the record part of the broader asset inventory and ownership process.

Reconcile enrolled devices with identity, access and management platforms. Investigate active access from unenrolled, noncompliant or departed-user devices.

Prepare for loss and incidents

Users should know how to report loss, theft, suspected compromise or accidental disclosure promptly. Response steps can include:

• revoke sessions, tokens and certificates;
• disable the corporate account or device registration;
• remove corporate data or the managed work profile where authorised;
• assess exposed information and reporting obligations;
• preserve relevant corporate logs;
• reset credentials if compromise is plausible; and
• document recovery, lessons and return-to-service decisions.

Avoid assuming a remote-removal command succeeded. Devices may be offline, altered or unreachable. Confirm status where possible and evaluate residual exposure. Integrate these cases with the incident-management evidence process.

Control offboarding and withdrawal

When a participant changes role, leaves the organisation or withdraws a device, remove access and corporate material promptly. The workflow should address identities, application sessions, certificates, managed profiles, local files, shared links and any recovery keys held by the organisation.

Record the action and exceptions. If technical removal is impossible, assess the remaining information and choose compensating measures, such as credential revocation, link expiry or enhanced monitoring.

Personal-device access should also be reviewed when the device becomes unsupported, repeatedly fails compliance, is transferred to another person or is replaced.

Manage exceptions deliberately

Business pressure often creates exceptions: urgent travel, an unsupported specialist application or a temporary device replacement. Define who can approve an exception, how long it lasts, what information and services remain accessible, and which compensating safeguards apply.

An exception should not silently become permanent. Use an expiry date and confirm closure. Repeated exceptions may reveal that the approved operating model does not meet a real business need.

Worked BYOD policy-to-evidence map

Consider an illustrative example: a sales representative may access the customer relationship platform from a personal phone, but only through the managed mobile application. Local export is disabled, the work profile can be removed without erasing personal photographs, and high-risk administrative functions remain limited to organisation-owned devices.

Governance decision	Example rule	Accountable owner	Evidence an auditor can inspect
Eligible use	Sales staff may use enrolled iOS or Android devices for the approved mobile application	Service owner	Approved role-to-service matrix and current enrolment population
Access conditions	Strong authentication, supported operating system and compliant work profile are required	Identity and endpoint owners	Conditional-access result, compliance state and a blocked noncompliant attempt
Data boundary	Corporate records remain in the managed application; unmanaged export and backup are disabled	Information owner	Application policy, configuration export and a test showing blocked transfer
Privacy boundary	Administrators can see device posture and corporate-app events, not personal content	Privacy owner	Privacy notice, administration-role permissions and retained field inventory
Loss response	Report promptly; revoke sessions and remove the work profile where authorised	Incident owner	Recent exercise or case record showing time, actions, outcome and residual risk
Exit or withdrawal	Revoke identity sessions, remove corporate data and close the enrolment record	HR and identity owners	Leaver sample linking the employment trigger to revocation and verified removal

This map is illustrative AuditPrepared guidance, not a prescribed ISO form. Adapt the rows to the real access model and verify that the stated technical restriction works. A polished policy with no blocked-access test, lost-device case or completed leaver record is design evidence only.

Build audit evidence around operation

Design evidence may include:

• risk assessment and approved access models;
• eligibility and participation rules;
• privacy assessment and notices;
• required technical settings;
• incident, exception and offboarding workflows; and
• defined ownership across security, IT, privacy, HR and business teams.

Operating evidence may include:

• approved enrolments tied to active users;
• device-compliance and conditional-access records;
• proof of blocked noncompliant access;
• security-setting reports;
• incident tickets and response logs;
• time-bound exception approvals;
• removal records for leavers; and
• periodic reconciliations and management reporting.

Sample across risk, not only randomly. Include a privileged or high-impact user, a device that failed compliance, a recent enrolment, a lost device, an exception and a departed user. Trace each sample from approval through technical enforcement and current status.

An effective programme shows that policy, technology and user expectations agree. A partially effective programme has documented rules but inconsistent enrolment, removal or evidence. An ineffective programme permits access without reliable eligibility, separation, revocation or incident capability.

Measure control health

Useful measures include unauthorised access attempts, unsupported enrolled devices, overdue security updates, unresolved compliance failures, exceptions past expiry, lost-device response time and offboarding completion. Interpret trends in context; a rise in blocked attempts may show stronger enforcement rather than worsening behaviour.

Review the model when services, device platforms, privacy requirements, threats or working patterns change. Personal-device governance is an operating system of decisions, not a one-time document.

This article was cross-checked against the official ISO/IEC 27001 overview and NIST SP 800-124 Revision 2. The risk-based structure and evidence approach are original AuditPrepared guidance aligned to current practice.