What role do subcontractors play in an outsourced IT service?

In outsourced IT, subcontractors are third parties used by the main provider to deliver defined parts of the service. They may contribute technical delivery, project work, specialist consultancy or physical engineering, while the customer’s agreement remains with the primary IT provider. Their involvement should be controlled through the same governance, security and service-management framework as work performed directly by the provider.

Typical roles for subcontractors

• Specialist technical work: A provider may engage an expert for areas such as network architecture, cloud migration, penetration testing, digital forensics or complex infrastructure changes.
• On-site engineering: A subcontractor may install equipment, investigate a physical fault, carry out cabling work or support technology across multiple business locations.
• Project delivery: A temporary project team may be used for a major migration, office move, systems integration or infrastructure upgrade.
• Manufacturer-authorised work: Some technical tasks require access to expertise associated with a particular product or platform. The provider should explain what the third party will do and how that work fits into the overall service.
• Independent assurance: An external specialist may assess security controls, test systems or review compliance arrangements. This is different from operating the customer’s IT environment and should be treated as a separate engagement within the provider’s governance model.

Using a subcontractor is not automatically a weakness. It can be sensible where a task is unusual, highly specialised or requires resources that would not reasonably be maintained permanently within one IT company. The important issue is whether the arrangement is transparent, proportionate and properly controlled.

The primary provider’s responsibilities

The main provider should identify which activities involve third parties and define the boundaries of each role. It should coordinate the work, confirm that the subcontractor is suitably qualified, review the deliverables and retain responsibility for resolving issues that affect the customer. The customer should not have to determine which organisation caused a problem before receiving a clear route to resolution.

This responsibility should be reflected in the contract. A clause stating that the provider may use subcontractors is less useful than a clear description of what the provider must do when it uses one. Relevant provisions may cover:

• the services or activities that can be delegated;
• the provider’s responsibility for the subcontractor’s performance;
• minimum technical, security and confidentiality requirements;
• approval or notification arrangements for material changes;
• requirements relating to further subcontracting;
• ownership and return of documentation, credentials and business data;
• incident escalation and cooperation requirements; and
• rights to review relevant assurance information or audit evidence.

Security and data protection considerations

Subcontractors can increase the number of people and organisations with access to business systems, so access should be limited to what the specific task requires. Individual accounts, multi-factor authentication where appropriate, time-limited permissions, activity logging and prompt removal of access are practical controls. Shared administrator credentials make it harder to establish who performed an action and should be avoided where a named-account alternative exists.

If a subcontractor can access personal data, confidential information or systems that process it, the arrangement should be assessed under the organisation’s data protection responsibilities. The provider should be able to explain where the data is handled, what instructions apply, how incidents are reported and how information is deleted or returned when the work ends. A subcontractor’s location and any transfer of data outside the United Kingdom may also require specific contractual and legal review.

Security checks should cover the subcontractor as an organisation, not just the individual engineer. Depending on the nature of the work, relevant evidence may include documented security policies, staff vetting arrangements, independent assurance reports, penetration-testing information, vulnerability-management processes and records showing how privileged access is controlled. The level of scrutiny should match the sensitivity of the systems and data involved.

How subcontracted work should be managed

1. Define the task: Record the objective, systems affected, dependencies, acceptance criteria and boundaries of the work.
2. Assess the subcontractor: Check relevant competence, references, security arrangements, insurance and legal terms before access or delivery begins.
3. Plan the change: Document approvals, testing, rollback arrangements and any business impact. The primary provider should make sure the subcontractor follows the agreed change process.
4. Control access: Issue only the permissions needed for the task and keep a record of who has them.
5. Review the output: Confirm that the work meets the specification, that systems are documented and that unresolved defects have an owner.
6. Close the engagement: Remove access, recover assets, retain relevant records and update the customer’s technical documentation.

Documentation is particularly important when a subcontractor changes configuration or introduces a dependency. The customer should receive accurate records of the resulting environment, including diagrams, configuration details, licences, support contacts and recovery information where relevant. Without this information, future troubleshooting and supplier changes become more difficult.

Risks to examine

The main risks are unclear accountability, inconsistent security standards, poor documentation, unauthorised access and dependency on an organisation the customer has not assessed directly. There may also be conflicts of interest if a subcontractor recommends a product or service from which it benefits commercially. These risks can be reduced through disclosure, defined responsibilities, approval controls, independent review and a requirement to use equivalent standards across all parties.

A provider should also explain whether it routinely uses the same subcontractors or selects them for individual projects. Frequent changes may affect continuity and familiarity with the customer’s environment. Conversely, a long-standing dependency on one specialist may create concentration or exit risk. Neither arrangement is automatically unacceptable, but both should be understood before the service is agreed.

Questions to ask an outsourced IT provider

• Which parts of the proposed service may be delivered by subcontractors?
• Will the provider identify those organisations and tell the customer when a material change is proposed?
• What checks are completed before a subcontractor is approved?
• How are subcontractor accounts, privileges and activity monitored?
• Who reviews and accepts the work?
• How are security incidents, failed changes and missed deliverables escalated?
• Where will business or personal data be accessed or stored?
• What happens to access, documentation and information when the subcontracted work ends?

For a small or medium-sized organisation, subcontracting can provide access to capabilities that would otherwise be difficult to obtain. It should, however, remain visible within the outsourced IT operating model. A well-structured arrangement makes the third party’s role clear, applies suitable controls, preserves an auditable record and leaves the primary provider answerable for the service delivered to the customer.