A.8.1 User endpoint devices: requirements and evidence

What A.8.1 user endpoint devices requires in ISO 27001

A.8.1 User endpoint devices asks that information stored on, processed by or accessible through user endpoint devices is protected. For a compliance lead or engineer, the practical question is which laptops, phones and other devices fall under that wording, and what evidence shows each one is in the protected state. In the 2022 edition the control sits in the technological controls theme (clause 8 of Annex A), and it merges two controls from the 2013 edition: A.6.2.1 Mobile device policy and A.11.2.8 Unattended user equipment. The merge makes A.8.1 broader than either predecessor. It covers the device as a whole, including what happens when it is left unattended, lost, stolen or used off-premises, not only a policy for mobile devices. ISO/IEC 27002:2022 gives guidance on how to implement the control, but the guidance itself cannot be certified. Your certification body will test your controls against the requirements and your own documented approach.

The control is hard to meet for three reasons. First, most organizations do not hold a complete, current inventory of the devices that touch their information, especially when staff use personal phones for email or chat. Second, personal devices bring a boundary problem: you need a documented rule for what may be accessed from them, what the organization can enforce, and what it cannot. Third, proving the state of each device over time is harder than setting a policy once. An auditor will usually ask for evidence that devices were enrolled, encrypted, screen-locked and patched during the audit period, not only on the day the policy was written. Start by confirming the scope of your Statement of Applicability, listing every device class in scope, and deciding which evidence source covers each class.

Self-hosted open-source tools can produce much of this evidence inside your own infrastructure. osquery exposes device state as SQL tables and its osqueryd daemon can run scheduled queries across a fleet. Fleet policies, built on osquery, ask yes or no questions of devices and show which devices pass or fail each policy, which gives a dated record of compliance. Wazuh Security Configuration Assessment checks endpoints against YAML policies, mostly based on CIS benchmarks, and recommends remediation. Velociraptor can collect artifacts from offline machines when they reconnect, which helps with investigations of lost or unmanaged devices. Confirm with each vendor which platforms and device types each tool supports before you rely on it, because coverage for phones is not the same as coverage for laptops. Your own mobile device management or endpoint tooling may also be needed for remote wipe, which these tools do not replace.

Which devices, data and teams fall under A.8.1 scope

Scope for A.8.1 is set by three questions: which devices can reach company information, what information those devices can reach, and which teams own the rules that govern them. The organization makes these decisions itself, and the Statement of Applicability should record how it reached them, because every later control choice depends on this boundary.

Company-owned laptops and desktops

These are the simplest devices to bring into scope because the organization controls their purchase, build and disk configuration. Confirm which models, operating systems and locations are in the inventory, and whether home-office machines and loaned equipment are tracked. Each device should have a named owner, a recorded encryption status and a known build image. A device that is not in the asset register is hard to show as protected during an assessment, so inventory completeness is the first thing an assessor will test.

Phones and tablets under BYOD

Bring-your-own-device programs bring personal phones into scope whenever they can open email, chat, file shares or admin consoles. Decide whether personal devices are enrolled in mobile device management, enrolled with a work profile only, or excluded from company data entirely. Each choice produces different evidence, so the policy and the enrollment settings must match. Check how the organization can remove only company data on a personal device without wiping personal content.

Contractor and third-party devices

Contractors, auditors and vendor staff often connect their own laptops to company email, source code or ticketing systems. If those devices reach company information, they fall within the endpoint decision even though the organization does not own them. Define the minimum conditions a device must meet before access, such as disk encryption and an endpoint agent, and decide whether access is limited to a virtual desktop. Supplier terms should record these conditions.

Servers and shared kiosks

Servers are usually covered by other technological controls, but shared kiosks, warehouse terminals and conference room devices can behave like endpoints. Decide case by case whether a device is a user endpoint or infrastructure, and record the reason. A shared device that stores session tokens or lets several people sign in needs its own rules for lock, logout and clearing local data. Ambiguous devices left outside scope are a common finding, so write the boundary down explicitly.

Data reachable from each device

Scope also depends on what a device can reach, not only on the device itself. Map which systems each device class can open, such as email, source code repositories, customer records, financial reports or production consoles. A device that reaches customer records carries more risk than one limited to a public wiki, and the controls should scale to match. Record this mapping in the asset inventory so that the access model and the endpoint requirements can be checked against the same list.

Teams that own the device rules

A.8.1 touches several teams. IT typically runs enrollment and configuration, security sets the baseline and reviews exceptions, and HR triggers device return and account removal at offboarding. Whoever owns the device policy must also approve BYOD terms and exceptions. Name these owners in the policy and in the Statement of Applicability so that an assessor can trace each requirement to a responsible role. Unclear ownership usually shows up as devices that are never collected when staff leave.

How an assessor tests A.8.1 for endpoint devices

This table sets out how an assessor typically tests A.8.1, what evidence they ask for in each test, and where organizations most often fall short. Read each row as a test the organization should rehearse before the audit, not as a checklist the assessor will accept on its own. The main takeaway is that a written policy only counts when inventory, configuration and offboarding records show it is applied to real devices.

Test area	Evidence requested	Common findings
Endpoint and mobile device policy	Approved policy version, approval record, owner, review date and the link between the policy and the wider access control policy	Policy exists but is outdated, unapproved or does not name the devices it covers
Device inventory reconciliation	Device register compared with directory accounts and HR joiner, mover and leaver records	Inventory is incomplete, lacks owners, or includes devices no one can match to a person
Sampling of enrolled devices	Configuration output for a sample of devices showing disk encryption, screen lock timeout and operating system patch level	Devices enrolled but never checked against the policy, or checks run once and not repeated
Remote wipe capability	Demonstration or logged test of wipe on a sample device, with records of who can trigger it and when	No evidence that wipe has ever been tested, or wipe is available only to a single administrator
Offboarding actions for devices	Leaver tickets showing device return, account revocation and wipe or retirement dates	Accounts disabled but devices still hold data, or no record linking a leaver to a device
Personal device rules	Bring-your-own-device terms, enrollment records, containerization or separation settings and acknowledgments from users	Personal devices reach corporate data with no agreed terms or no enrollment record
Unattended equipment handling	Clear screen and clear desk rules, automatic lock settings, and records of awareness or spot checks	Rules exist on paper, but spot checks and lock settings are never recorded
Mapping to NIST controls	The NIST crosswalk relates A.8.1 to AC-11 (Device Lock) and AC-19 (Access Control for Mobile Devices), so the organization's own evidence for those device controls can be reused	Crosswalk cited as proof of compliance; NIST cautions that mapped controls are not always equivalent, so assessors test the organization's own implementation

Implementing A.8.1 endpoint controls in order

This sequence moves from deciding which devices and data are in scope to a working loop that enrolls devices, checks them against policy and proves that lost or retired devices can be wiped. Each step closes with an artifact an assessor can read, so the ISMS can show the control operating rather than only existing on paper.

Define the device and data scope
Start by listing which kinds of endpoints are in scope: company laptops, desktops, phones, tablets and any personal devices allowed to reach company email, files or applications. Then identify the information each device class can reach, such as source code, customer records or administrative consoles. The information owner and the IT lead should sign off together. The output is a short scope statement that names device classes, data classes and the systems they touch, and it feeds the Statement of Applicability and the asset register.
Write the endpoint and mobile policy
Draft or update the mobile device and endpoint policy so it covers company-owned and personal (bring-your-own) devices, acceptable use, reporting of lost or stolen devices, and the rules for leaving equipment unattended in offices, homes and public places. Legal and HR should review the personal device terms, especially where monitoring or remote wipe applies to a private phone. Leadership approves the policy, and staff acknowledge it. The output is an approved, versioned policy with a record of who acknowledged it.
Build and reconcile the device inventory
Compile every endpoint from directory records, mobile device management consoles, procurement records and, where possible, agent check-ins from osquery or a similar tool. Compare these sources and resolve gaps: devices that report but are not registered, registered devices that have not checked in, and personal devices that were approved but never enrolled. Assign an owner and a status to each device. The output is a reconciled inventory with a documented exception list, which is the evidence that the organization knows what it must protect.
Set the baseline configuration standard
Write a baseline for each device class covering disk encryption, screen lock and idle timeout, operating system and browser currency, host firewall, endpoint protection, and restrictions on local administrator rights. Where a recognized benchmark exists for the operating system, use it as a reference and confirm the exact settings against the vendor documentation for your versions. Security engineering and IT operations agree the standard. The output is a baseline document with a setting, a purpose and a test for each item, which later becomes the policy the fleet is checked against.
Enroll devices and enforce policy checks
Enroll each device in the management platform so the baseline can be applied and measured. Turn the baseline items into yes or no checks that run on a schedule, for example whether disk encryption is on, whether a screen lock is set and whether the OS is supported. Tools such as Fleet and Wazuh can express these as queries or assessment policies that report which devices pass or fail. Set the rules for blocking access from non-compliant devices to sensitive applications. The output is a compliance report by device, plus a record of enforcement actions taken on failing devices.
Run exception handling, offboarding and wipe tests
Operate the control as a recurring loop. Route each failing check to a named owner with a deadline set in your own policy, and record any accepted exception with a reason, an approver and a review date. When someone leaves or a device is lost, remove access, retrieve or wipe the device and update the inventory. Test remote wipe periodically on a spare or test device, and retain the ticket, the wipe log and the inventory change as evidence. The output is a tested wipe record and a dated exception register, which show that the control works in practice.

Evidence that passes A.8.1 and how to keep it current

An assessor testing A.8.1 starts from a sample of individual devices and works outward to the rules that govern them. The six artifacts below are linked by that trace: each device record should point to a policy version, a compliance result, and any approved exception or wipe event that touches it.

Approved endpoint and mobile device policy

This is the written rule set for corporate and personal devices: enrollment, minimum encryption, screen lock, patching, remote wipe and reporting of lost devices. Keep every approved version with its approver, approval date and the changes made from the previous version. Between audits, store the current policy in a version-controlled repository and export a dated copy each quarter, so the version in force on any sample date can be shown. Check that the policy names the controls the technical checks actually enforce.

Device inventory reconciled to directory records

The inventory lists every laptop and phone that can reach company information, with owner, device type, operating system and enrollment status. Reconcile it against the identity directory and HR records to catch devices owned by leavers, contractors or unknown users. Schedule the reconciliation as a recurring export with a timestamp and record the exceptions it finds and how each was closed. An auditor who picks a device from the inventory will expect to see it appear in the directory and be linked to a named person.

Per-device compliance results

For each device, record the state of disk encryption, screen lock, operating system patch level and endpoint protection at a known point in time. Osquery can run these checks as scheduled queries across a fleet, and Fleet policies show which devices pass or fail each policy. Keep the timestamped results rather than a summary screenshot, and retain failing results with the remediation ticket that followed. This is the artifact that connects a sampled device to the policy it was tested against.

Remote wipe and offboarding records

Each remote wipe or device retirement needs a record with the device identifier, the trigger (loss, theft, termination or role change), the date and time, and the operator who issued the command. Confirm that the wipe completed by checking the device's final reported state, not only the command log. Keep these records as an event log exported on a schedule. Ask whether your mobile management tooling can produce this trail with operator identity, since an auditor will ask who could issue a wipe and whether that use was logged.

Exception register with approvals and expiry

Some devices will fail a requirement for a documented reason, such as a legacy operating system used by a specialist tool. Each exception needs a business justification, a compensating control, the named approver, and an expiry date. Review the register on a fixed cadence and close expired entries or renew them with fresh approval. An expired exception that is still active on a device is a common finding, so reconcile the register against live compliance results at each review.

Training and acknowledgment for personal device rules

Where staff use personal phones or laptops for work, they should acknowledge the device rules before access is granted and again when the policy changes. Keep signed or electronically recorded acknowledgments with the policy version each person accepted, and track completion against the directory so new joiners and contractors are covered. Confirm that the acknowledgment list matches the set of people with enrolled personal devices, because gaps between those two lists are easy for a sampling auditor to find.

Open-source tools that produce A.8.1 endpoint evidence

osquery exposes operating system state on an endpoint as SQL tables, so an operator can ask the same question of every laptop and server in the same way. For A.8.1, that helps show what is actually running on user devices, which kernel modules are loaded, where connections go and which browser extensions are installed. Its osqueryd daemon runs scheduled queries across a fleet of hosts and can return results to a central place for review.

Process and module visibility: Tables for running processes and loaded kernel modules let a team check whether endpoints match what the device policy describes.
Network and browser state: Open network connections and browser plugins show exposure that a policy document alone will not reveal.
Hardware and file hashes: Hardware events and file hashes support checks on removable media use and on the integrity of specific files.
Scheduled collection: The osqueryd daemon runs queries on a schedule, which produces repeated records over time rather than a single snapshot.
License: osquery is licensed under Apache-2.0 OR GPL-2.0-only, so the organization should confirm which license terms fit its distribution and internal use.

osquery produces the raw data. Ask your team to confirm which tables are available on each operating system in your fleet and how long query results are retained.

What meeting A.8.1 costs in money and effort

This table breaks down the cost components of meeting A.8.1 for user endpoint devices, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to keep it down. No prices or durations are given because none are supplied, so use the drivers and the quote checklist below to compare written scopes.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling and licenses	Recurring	Open-source agents such as osquery, Fleet, Wazuh and Velociraptor carry no license fee under their own terms, but hosting, storage, MDM licensing and any commercial endpoint tools still cost money	Self-host inside your own cloud or data center, right-size storage for query results, and confirm each vendor's licensing terms in writing
Engineering time to deploy and baseline devices	One-time, with recurring updates	Number of operating systems, device enrollment method, and how many configuration baselines must be built	Standardize on fewer OS builds, reuse one policy set across fleets, and document the baseline as code
Policy and inventory work	One-time, with periodic review	Size and accuracy of the device register, number of personal device arrangements, and how many roles need different rules	Start from one maintained asset source, limit personal device rules to defined cases, and assign a named owner for each policy
Evidence upkeep	Recurring	How often evidence is refreshed, how many checks run per device, and how many reports the assessor samples	Schedule automated policy queries and export dated results, so evidence is collected continuously rather than rebuilt before each audit
Exception handling and offboarding operations	Recurring	Volume of device exceptions, personal device loss or theft, and staff turnover across geographic sites	Use a written exception register with expiry dates, and automate remote wipe and access removal triggered by the HR leaver process
External testing or review of the configuration	Recurring or per engagement	Scope of the review, number of device types tested, and whether the review covers remote and personal devices	Fix scope in writing before work starts, reuse internal test results, and limit external review to the highest-risk device groups
Auditor sampling time billed by the certification body	Recurring, tied to the audit cycle	Number of sites, devices sampled, and nonconformities raised during audit	Prepare a clean evidence set in advance, fix scope early, and confirm the certification body's fee basis before signing

Who does what for A.8.1: your team, a partner and the auditor

Your organization owns A.8.1. That means the mobile and endpoint policy, the decisions about which risks are acceptable, the approval of any exception to the rules, the Statement of Applicability entry that explains how the control is applied, and the daily operation of endpoint controls. No partner or auditor can take these over, because the certification is about your management system working in practice.

Policy and risk decisions: Set the rules for company-owned and personal devices, including enrollment, encryption, screen lock, remote wipe and acceptable use, and decide how much residual risk you accept.
Exception ownership: Approve, time-limit and review any device that falls outside the standard, such as an older operating system or a contractor laptop.
Statement of Applicability entry: Write and maintain the justification for A.8.1, linking it to the policy, the risk treatment and the evidence location.
Daily operation: Review failing device checks, chase owners to remediate, and decide when a non-compliant device is blocked from company data.

Before any assessment, confirm that a named person can explain every endpoint decision and show the records behind it.

Where organizations fall short on A.8.1 and how to close each gap

Most A.8.1 findings come from the same few weaknesses: a device list nobody trusts, personal devices outside any rule, and controls that exist on paper only. Each card below names one gap, what an assessor typically finds, and a practical way to close it before the audit.

No reconciled device inventory

Organizations often hold one device list in the MDM console, another in the asset register and a third in the directory, and none of them agree. An assessor will sample devices and ask how each one was enrolled and who holds it. Reconcile the inventory against directory and HR records monthly, flag devices with no assigned owner, and retire records for leavers. Ask who owns the list and how often it is compared.

Personal devices outside any rule

Staff reading company email on personal phones is common, and many policies never address it. Under A.8.1 the organization must still protect information on those devices. Require enrollment or an approved container before any device can reach company data, and set out what the organization can wipe. Confirm that the mobile device policy covers contractors and unmanaged browsers, not only corporate laptops.

Policies that no one checks

A device policy listing encryption, screen locks and patch levels proves little if no record shows the settings are in place. Assessors look for evidence that each requirement is measured on real devices. Use osquery or Fleet to run scheduled queries for disk encryption, screen lock and OS version, then keep the results. A policy without a recurring check is an untested claim.

Remote wipe never tested

Many teams have a wipe command in their MDM but have never confirmed it works on a real device. A failed wipe during a lost-laptop incident is a serious finding. Run a wipe test on a spare device each quarter, record the date, the operator, the device state before and after, and any fault. Confirm whether the wipe reaches devices that are offline or in a backup state.

Unattended equipment rules on paper only

A clear-desk rule and an automatic screen lock are easy to write and hard to verify. Assessors will ask how the lock timeout is enforced and whether they can see evidence from devices. Push the lock setting through MDM, check it with a scheduled query, and include unattended devices in spot checks of office and home workspaces. Keep the check results alongside the policy.

Exceptions that never expire

Temporary exemptions for older operating systems or unmanaged devices often outlive the project that required them. Each exception then becomes a standing gap that no one reviews. Record every exception with an owner, a documented risk acceptance and a fixed expiry date, then review the register at each management review. Illustratively, an exception granted for a migration should lapse when the migration closes, not on a calendar that nobody watches.

Questions buyers ask about A.8.1 cost, effort and outside help

How much effort does A.8.1 take for a team with a few hundred devices?

The effort is driven less by the device count than by how many device types, operating systems and ownership models you run. Effort rises with the number of corporate and personal (bring-your-own) devices, the number of operating systems, how many devices are outside the office at any time, and whether device inventory already exists. Initial work covers a device register, a written endpoint policy, baseline hardening, encryption checks and a tested remote wipe procedure. Ongoing work is mostly exception handling, new-hire enrolment, offboarding and periodic review. Ask any partner to break the quote into these components so you can see what is one-time and what recurs.

Can a small team run A.8.1 itself with open-source tools?

Often yes, if one or two people own the work and the tooling is kept simple. Osquery can answer device-state questions across a fleet, Fleet policies show which devices pass or fail each yes-or-no check, and Wazuh can assess endpoint configuration against policies. Velociraptor is useful when you need to investigate a specific device. The harder part is not the software but the discipline of acting on failing results, keeping the inventory current and documenting exceptions. Self-hosting also means someone must patch and back up the tooling itself, so confirm that capacity before you commit.

What does A.8.1 need from device owners, HR and the policy owner?

A.8.1 cannot be met by IT alone, because it depends on people outside the technology team. Device owners must enrol devices, keep operating systems current and report loss or theft promptly. HR must trigger timely offboarding so that access and device returns are handled on the day an employee leaves. The organization should also name one accountable policy owner who approves the endpoint rules, reviews exceptions and answers the auditor's questions. Write these responsibilities into the policy and the job descriptions so the evidence survives staff changes.

Can A.8.1 be certified on its own?

No. A.8.1 is one of 93 Annex A controls, and it is assessed as part of an information security management system (ISMS) certification. Your organization defines the scope of the ISMS, and an accredited certification body audits whether the controls in that scope are implemented and operating. Your Statement of Applicability records how A.8.1 applies to you, including any justified exclusions. Plan your evidence around the whole ISMS rather than treating this control as a standalone project.

Can an implementation partner certify our endpoint controls?

No. An implementation partner can prepare systems, configuration, documentation and evidence, but only an independent accredited certification body can issue a certificate. DeployOpen follows this same division: it plans, implements and documents controls inside your infrastructure and prepares evidence, but it does not issue audit reports, attestations or certifications. Before engaging anyone, confirm in writing which tasks are theirs, which remain yours, and that the auditor will be independent of the firm doing the preparation.

How do self-hosted tools change our license spend?

Self-hosted open-source tools generally remove per-seat fees for the monitoring and query software itself, so the spend shifts from licenses to infrastructure, staff time and support. Osquery, Fleet, Wazuh and Velociraptor carry open-source licenses with different terms, so have counsel confirm the license obligations for your use case. Recurring costs include hosting, storage for logs and results, maintenance and any retainer for upgrades. Ask any partner to show these recurring costs alongside one-time setup costs in the quote.

How does A.8.1 relate to A.8.7 malware protection and A.6.7 remote working?

A.8.1 covers the endpoint itself, its registration, configuration, encryption, wipe and personal-device rules. A.8.7 covers protection against malware, which includes detection and repair software and handling infections, so the two controls share evidence such as endpoint protection status. A.6.7 covers remote working, which determines where endpoints operate and what protections apply off-premises. An assessor will often expect these controls to be consistent with one another, so write a single endpoint policy that references them and check that the same device inventory feeds all three.

How DeployOpen scopes and prepares A.8.1 endpoint evidence

DeployOpen works on A.8.1 User endpoint devices by implementing the endpoint tooling inside your own infrastructure and preparing the evidence an assessor will ask for. The organization owns its controls and its policy decisions, while DeployOpen prepares systems, configurations and documentation for review by your independent auditor or certification body.

How we scope

Agree in writing which device types, operating systems and ownership models fall inside the A.8.1 boundary, including personal devices.
Confirm which user endpoint policies, encryption settings and remote wipe requirements your organization has already approved.
Record which controls A.8.1 shares with A.6.7 Remote working, A.7.9 Security of assets off-premises and A.8.7 Protection against malware.

How we build

Deploy self-hosted osquery and Fleet to answer device posture questions such as disk encryption and screen lock as policies.
Configure Wazuh Security Configuration Assessment policies to check endpoint settings against the benchmarks your organization selects.
Test policy results against sample devices so that pass and fail states are reliable before they are cited as evidence.

How we hand over

Deliver the written scope, configuration baselines, policy definitions and a record of how each query or check maps to the endpoint requirement.
Provide exported policy pass and fail reports, with dated snapshots that show the state of devices over time.
Document the operating procedures your staff need to answer exceptions, handle lost devices and respond to failing devices.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, and a quote follows from the written scope.
Ask your auditor early which evidence format they accept, since they decide whether the evidence is sufficient.