What should staff do before a remote IT support session?

Before a remote IT support session, staff should confirm who is providing support, understand what access is being requested, and prepare the information and permissions needed to investigate the issue safely. Good preparation reduces delays while helping protect business data and user accounts.

Confirm the support request

Use the organisation’s established support channel to verify that the session is expected. Staff should check the support reference, the name of the technician or support team, and the reason for the connection. If an unexpected pop-up, telephone call or message asks for remote access, do not approve it until its authenticity has been confirmed through a trusted internal process.

A remote session should have a defined purpose. For example, the technician may need to inspect an application setting, review a device policy or diagnose a permissions problem. Knowing the intended scope helps the user identify anything unusual during the session and ensures that access is not granted more broadly than necessary.

Prepare the correct account and permissions

Check which user account is affected and whether the person attending the session can reproduce the problem. If administrative approval is required, arrange for an authorised member of staff to be available. Staff should not disclose passwords, multifactor authentication codes, recovery codes or other secrets to a technician. Where elevated access is needed, it should be provided through the organisation’s approved process rather than by sharing credentials.

For shared devices or systems containing several user profiles, identify the relevant profile before the session begins. This prevents support activity from being carried out against the wrong account and helps distinguish a user-specific fault from a device-wide configuration issue.

Consider privacy and confidential information

Review what may be visible on screen during the connection. Remote support can expose open windows, notifications, browser tabs, file names and locally stored documents. Move confidential material out of view where appropriate, and tell the technician if the device contains particularly sensitive information, such as client records, financial data, personnel files or commercially confidential documents.

Staff should remain present unless the agreed support process specifically allows otherwise. They can watch for unexpected activity, answer questions about the system and raise a concern if the technician appears to access an unrelated application or file. If the session needs a wider scope than originally agreed, the user should pause and seek confirmation from the appropriate internal contact.

Gather useful technical information

• Identify the device by its organisation’s asset name, location or assigned user.
• Note the application, account or service affected and whether other users experience the same issue.
• Record the steps that normally lead to the problem, without attempting unapproved fixes first.
• Have relevant ticket references, recent change records or internal instructions available.
• Confirm whether the issue affects one device, a particular site or a wider group of users.

This information gives the technician context without requiring unnecessary exploration of unrelated systems. It is also useful when the immediate fault is a symptom of a broader issue, such as a policy change, account restriction or application update.

Check the device environment

Keep any required docking station, monitor, headset, security token or other approved peripheral available if the issue involves it. If the problem affects printing, scanning, telephony or another connected service, identify the relevant equipment and its location. Do not unplug network, security or specialist equipment unless the support instructions specifically require it, as doing so may remove useful diagnostic evidence or disrupt other users.

For a device used in a shared workspace, consider whether the session should take place in a position where confidential information is not visible to unauthorised people. Remote access does not remove the need for ordinary physical security controls.

Understand what happens when the session ends

At the conclusion, ask what was checked, what was changed and whether any follow-up action is required. The technician should indicate whether temporary access has ended and whether any support tool or session component needs to be removed. Staff should also know whether they need to restart an application, sign in again or test a particular function.

Record the outcome in the organisation’s support process, including any unresolved symptoms or agreed next steps. If the issue returns, this record helps the support team compare the new behaviour with the original fault rather than repeating the same initial checks.

These preparations are suitable for sessions managed by an internal IT team or an external provider such as S2 Technology Group. The precise approval method depends on the organisation’s remote access policy, device management arrangements and data protection requirements.