---
title: "A remote support acceptable use policy: consent, boundaries and breach handling"
description: "A remote support acceptable use policy covering consent, what operators may do in a session, recording, monitoring boundaries and breach handling."
canonical_url: https://rmm247connect.app/best-practices/remote-support-acceptable-use-policy
section: "Best practice"
product: 247connect
product_website: https://www.247connect.cloud/
site: "247connect Knowledge Hub"
author: "247connect Marketing Team"
date_published: 2026-02-02
date_modified: 2026-08-27
language: en-GB
license: Quotation and citation permitted with attribution to 247connect.
---

# A remote support acceptable use policy: consent, boundaries and breach handling

**Reading time:** 8 min read

## Summary

Remote support tools give an operator temporary control of someone else's screen, and sometimes their whole device. That is a significant trust relationship, and it needs rules that are written down rather than assumed. An acceptable use policy for remote support sets out what a user is agreeing to when they accept a session, what an operator is and is not permitted to do once connected, and what happens when either side steps outside those limits. This guide sets out the sections such a policy needs.

## Key takeaways

- Consent must be explicit and visible for every attended session, not assumed because a tool is installed on the device.
- The policy should list, plainly, what an operator may and may not do once connected, not just describe the tool in general terms.
- Recording and monitoring have separate rules from live viewing and need their own disclosure and retention statements.
- Staff need to know, in advance, how to recognise a legitimate session and how to end one they are uncomfortable with.
- A breach of the policy needs a defined response, not an ad hoc decision made after the fact.
- The policy should be short enough that staff actually read it, with detail pushed into a linked technical standard.

## Consent: what a user is actually agreeing to

Every attended remote support session should require the user to actively accept the connection, with an on-screen indicator showing that a session is active and who is connected. This is not a formality; it is the point at which the user agrees to let someone else view or control their machine, and it should be treated with the same seriousness as any other access grant.

The policy should state that sessions are never established silently for attended support, that the user can see the operator's name or identifier, and that the user can end the session at any time regardless of what the operator is doing. Unattended access, where no user consent is sought per session, is a different category and belongs in the remote access policy rather than here, with its own separate authorisation.

- Visible on-screen indicator whenever a session is active
- Operator identified by name, not just a company or tool name
- User can end the session at any point without needing to explain why
- Unattended access excluded from this policy and governed separately

## What operators may and may not do

Staff generally do not know the technical boundaries of what a remote support session allows, so the policy needs to state them plainly rather than leaving it to trust in the operator. It should list permitted actions, such as viewing the screen, installing approved software, and adjusting settings relevant to the reported fault, and it should list prohibited actions explicitly, such as accessing personal files unrelated to the issue, browsing outside the scope of the ticket, or transferring data off the device.

Operators should be required to stay within the scope of the reported issue and to explain, if asked, what they are doing and why. Where the fix requires something outside the original scope, such as investigating a second problem noticed along the way, the policy should require the operator to ask again rather than treating consent as unlimited once granted.

- Permitted: viewing the screen, adjusting settings tied to the reported issue, installing approved software, running diagnostics
- Prohibited: browsing personal files, accessing accounts unrelated to the issue, copying data off the device without a documented reason
- Operators must stay within the scope of the ticket and re-confirm consent if that scope changes
- Users can ask the operator to explain any action taken during the session

## Recording, monitoring and disclosure

If sessions are recorded or logged, this must be disclosed to the user before or at the start of the session, not discovered later. The policy should state what is captured, screen activity, keystrokes, file transfers, and for how long it is retained, and it should distinguish recording, which captures the session content, from logging, which captures metadata such as who connected and when.

Monitoring outside active sessions, such as background telemetry from an agent that remains installed, is a separate matter and needs its own clear statement in the policy, since users and staff are more likely to assume monitoring stops when the session ends unless told otherwise.

## Staff communication and recognising legitimate sessions

Staff need to know what a legitimate support session looks like so they can recognise and reject an illegitimate one, which is a common social engineering vector. The policy, or a short summary of it, should tell staff to expect a named operator, a visible connection indicator, and a request tied to a ticket they raised or expect, and to refuse or end any session that does not match that pattern.

This communication works better as a short, memorable summary distributed at induction and refreshed periodically, rather than expecting staff to read the full policy document when a session request arrives. A one-page version, pointing to the full policy for detail, tends to be what actually gets used.

## Breach handling

The policy needs a defined response for when it is breached, whether by an operator exceeding scope, a user granting access to an unverified caller, or a technical control failing to enforce the stated rules. This should name who investigates, what is reviewed first, typically the session log, and what disciplinary or contractual consequences apply depending on severity.

Breaches involving external or managed service provider operators should trigger a review of that contract's access controls, not just an individual incident response, since a single breach can indicate a wider gap in how the supplier manages its own staff.

## Checklist

1. **Require explicit consent per attended session** — No session starts without a visible indicator and an identified operator.
2. **Publish a plain list of permitted and prohibited actions** — State what an operator may and may not do, not just what the tool is capable of.
3. **Disclose recording and retention** — Tell users, before or at session start, what is captured and how long it is kept.
4. **Separate live monitoring from background telemetry** — State clearly whether anything continues to be logged once the session ends.
5. **Distribute a one-page staff summary** — Give staff a short guide to recognising a legitimate session at induction and periodically after.
6. **Require re-confirmation when scope changes** — An operator noticing an unrelated issue must ask again before acting on it.
7. **Name a breach response owner** — State who investigates a suspected breach and what the escalation path is.
8. **Review supplier contracts after a breach** — Treat a breach by a third-party operator as a contract-level issue, not only an individual one.

## Common mistakes

- Assuming consent because a remote support tool is installed, rather than requiring active acceptance per session
- Leaving 'what the operator can do' undefined, so scope creep during a session goes unquestioned
- Recording sessions without telling users, which damages trust once discovered
- Giving staff no simple way to recognise a legitimate session, leaving them vulnerable to social engineering
- Treating a policy breach as a one-off incident without checking whether the same gap exists elsewhere

## What to measure

- **Attended sessions with visible consent indicator:** Target 100%
- **Staff who have seen the one-page summary:** Target 100% at induction, refreshed annually
- **Sessions with logged operator identity:** Target 100%
- **Policy breaches investigated within an agreed time:** Track against a set target, e.g. 48 hours

## Frequently asked questions

### Does a remote support acceptable use policy need separate rules for attended and unattended access?

Yes. Attended access relies on per-session user consent and should be governed by this policy. Unattended access, where no consent is sought each time, carries different risk and is better governed by the remote access policy, with its own approval and review process.

### What should an acceptable use policy say operators cannot do?

It should explicitly prohibit actions outside the scope of the reported issue, such as browsing personal files, accessing unrelated accounts, or transferring data off the device without a documented reason, rather than leaving these as unstated assumptions.

### Do users need to be told if their remote support session is recorded?

Yes. Disclosure should happen before or at the start of the session, stating what is captured and how long it is retained, and this should be distinct from any statement about ongoing background monitoring once the session ends.

### How can staff recognise a legitimate remote support session?

A legitimate session should have a named, identifiable operator, a visible on-screen connection indicator, and a clear link to a ticket the user raised or expects. Staff should be told to refuse or end any session that does not match this pattern.

### What should happen when the acceptable use policy is breached?

The policy should name who investigates, typically starting with the session log, and set out disciplinary or contractual consequences based on severity. A breach by a third-party operator should also trigger a review of that supplier's own access controls.

### Should the acceptable use policy be a single long document?

It works better as a short core document supported by a one-page staff summary. Staff are far more likely to internalise a short, memorable version distributed at induction than a lengthy policy they read once and never revisit.

## Sources

- [Cyber Essentials Requirements for IT Infrastructure](https://www.ncsc.gov.uk/cyberessentials/overview) — NCSC. UK government scheme setting baseline expectations for access control and user account management.
- [Social Engineering](https://www.ncsc.gov.uk/collection/phishing-scams/social-engineering) — NCSC. Guidance on recognising manipulation tactics relevant to staff-facing session verification.
- [Guide to Enterprise Telework, Remote Access and BYOD Security (SP 800-46 Rev. 2)](https://csrc.nist.gov/pubs/sp/800/46/r2/final) — NIST. Federal guidance covering remote session controls and acceptable use considerations.
- [Guidance on the use of remote access technologies](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/) — ICO. UK data protection regulator guidance relevant to disclosure and monitoring of personal data during remote sessions.

---

Source page: https://rmm247connect.app/best-practices/remote-support-acceptable-use-policy