Annex A 6.7: Remote Working

To meet the annex a 6.7: remote working requirement, you must define and enforce security controls that protect information accessed, processed, or stored outside your facilities, and you must keep evidence that those controls operate in practice. Operationalize it by publishing a remote working standard, hardening endpoints and access paths, and routinely verifying compliance. ¹

Key takeaways:

• Document clear remote working rules (devices, networks, access, data handling) and make them enforceable through technical controls. ¹
• Build audit-ready evidence by mapping the control to owners, systems, and recurring logs/screenshots/attestations. ¹
• Treat third parties and contractors as in-scope remote workers when they access your information or systems remotely. ²

Annex A 6.7 focuses on a simple operational reality: your risk boundary is no longer your office. Remote work expands the attack surface through unmanaged networks, mixed personal and corporate devices, weaker physical security, and informal data handling. ISO/IEC 27001 expects you to address those risks with defined rules, consistent technical enforcement, and provable control operation. ¹

For a CCO or GRC lead, the fastest path is to translate “remote working” into a small set of non-negotiables that IT can enforce: strong identity and access management, hardened endpoints, secure connectivity, controlled data movement, and monitoring that produces evidence without heroic effort during an audit. The control is medium severity for many organizations because remote work is common and failures often cascade into incidents (credential theft, malware, data leakage) that trigger customer, regulator, and contractual scrutiny. ²

This page gives requirement-level implementation guidance you can hand to control owners. It is written to help you decide scope, write the minimum viable policy set, implement technical guardrails, and assemble the evidence package an ISO 27001 assessor will ask for.

Regulatory text

Framework requirement (excerpt): “ISO/IEC 27001:2022 Annex A control 6.7 implementation expectation (Remote Working).” ¹

Operator interpretation: You must define and implement security measures for remote working that are appropriate to your risks, and you must be able to demonstrate those measures operate. In practice, assessors expect a documented approach (policy/standard), technical enforcement (device and access controls), and repeatable evidence (configuration states, logs, and user acknowledgments) tied to a named control owner. ¹

Plain-English interpretation (what the requirement means)

Remote working controls answer four questions:

1. Who is allowed to work remotely and access what?
2. From which devices and networks can they connect?
3. How do you protect company data offsite (viewing, storage, transfer, printing)?
4. How do you detect and respond when remote access is abused or compromised?

Your goal is not to outlaw remote work. Your goal is to make remote work a managed operating mode with rules people can follow and systems can enforce.

Who it applies to

In-scope entities

• Any organization operating an ISMS aligned to ISO/IEC 27001 that permits remote access to information, systems, or services. ²

In-scope operational contexts (include these explicitly)

• Employees working from home, coworking spaces, hotels, or while traveling.
• Privileged administrators working remotely (highest risk).
• Third parties (contractors, consultants, managed service providers) connecting into your environment.
• Remote access to SaaS admin consoles, cloud consoles, internal apps, code repositories, and production support tooling.

Scoping tip: Tie scope to your asset inventory and access paths: “Any user who accesses company information systems from outside corporate-controlled networks or facilities” is usually clear enough for implementation and audit.

What you actually need to do (step-by-step)

The control is easiest to implement as one control objective with multiple supporting controls.

Step 1: Define remote working modes and minimum security baseline

Create a Remote Working Standard that covers:

• Approved remote access methods (VPN, ZTNA, VDI, managed browser, etc.).
• Allowed device types (managed corporate endpoints vs BYOD).
• Required security controls (MFA, disk encryption, screen lock, EDR).
• Data handling rules (local storage, removable media, printing, copy/paste, screenshots, cloud sync).
• Physical security expectations (no unattended devices, privacy screens for sensitive work where appropriate).

Keep it short. The standard should reference supporting procedures owned by IT/SecOps.

Step 2: Map roles, owners, and systems (make it auditable)

Build a one-page control map:

• Control owner: typically Head of IT/Security.
• Supporting owners: IAM, Endpoint Engineering, HR/People Ops (acknowledgments), Procurement/TPRM (third-party access).
• Systems in scope: IdP, MDM, EDR, VPN/ZTNA, SIEM, ticketing, DLP (if used).

This is the “map 6.7 to documented control operation and recurring evidence capture” pattern auditors reward because it prevents last-minute evidence hunts. ¹

Step 3: Enforce identity and access controls for remote access

Minimum expectations you can operationalize quickly:

• MFA required for remote access and for administrative actions in SaaS/cloud consoles.
• Conditional access rules (device compliance required, block legacy auth, restrict high-risk geos if relevant to your business).
• Least privilege: separate admin accounts, just-in-time access for privileged roles if available.

Evidence should come from IdP settings exports, screenshots, and policy objects, not a narrative.

Step 4: Enforce endpoint security for remote workers

Remote work fails most often at the endpoint. Set a baseline:

• MDM-managed devices for employees wherever feasible.
• Full-disk encryption, enforced screen lock, and OS patching.
• EDR installed and reporting.
• Local admin rights controlled.

If BYOD is permitted, define a safe alternative (VDI, managed browser, or limited web-only access) and document what data is prohibited on personal devices.

Step 5: Secure connectivity and home network assumptions

You cannot secure every home router, but you can reduce dependence on home network trust:

• Require VPN/ZTNA for internal resources.
• Restrict access to sensitive systems to managed devices only.
• Consider split tunneling decisions as a documented risk decision, with compensating controls if you allow it (logging, EDR, DNS protections).

Write down your decision and keep the approval record. Auditors look for risk-based choices.

Step 6: Control data movement and offsite storage

Pick a small set of enforceable rules:

• Approved storage locations (corporate cloud drives, sanctioned repos).
• Prohibit storing regulated or confidential datasets locally unless explicitly approved.
• Rules for printing and disposal at home (or prohibit printing of sensitive data).
• Secure file sharing with external parties (approved methods, expiration, access reviews).

If you have DLP, show the policy scope and alerts. If you do not, document procedural controls and compensating monitoring.

Step 7: Monitoring, detection, and response for remote access abuse

Remote work increases credential theft risk. Make sure you can detect:

• Unusual sign-ins, impossible travel, repeated failures.
• New device enrollments.
• Privilege escalations and admin console access anomalies.

Tie alerting to an incident process and show at least a small sample of closed alerts/tickets to prove operation.

Step 8: Train users and get acknowledgments

Security awareness should include remote-work-specific scenarios:

• Handling confidential calls in public.
• Shoulder-surfing and screen locking.
• Phishing over SMS and personal email spillover.

Collect acknowledgments (HRIS attestation, LMS completion) and keep them exportable.

Step 9: Extend to third parties and contractors

Remote working is often “outsourced” through third-party access:

• Put third-party remote access behind your IdP and MFA where possible.
• Time-bound accounts and periodic access reviews.
• Contract language requiring equivalent endpoint hygiene if they connect from their devices.

This is where GRC and TPRM teams can prevent silent scope gaps.

Required evidence and artifacts to retain

Use an evidence register that lists artifact, system of record, owner, and refresh cadence. Typical artifacts:

• Remote Working Policy/Standard and approval record.
• Access control policies: MFA/conditional access configurations (export or screenshots).
• VPN/ZTNA configuration and user access list (as applicable).
• MDM compliance reports (encryption, screen lock, patch posture).
• EDR coverage report showing endpoints reporting.
• Data handling standard (approved storage, prohibition list, exception process).
• Security awareness completion and policy acknowledgments.
• Sample remote-access monitoring alerts and incident tickets.
• Exceptions register (who, what exception, compensating controls, approval, expiry).

Practical evidence rule: If an assessor asks “show me,” you should be able to produce the artifact from a named system in minutes, not days.

Common exam/audit questions and hangups

Assessors commonly drill into:

• Scope clarity: “Who is allowed to work remotely? Does it include contractors?”
• BYOD reality: “Do you truly prevent sensitive access from unmanaged devices, or is it only written?”
• Privileged access: “How do admins work remotely, and how do you reduce risk?”
• Proof of operation: “Show me device compliance reports and conditional access blocks.”
• Exceptions: “How many exceptions exist and how do you ensure they expire?”

Hangups usually come from undocumented exceptions, “policy-only” controls, and missing operational evidence for a sample of users.

Frequent implementation mistakes (and how to avoid them)

1. Writing a remote work policy that IT cannot enforce.
   Fix: align each policy statement to a technical control or a measurable procedure (MDM rule, IdP conditional access, ticket workflow).

2. Ignoring third-party remote access.
   Fix: include third parties in the remote working definition and route their access through the same IAM controls, or document compensating controls.

3. Allowing BYOD without guardrails.
   Fix: either prohibit sensitive workflows on BYOD or provide a controlled method (VDI/managed browser) and show enforcement.

4. No evidence trail.
   Fix: build recurring exports/screenshots into a lightweight monthly or quarterly control check, then store them with clear naming.

5. Privilege treated the same as standard access.
   Fix: implement stronger controls for admin actions (separate accounts, step-up MFA, tighter device compliance).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific ISO control, so treat enforcement risk as indirect: remote working weaknesses often show up as the root cause in security incidents that then drive contractual penalties, customer audit failures, or regulator attention under separate legal regimes. Your ISO 27001 assessment risk is more direct: weak evidence of remote working control operation can lead to nonconformities because the assessor cannot verify effectiveness. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Name the control owner and publish the Remote Working Standard (draft, review, approve).
• Inventory remote access paths and in-scope systems (IdP, VPN/ZTNA, MDM, EDR).
• Turn on or tighten MFA for remote access and admin consoles where feasible.
• Stand up an evidence register for Annex A 6.7 with owners and storage locations.

Days 31–60 (enforce and close obvious gaps)

• Implement conditional access: require compliant devices for sensitive apps.
• Increase endpoint coverage: enroll devices in MDM, ensure encryption and EDR reporting.
• Formalize BYOD stance and implement the chosen control pattern (block, restrict, or provide controlled access).
• Implement a remote access review workflow for high-risk groups (admins, finance, production support).

Days 61–90 (operate, test, and make it repeatable)

• Run a table-top for a remote credential compromise scenario and capture lessons learned.
• Perform a control effectiveness check: sample users, confirm device compliance, confirm MFA enforcement, confirm log visibility.
• Clean up exceptions: approvals, compensating controls, expiry dates.
• Package your “audit-ready” Annex A 6.7 evidence set and store it in a single folder with an index.

Where Daydream fits naturally: teams often fail Annex A controls on evidence, not intent. Daydream can act as the system that maps Annex A 6.7 to owners, tasks, and recurring evidence capture so control operation is continuous rather than a scramble before the audit. ¹

Frequently Asked Questions

Does Annex A 6.7 require us to ban BYOD?

No. It requires you to manage remote working risk with appropriate controls. If you allow BYOD, document what is allowed, restrict access to sensitive systems, and keep evidence that restrictions are enforced. ²

Are contractors and third parties covered by the remote working requirement?

Yes if they remotely access your systems or information. Treat them as in-scope remote workers and apply equivalent access controls, monitoring, and periodic access review. ²

What is the fastest way to produce audit-ready evidence for remote working?

Start with an evidence register and pull configuration evidence directly from systems of record (IdP conditional access policies, MDM compliance reports, EDR coverage). Pair that with the approved remote working standard and a small sample of monitoring tickets. ¹

How do we handle remote work while traveling internationally?

Treat it as a higher-risk remote working scenario and decide on explicit rules (device compliance, step-up authentication, restricted access to sensitive systems). Document the rule and keep evidence that access controls support it. ²

What if we cannot enforce MDM on a subset of executives or engineers?

Use an exception process with documented compensating controls (restricted application access, VDI/managed browser, enhanced monitoring) and a defined expiry date. Auditors typically focus on whether exceptions are controlled and time-bound. ²

What’s the minimum policy set we need for Annex A 6.7?

A remote working standard plus supporting access control and endpoint security policies is usually sufficient if the content is actionable and enforced. Avoid duplicative documents; focus on clarity, ownership, and evidence. ¹

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview