# 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*.

<!--
Guidance: How to use this template
- Use it when you define or refresh how endpoints are managed, before an
  MDM or EDR roll-out, or when BYOD use has grown without rules.
- Fill first: the device categories in section 3 and the minimum
  requirements table in section 4. Every other section depends on them.
- Main pitfall: writing rules the tooling cannot enforce or report on.
  An auditor asks for the MDM compliance report, not for the policy text.
  If a rule cannot be measured, mark it as user responsibility and say how
  it is checked.
- BYOD touches personal data of staff. Agree section 9 with HR, legal and
  employee representatives where they exist, before roll-out.
- Related templates: `compliance/acceptable-use-policy`,
  `isms/remote-working-policy`, `isms/malware-protection-standard`,
  `isms/secure-configuration-baseline`, `security/vulnerability-management-policy`,
  `security/cryptography-standard`, `isms/equipment-disposal-reuse-record`,
  `isms/offboarding-security-checklist`, `compliance/asset-inventory`.
-->

## Document control

<!-- Guidance: Changes to device categories, BYOD privacy commitments or the patch deadlines are major versions and need re-approval and staff communication. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-058 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@head-of-it] |
| Approvers/reviewers | [@isms-manager], [@ciso], [@hr-lead], [@dpo or privacy lead] |
| Last updated | YYYY-MM-DD |
| Effective from | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.8.1, cited only); ISO/IEC 27002:2022 |
| Next scheduled review | YYYY-MM-DD (at least annually) |
| Applies to | [All employees, contractors, temporary staff and third parties who access organization information from an endpoint] |
| Supporting standards | [Secure configuration baseline DOC-ISMS-060], [Malware protection standard DOC-ISMS-059], [Acceptable use policy DOC-ISMS-040] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Policy owner | [@head-of-it] | [Prepared] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD |
| Privacy lead | [@dpo] | [Reviewed for BYOD privacy] | YYYY-MM-DD |
| Top management | [@coo] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@owner] | First issue |
| [x.y] | YYYY-MM-DD | [@author] | [Change summary] |

## Contents

- [1. Purpose, scope and applicability](#1-purpose-scope-and-applicability)
- [2. Roles and responsibilities](#2-roles-and-responsibilities)
- [3. Device categories and permitted use](#3-device-categories-and-permitted-use)
- [4. Minimum security requirements](#4-minimum-security-requirements)
- [5. Device lifecycle](#5-device-lifecycle)
- [6. Patching and operating system support](#6-patching-and-operating-system-support)
- [7. Software installation and application control](#7-software-installation-and-application-control)
- [8. Separation of work data on BYOD](#8-separation-of-work-data-on-byod)
- [9. BYOD privacy commitments](#9-byod-privacy-commitments)
- [10. Lost or stolen devices](#10-lost-or-stolen-devices)
- [11. Compliance monitoring and enforcement](#11-compliance-monitoring-and-enforcement)
- [12. Exceptions](#12-exceptions)
- [13. Size tiers](#13-size-tiers)
- [14. Records and evidence](#14-records-and-evidence)
- [15. User acknowledgement](#15-user-acknowledgement)
- [16. References](#16-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose, scope and applicability

<!-- Guidance: Say exactly which devices are in and out. Auditors look for the boundary: OT terminals, meeting-room PCs, kiosks and developer test devices are the usual grey zone. Name where each excluded class is governed instead. -->

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.

| Item | Value |
|---|---|
| In scope | Laptops, desktops, tablets and phones that access [Organization name] e-mail, collaboration tools, source code, customer data or internal systems, whether organization-owned or personally owned |
| In scope, access method | Native applications, managed browsers and unmanaged browsers reaching organization services |
| Out of scope | [Servers and cloud workloads (secure configuration baseline DOC-ISMS-060), OT operator stations (OT security standard), network devices (network security standard DOC-ISMS-063)] |
| Related controls | A.5.10 acceptable use, A.6.7 remote working, A.7.9 assets off premises, A.7.14 secure disposal, A.8.7 malware, A.8.8 vulnerabilities, A.8.19 software installation, A.8.24 cryptography |
| Risk references | [RISK-006 *(Example)*: customer data on a lost laptop], [RISK-019 *(Example)*: data copied from BYOD phone] |

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

<!-- Guidance: One accountable owner per activity. Do not leave "IT" as the answer for everything: name who approves BYOD enrolment, who wipes a device and who decides exceptions. -->

| Role | Responsibilities |
|---|---|
| Policy owner [@head-of-it] | Maintains this policy, the MDM and EDR configuration, compliance reporting and the device inventory |
| ISMS manager [@isms-manager] | Checks that the policy matches the risk assessment and the SoA entry for A.8.1, tracks exceptions and metrics |
| Security operations [@secops] | Monitors EDR alerts and non-compliant devices, runs remote lock and wipe on request |
| Privacy lead [@dpo] | Approves what device data the organization collects from BYOD and the privacy notice |
| HR [@hr-lead] | Includes device obligations in onboarding and offboarding, handles policy breaches with the disciplinary process (DOC-ISMS-052) |
| Line managers | Approve the device category a person needs, confirm returns at exit |
| Every user | Uses only permitted devices, keeps them updated and locked, reports loss or theft at once |

## 3. Device categories and permitted use

<!-- Guidance: Define few categories. Each extra category is another column of rules to enforce. Decide what each category may reach: a BYOD phone with managed apps does not need the same reach as a corporate laptop. -->

| Category | Description | May access | May not access |
|---|---|---|---|
| C1 Corporate managed computer | Organization-owned laptop or desktop, fully enrolled in MDM and EDR | All systems the user is authorised for, including restricted data and admin tools | None by category (access control rules still apply) |
| C2 Corporate managed mobile | Organization-owned phone or tablet, fully enrolled | E-mail, chat, collaboration, MFA authenticator, approved business apps | Admin consoles, bulk export of restricted data |
| C3 BYOD mobile with app protection | Personal phone or tablet using managed apps or a work profile, no full device management | E-mail, chat, calendar, documents in managed apps, MFA authenticator | Restricted data downloads outside managed apps, admin consoles |
| C4 BYOD or third-party computer, browser only | Personal or contractor laptop reaching services through a browser session with session controls | Web versions of e-mail and collaboration, with download and print blocked | Source code, production consoles, local sync of files |
| C5 Shared or kiosk device | Meeting-room PCs, reception terminals, training laptops | Named functions only (signage, visitor sign-in) | Personal sign-in to business systems |

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

<!-- Guidance: Each row must map to an MDM, EDR or identity setting you can report on. State the measurable value, not "strong". Auditors sample devices against this table. -->

| Requirement | C1 Corporate computer | C2 Corporate mobile | C3 BYOD mobile | C4 Browser only |
|---|---|---|---|---|
| Enrolment | Full MDM, enrolled at purchase through automated enrolment | Full MDM | App protection policy or work profile | None, session controls at the identity provider |
| Encryption at rest | Full-disk encryption on, recovery key escrowed in MDM | Device encryption on (platform default) | Device encryption on, checked at enrolment | Not checked, no local storage permitted |
| Screen lock | Auto-lock after [5] minutes, password or biometric | Auto-lock after [2] minutes, PIN of at least [6] digits | Device PIN of at least [6] digits, app PIN for managed apps | Session timeout [30] minutes idle |
| Supported OS | Vendor-supported version only | Vendor-supported version only | Vendor-supported version, minimum [OS version] set in policy | Supported browser version |
| Patching | Section 6 deadlines | Section 6 deadlines | Minimum OS level enforced at sign-in | Browser up to date at sign-in |
| Malware protection | EDR per DOC-ISMS-059 | Mobile threat defence [Yes / No] | Jailbreak and root detection in managed apps | Not applicable |
| Host firewall | On, managed centrally | Platform default | Platform default | Not applicable |
| Local admin rights | Removed by default, time-bound elevation on request | Not applicable | Not applicable | Not applicable |
| Configuration baseline | DOC-ISMS-060 platform baseline | DOC-ISMS-060 mobile baseline | Not applicable | Not applicable |
| Backup of work data | Work files in organization cloud storage, no reliance on local copies | Same | Same | Same |

Example rule entries for the rule log:

| Rule ID | Category | Rule | Enforced by | Evidence |
|---|---|---|---|---|
| END-RULE-001 *(Example)* | C1 | Full-disk encryption on, key escrowed | MDM compliance policy | Monthly MDM encryption report |
| END-RULE-002 *(Example)* | C1, C2 | OS version not older than vendor support | MDM compliance policy plus identity conditional access | Non-compliant device list |
| END-RULE-003 *(Example)* | C3 | Managed apps block copy and paste to unmanaged apps | App protection policy | Policy export, quarterly |
| END-RULE-004 *(Example)* | C4 | Download, print and clipboard blocked in browser sessions | Session control at identity provider | Session policy export |

## 5. Device lifecycle

<!-- Guidance: The lifecycle is where most audit findings sit: devices issued before enrolment, devices returned but not wiped, devices sold without sanitisation records. Make each step produce a record. -->

```mermaid
flowchart LR
  A["Request and approval"] --> B["Procure through approved channel"]
  B --> C["Automated enrolment: MDM, EDR, baseline"]
  C --> D["Issue to user, record in asset inventory"]
  D --> E["Operate: patch, monitor, comply"]
  E --> F{"Repair, reissue or retire?"}
  F -->|Repair| G["Vendor repair with data removed or drive retained"]
  G --> E
  F -->|Reissue| H["Wipe, re-enrol, update owner"]
  H --> D
  F -->|Retire| I["Sanitise and record disposal"]
```

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

<!-- Guidance: Align the deadlines with the vulnerability management policy so there is one set of numbers. Measure on the device fleet, not on the patch release. -->

| Update type | Deadline from release *(Example)* | Enforcement |
|---|---|---|
| Actively exploited vulnerability (for example listed in the CISA Known Exploited Vulnerabilities catalogue) | [3] days | Forced install and restart after a [24]-hour deferral |
| Critical or high security update | [14] days | Forced after deferral period |
| Other security updates | [30] days | Automatic |
| Feature or major OS version | [90] days after the organization approves it | Staged rings: IT pilot, early adopters, all |
| Browser and productivity apps | Automatic, [7] days | Auto-update enforced |

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

<!-- Guidance: A.8.19 is about deciding what software may land on live systems, and laptops count. On endpoints this means a self-service catalogue plus blocking what you do not allow, not a ban nobody follows. -->

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

<!-- Guidance: Separation is what makes BYOD acceptable to both sides: the organization controls its data, the person keeps control of the device. Describe the technical method you use and test the selective wipe before roll-out. -->

| Measure | Requirement |
|---|---|
| Container method | [Work profile on Android, managed apps with app protection on iOS and iPadOS, or managed browser] |
| Data flow | Copy, paste, save-as and share from managed to unmanaged apps blocked |
| Backup | Work data excluded from personal device backups where the platform allows |
| Authentication | App PIN or biometric after [30] minutes inactive, plus MFA at sign-in |
| Offline access | Managed apps wipe cached work data after [30] days without sign-in |
| Selective wipe | Removes managed apps and work data only, never personal content |
| Minimum device state | Not jailbroken or rooted, supported OS version, device lock set |

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

## 9. BYOD privacy commitments

<!-- Guidance: Write what the organization can and cannot see in plain words. Where a data protection law applies (for example the GDPR in the EU and EEA), staff device data is personal data: name the purpose, the legal basis and the retention. Check with the privacy lead. -->

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

| The organization can see | The organization cannot see |
|---|---|
| Device model, OS version, device name | Personal e-mail, messages, photos, contacts |
| Whether the device lock and encryption are on | Browsing history outside managed apps |
| Whether the device is jailbroken or rooted | Location (not collected) |
| List of managed apps and their versions | Personal apps and their content |
| Sign-in times to organization services | Phone call or messaging records |

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

<!-- Guidance: Speed matters more than form. Give one number or channel, accept reports 24/7 and measure time from report to lock. Decide in advance when a loss becomes a reportable personal data breach. -->

```mermaid
flowchart TD
  A["User reports loss or theft"] --> B["Service desk logs event in incident register"]
  B --> C["Lock device and revoke sessions and tokens"]
  C --> D{"Corporate device?"}
  D -->|Yes| E["Full remote wipe once lock confirmed"]
  D -->|No, BYOD| F["Selective wipe of work data"]
  E --> G{"Encrypted and locked at time of loss?"}
  F --> G
  G -->|Yes| H["Close as low-impact event, record evidence"]
  G -->|No or unknown| I["Raise incident, assess personal data breach"]
```

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

<!-- Guidance: Show the states a device moves through and what happens automatically. Grace periods avoid locking people out for a reboot, but must be short and visible in reports. -->

```mermaid
stateDiagram-v2
  [*] --> Compliant
  Compliant --> Grace: check fails
  Grace --> Compliant: fixed within grace period
  Grace --> Blocked: grace period ends
  Blocked --> Compliant: fixed and rechecked
  Blocked --> Retired: device lost or replaced
  Compliant --> Retired: device returned, lost or replaced
  Retired --> [*]
```

| State | Trigger | Effect |
|---|---|---|
| Compliant | All section 4 checks pass | Full access for its category |
| Grace | A check fails (for example a pending patch) | Access continues, user notified daily, grace period [72] hours |
| Blocked | Grace period ends, or a critical check fails (encryption off, jailbreak, EDR missing) | Conditional access blocks organization services until fixed |
| Retired | Device returned, lost or replaced | Removed from MDM and inventory after wipe |

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.

| Metric | Formula | Target *(Example)* |
|---|---|---|
| Fleet compliance | Compliant devices / all enrolled devices | At least 97% |
| Encryption coverage | C1 devices with encryption on / all C1 devices | 100% |
| Patch latency | Median days from release to install, critical updates | Under 7 days |
| Unmanaged access | Sign-ins from unmanaged devices outside C4 rules | 0 |
| Time to lock | Median minutes from loss report to lock | Under 60 |

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

## 12. Exceptions

<!-- Guidance: Every exception has an owner, a compensating control and an end date. Unlimited exceptions turn into an undocumented second policy. -->

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).

| Exception ID | Device and rule | Compensating control | Expiry |
|---|---|---|---|
| EXC-END-001 *(Example)* | Lab laptop on older OS for a medical device interface (END-RULE-002) | No e-mail or internet, isolated VLAN, monthly check | 2027-06-30 |

## 13. Size tiers

<!-- Guidance: Show how the policy scales. Small organizations can meet A.8.1 with the MDM built into their productivity suite; large ones need regional support and OT boundaries. -->

| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Device model *(Example)* | 38 C1 laptops for employees, 8 contractors on C4 browser sessions, C3 phones optional | C1 laptops for all staff, C2 phones for on-call and clinical support teams, C3 for others | C1 for office staff, C5 shared terminals on plant floors, OT stations governed separately |
| Tooling | MDM and app protection from the productivity suite, one EDR product | Dedicated MDM, EDR with managed detection service | Regional MDM tenants or groups per country, EDR integrated with SIEM |
| Ownership | Head of Engineering Operations (0.5 FTE ISMS manager) with one IT generalist | IT operations team, security team of 3 for monitoring | Group IT with site IT leads, CISO security office for policy and monitoring |
| BYOD privacy | Single notice | Notice reviewed by privacy lead (processor and controller roles) | Notice per country to meet local employment and privacy law, works council consultation where required |
| Reporting | Monthly compliance export reviewed by ISMS manager | Weekly dashboard, quarterly steering report | Per-site metrics rolled into group report |

## 14. Records and evidence

<!-- Guidance: List what proves the policy operates. Map each item into the control evidence matrix so audit sampling is quick. -->

| Record | Owner | Location | Retention *(Example)* |
|---|---|---|---|
| Device inventory with category and owner | [@head-of-it] | MDM and asset inventory DOC-ISMS-012 | Life of device plus 1 year |
| MDM compliance and encryption reports | [@head-of-it] | MDM console exports, ISMS evidence folder | 3 years (one certification cycle) |
| EDR coverage report | [@secops] | EDR console exports | 3 years |
| Policy acknowledgements | [@hr-lead] | HR system | Employment plus [6] years |
| Lost and stolen device records | [@secops] | Incident register DOC-ISMS-021 | 3 years minimum |
| Disposal and sanitisation certificates | [@head-of-it] | Equipment disposal and reuse record DOC-ISMS-057 | 6 years |
| Exceptions | [@isms-manager] | Exception register | Expiry plus 3 years |

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

## 15. User acknowledgement

<!-- Guidance: Collect the acknowledgement electronically at issue and at enrolment of a personal device, and again when the policy changes materially. -->

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.

| Name | Device category | Device ID | Signature | Date |
|---|---|---|---|---|
| [Name] | [C1 / C2 / C3 / C4] | [Asset tag or enrolment ID] | [Signature] | YYYY-MM-DD |

## 16. References

<!-- Guidance: Cite the editions used and check them at each annual review. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024, https://www.iso.org/standard/82875.html | Current, Amd 1 https://www.iso.org/standard/88435.html | Annex A control A.8.1 and related controls |
| ISO/IEC 27002:2022, https://www.iso.org/standard/75652.html | Current | Control guidance and attributes |
| NIST SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise | May 2023 | Mobile device management concepts (free public source) |
| CISA Known Exploited Vulnerabilities catalogue | Live catalogue | Prioritising patches |
| GDPR (Regulation (EU) 2016/679) | As amended | Example of a privacy law that applies to BYOD device data |

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.