Endpoint Device and BYOD Policy Template (ISO/IEC 27001 A.8.1)

Endpoint Device and BYOD Policy: [Organization name]

Sets the rules for every laptop, desktop, tablet and phone that stores, processes or gives access to [Organization name] information, whether the organization owns it or a person brings their own device (BYOD). Supports ISO/IEC 27001:2022 + Amd 1:2024 Annex A control A.8.1 (user endpoint devices), with links to A.5.10, A.6.7, A.7.9, A.7.14, A.8.7, A.8.8, A.8.19 and A.8.24, and the guidance in ISO/IEC 27002:2022. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

• 1. Purpose, scope and applicability
• 2. Roles and responsibilities
• 3. Device categories and permitted use
• 4. Minimum security requirements
• 5. Device lifecycle
• 6. Patching and operating system support
• 7. Software installation and application control
• 8. Separation of work data on BYOD
• 9. BYOD privacy commitments
• 10. Lost or stolen devices
• 11. Compliance monitoring and enforcement
• 12. Exceptions
• 13. Size tiers
• 14. Records and evidence
• 15. User acknowledgement
• 16. References
• Standard and licence note

1. Purpose, scope and applicability

This policy protects information stored on, processed by or reachable from user endpoint devices against loss, theft, malware, unauthorised access and leakage. It turns the risk treatment decisions in the risk treatment plan (DOC-ISMS-013) for endpoint risks into rules that people and tooling can follow.

The policy applies from the effective date to all staff and to third parties whose contract requires them to follow it. Where a contract sets stricter rules for a customer environment, the contract wins.

2. Roles and responsibilities

3. Device categories and permitted use

Rules:

1. A personally owned computer is never used to store organization information locally. Use category C4 or request a C1 device.
2. Privileged access (administration of production, identity or security tooling) is allowed only from category C1 devices, as set in security/privileged-access-standard.
3. A person may enrol at most [two] personal mobile devices in C3.
4. Contractors use a C1 device issued by [Organization name] or a C4 browser session unless their contract allows a contractor-managed device that meets section 4 and the supplier agreement (DOC-ISMS-068).

4. Minimum security requirements

Example rule entries for the rule log:

5. Device lifecycle

1. Request and approval. The line manager approves the category.
2. Procure. Buy only from approved channels that support automated enrolment, so the device is managed from first boot.
3. Enrol. The device receives the MDM profile, EDR agent and the platform baseline before the user signs in to business systems.
4. Issue. Record the device in the asset inventory (DOC-ISMS-012) with serial number, user and category. The user acknowledges this policy (section 15).
5. Operate. Patching, monitoring and compliance checks run continuously (sections 6 and 11).
6. Repair. Before third-party repair, remove the storage or wipe the device, or use a repair service bound by confidentiality terms.
7. Reissue. Wipe and re-enrol before a new user receives it.
8. Retire. Sanitise to the method in the equipment disposal and reuse record (DOC-ISMS-057) and keep the certificate.

6. Patching and operating system support

Devices on an operating system the vendor no longer supports lose access to organization services on the date support ends, unless an approved exception exists (section 12). Deadlines and severities follow security/vulnerability-management-policy; open items are tracked in the vulnerability remediation tracker (DOC-ISMS-072).

7. Software installation and application control

1. Users install software on C1 devices from the self-service catalogue. Requests for other software go to IT, which checks licensing, vendor support and security before adding it to the catalogue.
2. Local administrator rights are removed. Time-bound elevation is granted through [elevation tool] with the reason logged.
3. Application control blocks known-bad and unapproved executables and scripts according to DOC-ISMS-059.
4. Browser extensions are limited to an allow-list managed centrally.
5. Generative AI tools and plug-ins follow ai-data/ai-usage-policy.
6. On C3 devices only the managed apps listed in [app list] may open organization data.

8. Separation of work data on BYOD

If a person declines the container method, they use category C4 (browser only) or request a corporate device.

9. BYOD privacy commitments

[Organization name] commits to the following for personally owned devices enrolled in category C3:

1. Data collected is used only to protect organization information and to decide whether the device may connect.
2. Device data is retained for [90] days after unenrolment, then deleted.
3. The organization never performs a full wipe of a personally owned device. Only selective wipe is used.
4. If an investigation needs a personal device, the person is asked for consent and may decline. Legal holds follow the incident response plan (DOC-ISMS-020) and applicable law.
5. A staff privacy notice describes this processing and is listed in the records of processing where those are kept (compliance/gdpr-ropa).
6. Costs: [the organization pays a monthly allowance of USD [x] / no allowance]. Use your local currency.

10. Lost or stolen devices

1. Report loss or theft to [service desk channel, phone number] at once, and no later than [1] hour after noticing. Reports are accepted at any time.
2. The service desk logs the event in the incident register (DOC-ISMS-021) following the security event reporting procedure (DOC-ISMS-023).
3. Security operations lock the device and revoke sessions and refresh tokens within [1] hour of the report.
4. Corporate devices are fully wiped. BYOD devices receive a selective wipe.
5. If the MDM record shows the device was encrypted and locked, record the evidence and close the event. If not, or if it is unknown, raise an incident under DOC-ISMS-020 and assess it with compliance/personal-data-breach-assessment.
6. Theft is reported to the police where required by insurance or law. Keep the crime reference with the record.

11. Compliance monitoring and enforcement

Security operations review the non-compliant device list [weekly]. The ISMS manager reports the metrics below to the steering committee (DOC-ISMS-007) each quarter.

Breaches of this policy are handled under the disciplinary process for security breaches (DOC-ISMS-052), proportionate to intent and impact.

12. Exceptions

Exceptions are requested with the security exception request (DOC-ISMS-122, security/security-exception-request), assessed against the risk criteria (DOC-ISMS-010) and approved at the authority the risk methodology (DOC-ISMS-010 section 2.4) sets for the residual risk: the risk owner for Low; the risk owner and department head for Medium (top management if the risk category is Averse, DOC-ISMS-015 section 9 rule 1); top management with a treatment decision for High, recorded in the risk acceptance record (DOC-ISMS-019). Critical residual risk is not approvable as an exception: treat it or stop the activity. The ISMS manager reviews every request and keeps the exception register. Maximum duration is 12 months for Low or Medium and 6 months for High; at expiry the exception is reassessed, and a renewal is a new decision (DOC-ISMS-122 section 7).

13. Size tiers

14. Records and evidence

Link each record to control A.8.1 in the control evidence matrix (DOC-ISMS-033, isms/control-evidence-matrix).

15. User acknowledgement

By signing, I confirm that I have read this policy, that I will use only devices permitted for my category, keep them updated, locked and encrypted, report loss or theft at once, and, for a personally owned device, that I understand the privacy commitments in section 9 and the selective wipe in section 8.

16. References

Related templates: compliance/acceptable-use-policy (DOC-ISMS-040), isms/remote-working-policy (DOC-ISMS-054), isms/malware-protection-standard (DOC-ISMS-059), isms/secure-configuration-baseline (DOC-ISMS-060), isms/saas-productivity-security-baseline (DOC-ISMS-075), security/vulnerability-management-policy, security/cryptography-standard, security/privileged-access-standard, isms/equipment-disposal-reuse-record (DOC-ISMS-057), isms/offboarding-security-checklist (DOC-ISMS-053), compliance/statement-of-applicability (DOC-ISMS-011).

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A control A.8.1 and related controls) and ISO/IEC 27002:2022. Control numbers are cited with short original labels. The policy text, tables, categories and examples are original and reproduce no text from ISO/IEC standards: obtain the official standards from ISO (https://www.iso.org/standard/82875.html, https://www.iso.org/standard/75652.html) or your national standards body. NIST SP 800-124 Rev. 2 is a US government publication. Check for the current edition of each reference before use.

Template licence: MIT.