What access controls should an outsourced IT department use?

An outsourced IT department should use a layered access-control model covering identities, devices, networks, applications, data and administrative tools. The controls should be documented in an access policy, linked to business responsibilities, enforced through technical configuration and supported by evidence that access is being used appropriately.

Define who is responsible for each decision

Access controls are more effective when the provider does not decide access in isolation. The business should identify data owners, system owners and authorised approvers for each important service. The outsourced IT department can recommend suitable permissions and implement approved changes, while the organisation retains responsibility for deciding who should access commercially sensitive information.

The access policy should distinguish between:

• standard business users and operational administrators;
• employees, contractors, temporary workers and third-party contacts;
• access to ordinary business information and access to regulated, confidential or financially sensitive data;
• access required for a person’s normal duties and exceptional access required for a specific task.

This creates a clear audit trail showing why access was granted, who approved it and which system or information it applies to.

Use central identity and group-based permissions

Where practical, access should be managed through a central identity service rather than separate accounts held independently in every application. Users can then be placed into groups that represent job functions, teams or locations, with permissions assigned to those groups. This reduces inconsistent configuration and makes it easier to identify the systems affected when a person changes responsibilities.

Group names and permission sets should have clear descriptions. Nested groups, unused groups and direct user permissions should be limited because they make access difficult to understand. A documented permissions matrix can show which roles can view, create, edit, approve or delete particular categories of information.

Protect administrator access separately

Administrative access requires additional safeguards because it can affect many users and systems at once. The provider should restrict the tools from which administrative work can be performed, record administrative activity and prevent routine email or web browsing from taking place in the same privileged session.

Where supported, privileged access management can provide time-limited elevation for specific tasks. An administrator may receive the necessary rights for a defined activity and lose them when that activity is complete. This reduces the risk associated with standing privileges and makes unusual administrative actions easier to investigate.

Provider personnel should have access only to the customer environments they support. A shared technician login prevents reliable attribution and should not be used for normal administration. If a technical platform requires a service account, its purpose, owner, permissions and credentials should be recorded, and its use should be monitored.

Control remote and third-party connections

Remote management tools should be approved by the business, configured securely and limited to managed devices or defined support activities. The outsourced IT department should maintain an inventory of remote-access tools and remove those that are no longer required.

Connections from other suppliers, software vendors or specialist contractors should have a named business sponsor, a defined purpose and an agreed end point. The business should know whether the third party can view data, change configuration or administer systems. Shared supplier portals and support accounts should be avoided where individual attribution is possible.

Make device and network context part of the decision

Access should not depend solely on a person’s identity. The organisation should also consider whether the device is managed, encrypted, protected by current security controls and suitable for the sensitivity of the requested information. Network location, application risk and the type of data being accessed can also influence the decision.

A conditional access approach can restrict higher-risk activities, such as downloading confidential files to an unmanaged device, while allowing lower-risk work under controlled conditions. Network segmentation can further limit the systems that a compromised workstation or user account can reach.

Apply stronger controls to sensitive information

Not every system requires identical restrictions. Financial records, personal data, intellectual property and credentials should be classified and protected according to their sensitivity. Controls may include read-only access, approval before export, restrictions on bulk downloads, encryption and prevention of access from unsuitable devices.

Applications should expose only the functions required for a role. For example, a member of a finance team may need to view invoices without being able to change supplier bank details, while an operations user may need to update records without deleting them. Separating these functions reduces the impact of an error or compromised account.

Monitor use and test the controls

Access logs should record significant events, including authentication activity, permission changes, administrator actions, data exports and changes to security settings. Logs need suitable retention, protection against unauthorised alteration and a defined process for reviewing alerts.

The provider and business should agree which events require investigation and who handles them. Periodic access reviews should test whether permissions still match current responsibilities, but technical testing is also important. Reviews can include checking for dormant accounts, excessive group membership, unprotected service accounts, unexpected remote tools and paths to sensitive data that were not identified in the original design.

Access controls should be assessed as part of security testing and after major changes, such as a new application, office connection, acquisition or change in outsourcing arrangements. Findings should be recorded with an owner and a target completion date.

Set clear requirements in the outsourcing agreement

The contract should specify the provider’s duties for access administration, logging, security investigations, evidence retention and cooperation with the business’s own reviews. It should also explain how the provider’s personnel access customer systems and how access is handled when a member of the provider’s team changes role.

For a small or medium-sized organisation without a dedicated security function, an outsourced IT department can help design this framework and translate it into practical configuration. The business should nevertheless retain ownership of risk decisions, approval rules and the information it considers most sensitive.