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.

Vendor-neutral guide · 8 min read

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

Name: 247connect
Brand: 247connect

Written by the 247connect Marketing Team

Shape of the topic

Write it down, work the list, review it: a policy is only useful once it becomes a repeatable checklist.

In short

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.

Best-practice 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 pitfalls

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

Metrics for Remote support acceptable use policy

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

Select any column heading to sort.

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

Independent, standards-body and peer-reviewed material. None of these sources is affiliated with 247connect.

Cyber Essentials Requirements for IT Infrastructure
NCSC
UK government scheme setting baseline expectations for access control and user account management.
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)
NIST
Federal guidance covering remote session controls and acceptable use considerations.
Guidance on the use of remote access technologies
ICO
UK data protection regulator guidance relevant to disclosure and monitoring of personal data during remote sessions.

Putting it into practice

This guide is deliberately product-neutral. If you want to see how one implementation handles these requirements — attended and unattended access, named operator accounts, AES-256 encryption, audit logs and fixed pricing — the reference pages on this hub document 247connect in detail, and the product itself lives at 247connect.cloud.

What is 247connect?See a worked example