---
title: "ISO 27001 Annex A 6.7: remote working controls that survive audit"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-6-7-remote-working
published: 2023-04-28
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.6.7 Remote working"
journeyStage: implementation
---

# ISO 27001 Annex A 6.7: remote working controls that survive audit

## Key takeaways

ISO 27001 Annex A 6.7 asks for a deliberate, written decision on how people work outside the office, backed by controls an auditor can see working. Start with MFA on every entry point and managed, encrypted devices. Then add physical rules, an overseas approval step and telemetry that turns the audit answer into an export.

- **Scope** — A written decision on when, where and with which information people may work outside the office, covering home, transit, public spaces and abroad, plus access withdrawal and kit recovery at exit.
- **Authentication** — Multi-factor authentication on every remote route, including VPN, email and each SaaS application. A password alone on anything internet-reachable is the worst single gap in this control.
- **Endpoints** — Laptops and phones enrolled in mobile device management that enforces full-disk encryption, screen lock, current patches, malware protection and remote wipe, so a lost device stays a hardware problem.
- **Audit evidence** — Auditors sample the MDM dashboard, interview a remote employee and trace one access path end to end. Policy prose without matching telemetry, logs and acknowledgement records is treated as paper-only.

The security questionnaire asks how you protect staff working from home, and your answer is a policy nobody has read. ISO 27001 Annex A 6.7 is where an auditor tests that gap: not the document, but whether laptops, logins and living rooms behave the way it says.

This guide covers what the control requires and how to put MFA, secure connections, managed devices and physical rules in place. It then covers what an auditor samples and how to run the evidence continuously. It is written for CISOs, IT leads and GRC managers at 25–250-person firms running hybrid or remote-first.

## What is ISO 27001 Annex A 6.7 asking you to decide?

ISO 27001 Annex A 6.7 asks you to decide, deliberately and in writing, when people may work outside the office. It also asks what protects information when they do. It covers home, transit and public spaces, and extends to withdrawing access and recovering equipment when the arrangement ends.

The control exists because office protections stop at the front door. Firewalls, door badges and a managed network do not follow someone onto a train or into a spare bedroom. So the decision has to be explicit: which locations, which information, which systems, and which safeguards travel with the person.

Most of this is practice you already want. At 25–250 people, remote and hybrid work is the operating model. A.6.7 describes how your business already runs, and asks you to write it down and prove it. The exposures are mundane and expensive. An unencrypted laptop left on a train can be a notifiable data breach rather than a hardware cost. A phished password on a login with no second factor is network access from anywhere on earth. A screen angled toward a train aisle puts your client's data in a stranger's photo.

Buyers have noticed. Enterprise security questionnaires now probe remote-work controls as standard, and "everyone's remote, nothing's written down" reads as a firm that hasn't noticed where its perimeter went.

The device layer is shared with Annex A 8.1 (user endpoint devices), and kit taken off-site with Annex A 7.9. A laptop lost in a taxi is the classic trigger for the event reporting route in Annex A 6.8.

## What does the ISO 27001 Annex A remote working control require?

In practice, the control needs four layers working together. The first is a remote-working policy stating where, and with which information, people may work. The others are secured connections with strong authentication, managed and encrypted devices, and physical discipline in shared and public spaces.

We recommend the policy covers five things:

- **Where** people may work: home, public spaces and abroad.
- **What** classes of information may be handled in each place.
- **Which systems** are reachable remotely, and by whom.
- **Behaviours** expected in shared and public spaces, from screen locking to calls and paper.
- **Exit**: access withdrawn and equipment returned when a role or engagement ends.

Searchers call this an ISO 27001 remote working policy or an ISO 27001 remote access policy. The title matters less than the content. Whatever you name it, it must cover the technical, physical and behavioural rules rather than gesture at them.

A.6.7 is a preventive control, and it protects confidentiality, integrity and availability alike. The risks are data that is overheard or overlooked, sessions that are hijacked, and work stranded on a lost device with no backup. In practice the work falls to two disciplines, network security for the remote-access path and endpoint security for the device at the end of it, and the next sections build each layer in turn.

## How do you enforce MFA on every remote entry point?

Put multi-factor authentication on every route into company data: VPN or access broker, email, and each SaaS application, with no exceptions. The NCSC states that a password alone is not strong enough to protect sensitive data in an online service. Single-factor access to anything reachable from the internet is the worst gap in this control.

The [NCSC guidance on multi-factor authentication for corporate online services](https://www.ncsc.gov.uk/collection/mfa-for-your-corporate-online-services/why-mfa-matters) explains why remote work changed the picture. When services sat on the office network, being inside the building acted as a pseudo second factor. Cloud services removed it, so the password now stands alone, and a second factor turns a stolen credential into an incomplete one.

The NCSC also notes that some MFA methods are stronger than others, because attackers now phish one-time codes through fake login pages. Even so, any MFA beats a password alone, so start with what your identity platform supports and strengthen it later.

Work through the routes in this order:

1. **Inventory every door.** List the VPN or access broker, email, the identity provider and each SaaS tool that holds client data.
2. **Enforce at the identity platform.** Require MFA by policy at the identity provider so each application inherits it, rather than configuring tool by tool.
3. **Remove the exceptions.** Service accounts, legacy protocols and "temporary" bypasses are where single-factor access hides.
4. **Export the enforcement report.** It is the evidence the auditor will ask for.

The commonest pitfall is MFA on the VPN but not on the SaaS tools that hold the actual data. The front door is locked while the data sits behind a side window that opens with a password. An auditor who traces one access path end to end will find it.

If you do nothing else this month, do this and disk encryption. Together they carry most of the risk in this control.

## How do you secure the connection path for remote workers?

Place a corporate VPN or a zero-trust network access broker in front of internal systems, and disable auto-join to open public Wi-Fi on managed devices. The aim is that every remote session travels an encrypted, authenticated path, whatever network the person happens to be sitting on.

A VPN gives you an encrypted tunnel into internal systems. A zero-trust access broker goes further and grants access per application after checking who and what is connecting. Either meets the intent. At 50 people, whichever your identity platform already supports is usually the quicker route.

Auto-join is the quiet risk. A managed laptop that silently connects to a look-alike café network has left its protection to chance. Disable auto-join to open networks through device configuration rather than asking people to remember.

The policy and the training should also cover the home network:

- Change the router's default password.
- Keep the router's firmware current.
- Keep family members off work equipment.

None of this is expensive. Each rule is something a remote employee can state in one sentence, which is exactly how an interview tests it.

## Which technology allows users to shift their desktop off unmanaged machines?

Virtual desktop infrastructure (VDI) and remote desktop sessions are the technology that allows users to shift their desktop off hardware you do not manage. The person works on a personal machine, but the data stays in a managed session. That keeps corporate information off unmanaged hardware, which is the defensible pattern for BYOD.

Some people will use private machines, whether contractors, short engagements or plain preference. The [NCSC Bring Your Own Device guidance](https://www.ncsc.gov.uk/collection/device-security-guidance/bring-your-own-device) says the effectiveness of BYOD data protection depends on two things: how thoroughly the device can be managed, and how well usability has been balanced with security.

A private laptop you cannot enrol sits at the weak end of that scale, and a virtual session sidesteps the question. The personal machine only displays the data, so nothing lands in a local folder to be forgotten. Corporate data copied onto unmanaged hardware is the pattern auditors, insurers and incident responders all distrust, because you cannot encrypt, patch or wipe it.

Write the boundary into the policy: which roles may use private machines, that they do so only through the virtual session, and that access stops when they do not.

## How do you protect devices, screens and paper outside the office?

Enrol every laptop and phone in mobile device management (MDM) that enforces full-disk encryption, screen lock, current patches, malware protection and remote wipe. Then set plain physical rules: privacy filters, locked screens, lockable storage for paper, and muted smart speakers. Together these keep information protected when the device, or the room around it, is not.

Configure the MDM policy to enforce:

- **Full-disk encryption**, so a lost laptop yields nothing readable.
- **Screen lock and idle timeouts**, short enough to matter.
- **Current patches**, with a deadline and reporting on stragglers.
- **Malware protection**, running and reporting.
- **Remote wipe with location**, tested before anyone needs it.

Remote wipe only helps if someone reports the loss quickly, and minutes matter. Give staff a fast, guilt-free route to report a lost or stolen device, including on a Saturday night.

Set the physical rules plainly enough that people remember them:

- Lock the screen whenever you step away.
- Use privacy filters on trains and in cafés.
- Keep work screens out of sight of windows and household members.
- Provide lockable storage and a cross-cut shredder for anyone handling paper at home.
- Mute smart-speaker microphones around confidential calls.

The [ICO remote working data protection guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/working-from-home/how-do-i-work-from-home-securely/) adds a data-protection angle: anyone who has to work on their own device should keep the organisation's data separate from their personal data, so it is not kept longer than necessary.

Keep data central too. Work saved to corporate cloud storage keeps its backup coverage and stops information fragmenting across kitchen tables. Watch for personal cloud tools creeping in as shadow IT.

The physical layer is the one most often ignored entirely: no privacy-screen habit, client papers in the recycling, confidential calls on speakerphone in shared spaces. None of it needs tooling. It gets fixed when someone writes it down and trains on it.

| Layer | What it controls | Evidence an auditor can see |
| --- | --- | --- |
| Policy | Where, with which information, and by whom | Approved policy, acknowledgement records |
| Connection and authentication | Encrypted path, MFA on every entry point | VPN or broker logs, MFA enforcement report |
| Endpoint | Encryption, patching, screen lock, wipe | MDM and endpoint-protection dashboards |
| Physical | Screens, paper and calls in shared spaces | Training records, staff interview answers |
| Exit | Access withdrawn, equipment recovered | Offboarding records |

## Can staff work from abroad, and what changes across borders?

Yes, if the policy covers it. Data-protection law, client contracts and export rules can all apply when someone works overseas. A simple approval step for extended overseas working keeps the arrangement controlled without banning it, and lets you check those rules before the person travels.

The approval can be a form or a ticket asking where, for how long, and with which data. Three checks cover most cases:

- **Jurisdiction:** the data-protection law of the destination, especially for regulated data.
- **Client contracts:** some clients restrict where their data may be accessed from.
- **Export and transfer rules:** limits on moving or accessing certain data across borders.

Short trips are rarely the problem. The stays that surprise a firm are the extended ones nobody told IT about. Location signals in conditional access, covered in the final section, show them.

Ban-by-default is usually over-engineering. Unapproved and unmanaged is the real risk.

## What will an auditor test, and what evidence proves A.6.7?

Auditors test A.6.7 in three ways. They ask for the policy, then the MDM report proving the fleet matches it. They interview a remote employee about the rules they work under. And they trace one access path end to end to confirm MFA holds everywhere. A policy with no telemetry behind it reads as paper-only.

This is a people control, so the interview is the native test. Expect questions like these:

- "Show me your remote-working policy, then the MDM report proving the fleet matches it."
- "Is there any way in from outside without a second factor? Prove it."
- "This laptop was reported lost in April. Walk me through what happened, minute by minute."
- "What are your people allowed to do from a café? From another country?"
- "How would a remote employee report a stolen device on a Saturday night?"

A remote-working policy that staff cannot describe in an interview isn't a control.

Prepare an evidence pack that answers each probe:

- The approved policy and acknowledgement records.
- MDM and endpoint-protection dashboards showing encryption, patch and remote-wipe coverage, with any gaps explained.
- Remote-access and authentication logs: VPN or broker records, MFA enforcement reports and anomaly alerts.
- The risk assessment behind the remote arrangements, and any home-working self-assessment checklists.
- Authorisation records for who may work remotely and reach what.
- Training completions covering the remote-specific material.
- Offboarding records showing remote access ended and devices recovered.

Certification-body grading practice treats internet-reachable remote access on single-factor credentials, or an unencrypted fleet, as the total-breakdown case, and grades it major. A stale policy version, one unenrolled device or thin monitoring evidence grades minor, though a pattern of minors can aggregate to a major.

## How do you engineer remote-working assurance so it runs continuously?

Engineer the control so policy and enforcement are one mechanism. Device posture streams to a dashboard that alerts on drift. Conditional access admits only compliant, enrolled devices with a second factor. Impossible-travel alerts feed ticketing, and one lost-device report triggers lock, wipe, credential reset and an incident record.

Each piece removes a manual step:

- **Fleet compliance as a live metric.** Encryption, patch level, lock policy and wipe readiness are tracked together. A drift alert turns a gap into a ticket this week instead of a finding next year.
- **Conditional access as the enforcement point.** A non-compliant or unenrolled laptop simply cannot connect, so the written rule and the technical rule cannot diverge.
- **Anomaly signals.** Novel geographies and odd-hours access raise tickets, with the investigation trail captured as evidence.
- **A lost-device runbook.** One report, one flow, and speed and evidence come from the same button.

Offboarding is the last wire. Tie the end of remote access and the return of equipment into the leaver workflow. The identity platform then disables accounts on the leaving date, not when someone remembers.

Remote access that survives for weeks after someone leaves is a missing offboarding step, not an admin delay.

Fleet telemetry, conditional access and lost-device automation are the engineered controls GRCMANA's GRC engineering service builds. Setting the working-abroad and BYOD boundaries, and owning the policy suite around them, is governance judgement within a fractional CISO scope.

At 50 people, that is a short list of configurations, and the audit answer becomes an export rather than a project.

## Frequently asked questions

### Does A.6.7 allow staff to work from coffee shops and hotels?

Yes, provided the policy permits it and the safeguards travel with the person. That means secured access, a privacy filter, no auto-join to open Wi-Fi, and a device never left alone. Hotel business centres and shared computers sit outside that, so name them as prohibited. Test the controls on the device rather than judging the venue.

### Do we need a separate remote-working policy for A.6.7?

No. At 25–250 people, one combined mobile-device-and-remote-working policy is usually the right container. If you already run an acceptable-use policy, an annex may be lighter than a new document. Whichever you choose, check the version numbers across policy, device rules and procedures, because drift between them is an easy minor finding.

### What changed between the 2013 teleworking control and A.6.7?

The 2013 control was framed as teleworking. The 2022 edition reframed it as remote working, with sharper expectations on public-space risks, secure device provisioning and stronger-than-single-factor authentication. A policy that still says "teleworking" and describes only a home office predates those expectations and is worth rewriting.

### How long does it take to implement A.6.7 in a 50-person firm?

With a modern identity platform and MDM already in place, it is mostly policy plus configuration, so one to two weeks. The control leans on your existing policy process under Annex A 5.1 and the device baseline under Annex A 8.1, so build on those rather than starting fresh. If the fleet is not yet enrolled in MDM, enrolment becomes the long pole and sets your timeline.