ISO 27001 A.8.1: user endpoint devices and what auditors check

The due-diligence questionnaire asks whether every laptop is encrypted and centrally managed. Your asset register says yes, but nobody has checked the MacBook that joined in March. The auditor's Stage 2 screen-share request is two weeks away.

This guide covers ISO 27001 A.8.1 for security and IT leads at 25–250-person firms. It sets out what the control requires, how to set the endpoint baseline, what auditors sample, and how MDM data turns that evidence into something your tooling produces on its own.

What does ISO 27001 Annex A user endpoint devices require under A.8.1?

ISO 27001 Annex A 8.1 requires you to govern every laptop, phone and tablet that touches company information. That means written handling rules, a registered inventory of devices, technical protections enforced rather than hoped for, and users who understand their responsibilities. The control applies to corporate and personal devices alike.

Four strands make up ISO 27001 endpoint security under this control, and each one maps to something you can evidence:

• Rules. One written set of configuration and handling rules: the data classes a device may hold, permitted software, update expectations and network use off-site.
• Inventory. Every device known and registered, which depends on the asset inventory the rest of your ISMS already needs.
• Enforced protection. Encryption, patching, malware defence and remote wipe switched on by the platform, not requested by email.
• User responsibility. People who know what to do on trains, in cafés and at home.

A.8.1 is a preventive control that touches confidentiality, integrity and availability. A lost unencrypted laptop is a disclosure event. A compromised one corrupts whatever it touches, and a stolen device with no backup takes its data with it.

Endpoints are also where most real incidents start: a phished laptop, a stolen bag, a personal phone with the CRM logged in. At 25–250 people, one unmanaged MacBook is a meaningful share of your attack surface, and a remote-first team has no office perimeter to compensate. Cyber Essentials, enterprise security questionnaires and cyber insurance proposals all ask the same three things. Are disks encrypted, are devices centrally managed, and can you wipe a lost one? "We think so" stalls deals and loads premiums.

How did A.8.1 change from the 2013 controls?

In the 2022 revision, A.8.1 merged two 2013 controls, mobile device policy (A.6.2.1) and unattended user equipment (A.11.2.8), into one endpoint control. BYOD governance, caution in public places and port and media restrictions, previously implied, are now explicit. The result is one control to evidence instead of two.

If your documentation still cites the 2013 revision, you probably have a mobile device policy in one place and an unattended-equipment rule in another. Merge them into a single endpoint document rather than renumbering both. What carries over, and what to add:

• Mobile device policy content. Enrolment, approved devices and wipe rules stay, but extend them from phones to laptops and tablets.
• Unattended equipment rules. Screen-lock behaviour now ships as an MDM profile instead of a reminder in the staff handbook.
• The newly explicit themes. BYOD governance, public-place caution and port and media restrictions each need a visible home in the document.

Where a 2013-era policy is silent on personal devices or removable media, those are the paragraphs to add. The rest usually carries over unchanged, so this is an edit and not a rewrite.

What is the technical baseline every endpoint must meet?

Every endpoint needs three things, on every operating system: full-disk encryption, endpoint detection and response (EDR), and centrally managed patching. Everything else is negotiable by risk; these three are not. Enrolment in an MDM platform such as Intune or Jamf turns the baseline from policy into enforcement.

Endpoint management under this control starts with enrolment, because a baseline profile arrives with the device instead of depending on the user. For a 50-person fleet, the profile enforces:

• Disk encryption on by default, BitLocker on Windows and FileVault on macOS, with recovery keys escrowed centrally.
• Automatic OS and application updates, with a deadline for installing them.
• Screen-lock timers, which also cover the unattended-equipment half of the control.
• EDR present and reporting, the modern successor to antivirus.

On Windows, hardware-backed encryption is the target. The NCSC Device Security Guidance on Windows Platform Protection recommends full disk encryption using a Trusted Platform Module with a PIN, which reduces the risk of data extraction through physical attacks. Escrowed recovery keys stop that protection becoming your own outage when someone forgets a PIN or a leaver's laptop comes back locked.

Buyers and insurers ask about the same baseline. The NCSC Cyber Essentials Technical Controls Overview lists secure configuration, security update management and malware protection among its five technical controls. Those are the strands the profile above enforces, so one set of MDM settings answers both audiences.

The common failure is assumption. Teams record encryption as done because the operating system supports it, then never read the status back from the console. Verify per device, from the MDM, and treat any "unknown" as non-compliant until proven otherwise.

"Macs encrypt by default" is not evidence. The one machine that opted out is always the one that goes missing.

How should you govern BYOD and personal devices under UK GDPR?

Allow personal devices only if you can manage the risk: a work profile or container separating business from personal data, a signed agreement covering selective wipe of company data, and verified encryption. If you can't do all three, block access to company data or issue company hardware. UK GDPR makes the privacy half a legal duty, not a courtesy.

Each condition needs a concrete artefact an auditor can ask to see:

• Work profile or container. Business apps and data sit in a managed space the company can remove without touching personal photos or messages.
• Signed agreement. It records the company's right to wipe its own data selectively and settles privacy and intellectual-property questions before a dispute, not after.
• Verified encryption. The MDM reports it per device, because the user's assurance is not a record.

The ICO guidance on Bring Your Own Device (BYOD) security states the principle. The owner's data and the organisation's data should stay separate, and staff shouldn't be able to move company data into their personal storage. A container meets that technically. The agreement meets it legally.

There is a stronger option for your most sensitive data. Decide whether it may be stored on devices at all, or only accessed from them. SaaS-first estates can often disable offline copies entirely, which shrinks the loss scenario to a credential problem.

Where data does have to live on the device, back it up centrally and test a restore. Endpoint backups running over home broadband can fail silently, and the gap shows only when someone needs the file back.

The usual failure is BYOD by default: personal devices reaching company data with no container, no agreement and no wipe capability. It stays invisible until a departure turns hostile.

A BYOD policy with no right to wipe company data is a hope, not a control.

Should standard users keep local admin rights and USB storage?

No. Standard users should not hold local administrator rights, because removing them closes the unauthorised-software route and is one of the highest-value single changes at this scale. Removable storage should be denied by default with a documented exception route. USB-C ports stay enabled, since they carry power and displays; the control targets storage access.

Removing admin also stops malware persisting on a machine once something does get through. Pair the change with an approved-software catalogue pushed from the MDM, so people rarely need elevation in the first place. Few notice the change when the tools they use daily are already installed.

Removable media works best as three rules:

• Default-deny storage. Block mass-storage devices on every endpoint, leaving charging and display connections alone.
• Documented exception route. A named approver, a stated reason, an expiry date and a log entry.
• Evidence by profile. The configuration profile itself shows the restriction, which is what the auditor asks to see.

Two pitfalls pull in opposite directions. Keeping admin rights because removal felt like friction quietly undoes the software and malware defences. Locking down USB and installs too hard pushes engineers onto personal devices, building the shadow estate the control exists to prevent. An exception route fast enough to use fixes both: if engineers can get an approved tool or a temporary elevation the same day, they have no reason to route around you.

How do auditors test ISO 27001 A.8.1 and grade findings?

Auditors reconcile the asset register against the MDM console, then spot-check live compliance on two or three staff devices, often by screen-share, and trace a recent leaver. Unencrypted laptops or no central management usually grade major; a few unenrolled devices or one missing BYOD agreement grade minor, adding up to major if patterned.

Expect these questions in the room:

• "Show me every device that can reach company data, corporate and personal. How do you know the list is complete?"
• "Pick a laptop from the inventory. Prove it is encrypted and patched right now, not at the last report."
• "Do your users have admin rights? Who can install software?"
• "Someone leaves a laptop on a train this afternoon. Walk me through what happens."
• "How is company data separated from personal data on that phone?"

Each question has an evidence answer you can prepare in advance:

• Inventory and enrolment: the device register reconciled against MDM enrolment, the auditor's first check.
• Live status: an MDM compliance dashboard covering encryption, patching and EDR, rather than a stale export.
• Configuration: profiles showing screen-lock, admin removal and removable-media restrictions, plus escrowed key records.
• Leavers: offboarding records tying leaver dates to access revocation, device return and wipe confirmation.
• People and paper: the endpoint and BYOD policy set, signed agreements and awareness training records.

The BYOD test is often personal. The auditor may pick a specific employee and ask how work data sits on their own phone. The answer has to be one the employee can give without notes.

Grading follows certification-body practice, not the wording of the control. The line runs between absence and lapse.

No encryption, or no way to wipe a lost device, means the requirement is missing and grades major. A stale inventory entry or one unsigned BYOD agreement is a lapse in a control that otherwise works, and grades minor. Lapses that repeat across the sample add up to a major, because they show a control that isn't operating.

How do you automate A.8.1 evidence with MDM and IdP data?

Treat the MDM platform as a continuous-monitoring engine. Its compliance API feeds a live dashboard of encryption, patch and EDR status, and drift opens a ticket the day it happens. A scheduled job diffs IdP, MDM and asset register, and HR leaver events trigger revocation and wipe tasks with timestamps captured automatically.

The audit artefact becomes an export of what is already running, not a quarterly screenshot hunt. When the auditor asks how you know the device list is complete, the answer is the diff history: every unenrolled device flagged, ticketed, given an owner and closed.

An asset register kept by hand is a record of what you once bought, not what is connected today.

People still decide the hard cases, such as whether an exception is justified or whether a lost device is a reportable breach. Automation handles detection and record-keeping, and the human layer keeps judgement. Endpoint data is API-rich and high-yield, which is why this is core evidence-automation work in our GRC engineering builds.

What does an A.8.1 rollout look like for a 50-person firm?

With a cloud identity provider already in place, standing up MDM with the baseline profile takes one to two weeks, plus a few weeks chasing stragglers into enrolment. Start early: it depends on the asset inventory, feeds nearly every later technological control, and the reports it generates become standing audit evidence.

A workable order:

1. Confirm the inventory that enrolment will be reconciled against.
2. Enrol and apply the baseline profile, company hardware first, then chase the stragglers.
3. Write the single endpoint document, with BYOD folded in rather than ignored.
4. Name owners for lost or stolen devices: who to call, who triggers the wipe, who judges whether it is a reportable breach, all wired into offboarding.
5. Add the human layer to induction and annual awareness: lock the screen, never leave the laptop in the car, use a privacy filter on client data in public.

Some decisions are governance calls: what is allowed, what is managed and where the privacy line sits. A fractional CISO can own those and defend them at audit. Once the dashboards run, the same reports serve ISO 27001 audits, Cyber Essentials, customer questionnaires and cyber insurers, so one rollout answers four requests.

Frequently asked questions