ISO 27001 Annex A 7.9: security of assets off-premises

The due-diligence questionnaire asks how your remote laptops are encrypted, tracked and wiped. Your honest answer is a policy paragraph and a hope. ISO 27001 Annex A 7.9 is the control behind that question, and this guide shows hybrid UK firms of 25–250 people how to meet it without per-trip sign-out forms. It covers what the control owns, how MDM evidences it, custody when hardware changes hands, what auditors sample and how to automate the proof.

What does ISO 27001 Annex A 7.9 require, and how does it differ from A.6.7 and A.8.1?

ISO 27001 Annex A 7.9 asks you to protect assets that store or process company information outside your premises, so each one is authorised, hardened, trackable and recoverable. It covers physical handling and custody. Annex A 6.7 sets the rules for remote working, and Annex A 8.1 governs endpoint configuration hardening. Together the three controls form one triangle.

Think of this as the physical-security face of ISO 27001 security of assets off-premises. Once a laptop leaves the office, the building's locks and cameras stop protecting it, so the protection has to travel with the device. Management approves the device leaving, you harden it for cafés, trains and spare bedrooms, and you keep it recoverable if it goes missing.

The three controls split the work like this:

• A.7.9, handling and custody: authorisation, encryption, tracking, remote wipe and the custody trail when a device changes hands.
• A.6.7, remote working: the rules for how, where and on what terms people work away from the office.
• A.8.1, endpoint hardening: the technical configuration of the devices themselves.

Personal devices doing company work are in scope too. Permanently installed off-site kit, such as an antenna or a kiosk, carries heavier expectations of its own.

The control is preventive, and it touches all three security properties. Confidentiality is at stake when a stranger reads the disk or the screen. Integrity is at stake when someone tampers with a device out of your custody, and availability when the device and its data are simply gone. You also cannot authorise or track a device that is missing from the asset inventory in A.5.9, so that register comes first.

Why does off-premises asset security decide whether a lost laptop becomes a reportable breach?

Because encryption and remote wipe decide what a loss costs. If the device is encrypted and can be wiped, a loss is an operational inconvenience; if it is unencrypted, it becomes disclosure and regulatory attention. The ICO notes encryption is especially effective when the device storing the data is lost or stolen.

For a hybrid firm, off-premises kit is not an edge case. It is where most of the estate lives most of the week. When a laptop goes missing, whether the loss ends as a logged incident or a client-notifying breach comes down to whether this control was real.

The ICO guidance on encryption and data storage goes a step further: an effective encryption solution can also help demonstrate that you meet the security requirements of UK data protection law. That is the argument you want on file before a loss, not assembled afterwards.

The commercial cost arrives more quietly. Enterprise security reviews now ask directly how remote kit is encrypted, tracked and wiped. An unencrypted loss leaves an awkward paragraph in every renewal questionnaire that follows, and a thin answer reads as a firm that has not noticed its own working model.

Do you need a signed authorisation form every time a laptop leaves the building?

No. Issuing a laptop is the approval for it to leave the building, so record that authorisation in the asset register at handover. Reserve explicit sign-off for unusual cases: servers, bulk media and kit travelling to high-risk destinations. Per-trip forms for a workforce that leaves daily add ceremony without adding control.

In practice the asset register does the work. At handover, record who received which device, on what date, and that they have accepted the acceptable use terms. That entry is the approval, and it answers the auditor's question "who approved this device leaving, and where is that recorded?" in a single lookup.

Over-engineering is the pitfall here: per-trip forms produce a pile of paper nobody reads and a register that disagrees with it. For the genuine exceptions, keep a short approval record that names the approver, the asset, the destination and the return date. That is where a signature actually changes what happens.

How do you enforce the technical baseline on remote devices with MDM?

Enrol every device in mobile device management (MDM) before handover and enforce full disk encryption, screen lock, location tracking, remote wipe and current patches. No tool is named in the control, but MDM is the only credible way to evidence these across a fleet. Any personal device touching company data enrols or stays out.

The NCSC makes the case in two places. NCSC guidance on Mobile Device Management stresses high responsiveness where policies must be applied rapidly, such as wiping a lost or stolen device. NCSC guidance on erasing devices confirms that an enrolled device can be sent a remote wipe command over a network connection.

Enforce these settings at enrolment rather than asking staff to apply them:

• Full disk encryption switched on and reported as compliant.
• Screen lock after a short idle timeout.
• Location tracking and remote wipe enabled.
• Patches current, with non-compliant devices flagged.

The alternative to MDM is a manual attestation trail, with staff confirming their own settings. Auditors rightly distrust it, because it records what people believe about their devices rather than what the devices report.

A remote wipe you have never run is a control you don't have.

The usual failure is a wipe configured on faith and first attempted during a real incident, against a device that is offline. Rehearse it instead:

1. Wipe a spare device from the console, never a live one.
2. Confirm the erase completed and note how long it took.
3. Try an offline device and record what happens until it reconnects.
4. Keep the record as audit evidence.

The offline result matters most. A wipe command needs a network connection to land, so credential rotation cannot wait for it.

What travel and public-space habits actually prevent off-premises incidents?

A handful of habits prevent most incidents: keep the device with you or locked away, use a privacy filter on trains, take sensitive calls in private spaces, and report any loss the same day without blame. Fast reporting matters most because wipe, credential rotation and access revocation all depend on it.

The physical habits are simple enough to fit on one slide:

• Hotel: use the room safe.
• Car: keep the device out of sight, and never on the back seat.
• Train: a privacy filter stops the whole carriage reading the screen, and the luggage rack is the wrong place for a laptop bag.
• Calls: keep sensitive conversations for private spaces.

The reporting window is where the control succeeds or fails. People who fear a telling-off wait until Monday, and by then the window for wiping the device and rotating credentials has narrowed. Publish one reporting route that works out of hours, so a theft on a Friday night reaches someone who can act that night.

The lost laptop was never the breach. The slow report was.

Training is the other common gap. Awareness sessions often cover phishing in depth and never mention the physical side, so nobody has been told that the screen angled at the whole carriage is a disclosure. Add the travel and public-space habits to your awareness material and keep completion records.

How do you keep a chain of custody when hardware changes hands?

Log who held a device, who holds it now and what the next holder must not inherit. Apply that to contractor returns, leaver handbacks and repairs, scrubbing data before kit moves on. Permanently sited equipment such as ATMs, antennas and warehouse IoT needs a different model: treat each site as a miniature perimeter.

Three handovers cause most of the blind spots:

• Contractor return: log the date the kit came back, who received it, and scrub it before it is reissued.
• Leaver handback: record the return against the register and confirm what the device held before it moves to the next person.
• Repair: record who sent it, who had it and when it came back, and sanitise anything the next holder should not see.

Contractors and leavers are the classic custody gap. Kit comes back late or not at all, and nobody logs the handover, so the register still shows a device with someone who left months ago. Tying the return task to the HR leaver event closes that gap, as the automation section below shows.

Permanently sited equipment needs more than a register entry, because nobody carries it home and nobody sees it daily. Treat each site as a miniature perimeter with four layers:

• Monitoring of the site and the device.
• Tamper protection.
• Environmental cover.
• Locked-down logical access.

Most 25–250-person firms never meet this case. If yours does, scope it separately from laptops rather than stretching the laptop rules over it.

What do ISO 27001 auditors sample for A.7.9, and how do they grade gaps?

Auditors pick two or three remote workers and trace their devices from the asset register to the live MDM console, then check custody records and interview staff on loss response. Unencrypted devices in circulation or no remote wipe capability grade major; a device missing from MDM, a custody log gap or an untested wipe grades minor.

That grading reflects certification-body practice rather than wording in the control. The majors are absence-of-requirement findings in a firm that works remotely. Single lapses are minors, and they aggregate to a major when they form a pattern.

Expect the sample to run in this order:

1. Pick two or three people who work remotely.
2. Trace each person's devices from the register to the MDM console: enrolment, encryption and last check-in.
3. Request the custody records behind a returned or transferred device.
4. Interview staff on what they would do with a lost phone, testing whether the reporting window is known and not just written.

The questions are blunt. Auditors ask you to talk through a laptop stolen from a car on a Friday night, to show rather than tell that every device is encrypted, and whether you have ever performed a remote wipe. Only the last needs evidence you had to create in advance.

Each question has an exhibit ready:

• Policy: the remote working or mobile device policy, plus signed acceptable-use acknowledgements covering off-site use.
• MDM console: live or exported enrolment, encryption and patch posture. This one screen answers half the auditor's questions.
• Asset register: issue and return records that form the custody trail.
• Wipe proof: a test record, or a real incident where the wipe was executed.
• Incident records: the lost-device procedure and any actual reports with the response.
• Awareness records: travel and public-space material with completion records.

Privacy filters, cable locks and padded cases issued to staff add physical corroboration. They never replace the console evidence.

How do you automate A.7.9 evidence so the audit sample becomes a lookup?

Diff the asset register, identity provider and MDM console on a schedule, so unenrolled or unencrypted devices surface the week they appear. Export MDM posture into the evidence store, raise custody tasks from HR events, and run loss response as a tracked workflow. The auditor's sample then becomes a lookup, not an investigation.

This control automates better than most physical controls, because the estate phones home. The asset register, the identity provider and the MDM console are three lists that should agree. A scheduled diff catches the laptop imaged outside the process and never enrolled, which is the classic sampled finding.

An MDM platform nobody reconciles is a list of the devices that were never the problem.

Each of the other checks retires a manual task. Nobody screenshots a console, the chain of custody assembles itself from onboarding and offboarding, and a reported loss leaves a dated timeline in case a regulator asks. The table below sets out all four.

This is the pipeline our GRC engineering service builds. The effect on questionnaires is concrete: the answer to "how is remote kit encrypted, tracked and wiped?" stops being a policy paragraph and becomes a dashboard and a dated wipe record.

Frequently asked questions