Vendor and Third-Party Management

Executive summary

A lifecycle approach to external dependencies

Third-party risk is managed through informed selection, proportionate controls, clear accountability, and timely closure—not through a one-time checklist alone.

Before use

Clarify purpose, access, data, criticality, ownership, and client-specific constraints.

During selection

Review relevant security, privacy, legal, technical, operational, and commercial factors.

During service

Maintain defined ownership, controlled access, and review of material changes or incidents.

At exit

Remove access, address information return or deletion, and preserve necessary closure records.

Third-party landscape

Types of third parties used in data consulting

External services can support delivery, but their roles differ. We consider what each provider does, what it can access, and how its use affects client commitments.

Cloud infrastructure providers

Hosting, storage, compute, database, networking, backup, observability, and related infrastructure that may support an agreed delivery environment.

SaaS and productivity platforms

Collaboration, ticketing, analytics, development, communication, documentation, security, and project-management tools used where appropriate.

Specialists and subcontractors

Independent experts or delivery partners engaged for defined skills, capacity, geography, or project-specific requirements, subject to applicable controls.

Open-source components

Libraries, frameworks, packages, models, and utilities considered for suitability, licensing, maintenance, security, and client constraints.

Data and integration services

APIs, connectors, enrichment services, data platforms, and operational tools that may process or exchange engagement information.

Professional service providers

Legal, finance, communications, or operational providers that support business administration and may receive limited information for a defined purpose.

Vendor lifecycle

From need identification to secure offboarding

The process is designed to make ownership and decisions visible throughout the relationship.

STEP 01

Identify and classify

Define the intended service, information involved, access required, business criticality, and engagement context.

STEP 02

Assess due diligence

Review relevant security, privacy, legal, operational, technical, financial, and service-delivery considerations.

STEP 03

Set requirements

Document appropriate confidentiality, data-processing, security, access, notification, cooperation, and termination terms.

STEP 04

Approve and onboard

Record the decision, assign ownership, provision only necessary access, and communicate engagement-specific conditions.

STEP 05

Monitor material change

Review significant changes, incidents, service dependencies, scope expansion, or risk indicators where relevant.

STEP 06

Offboard and close

Remove access, recover or delete information as applicable, confirm handover needs, and retain appropriate records.

Due diligence

Review depth follows the risk presented

A provider’s assessment is shaped by the intended service, information sensitivity, access level, business criticality, integration, geography, and contractual context.

Security posture

Access-control approach and authentication options
Relevant security documentation and control evidence
Incident-management and vulnerability-handling expectations
Data-location, environment, backup, and resilience considerations

Privacy and data use

Purpose and categories of information processed
Data roles and engagement-specific responsibilities
Retention, deletion, transfer, and sub-processing considerations
Support for data-subject or regulatory obligations where applicable

Legal and contractual fit

Confidentiality, ownership, permitted-use, and restriction clauses
Data-processing terms where personal data is involved
Notification, audit, cooperation, and termination provisions
Alignment with client-specific contractual commitments

Operational suitability

Service dependency, support model, and continuity impact
Integration requirements and exit feasibility
Change-management and ownership arrangements
Financial, geographic, concentration, and availability considerations

Decision-useful controls

How review expectations change with context

This matrix illustrates the type of emphasis that may apply. It is not a fixed scoring model or a statement that every control applies to every provider.

Context	Typical example	Primary review emphasis	Possible decision condition
Limited information	Administrative or productivity service with no planned client-data use	Purpose, account security, terms, continuity, and data-use restrictions	Approved for a defined business purpose with restricted information use
Client data involved	Analytics, cloud, integration, or collaboration service processing engagement data	Security, privacy, data roles, access, location, sub-processors, retention, and incident terms	Approval subject to contractual, technical, privacy, and client requirements
Privileged access	Specialist requiring controlled access to a client or delivery environment	Identity, least privilege, supervision, confidentiality, activity boundaries, and offboarding	Time-bound, authorised access with defined ownership and removal steps
Critical dependency	Provider supporting core hosting, data pipelines, operational reporting, or managed service delivery	Resilience, support, concentration, portability, exit, material change, and continuity impact	Documented dependency plan and appropriate continuity or transition measures

Contractual requirements

Written obligations support accountable third-party use

Contract terms are selected according to the provider’s role and the engagement. They do not replace technical controls or operational ownership.

Purpose and authorised use

Terms should identify the intended service and limit use of engagement information to permitted purposes.

Confidentiality and personnel duties

Appropriate confidentiality obligations may extend to personnel and approved downstream providers.

Security and access expectations

Requirements may address reasonable safeguards, least-privilege access, account management, and cooperation on security matters.

Data-processing provisions

Where applicable, contracts may address data roles, processing instructions, transfers, retention, deletion, and sub-processors.

Incident and change notification

Notification expectations may be defined for relevant incidents, material service changes, ownership changes, or control changes.

Exit, return, and deletion

Termination provisions may cover access removal, information return or deletion, transition assistance, and surviving obligations.

Specific considerations

Cloud, open source, specialists, and sub-processors

Different third-party models create different decision points. The following considerations help make those distinctions explicit.

Cloud and SaaS provider considerations

Where cloud or SaaS services support delivery, review may cover:

Intended workload, information categories, tenancy, and administration model
Identity, authentication, logging, integration, and configuration options
Hosting location, transfer implications, backup, resilience, and service dependencies
Contract terms, sub-processors, incident practices, portability, and exit feasibility

Open-source software governance

Open-source use is considered in the context of the solution rather than treated as automatically acceptable or unacceptable.

Source, licence obligations, compatibility, and distribution implications
Maintenance activity, release history, dependencies, and community support
Known security concerns, update path, and replacement feasibility
Client restrictions, documentation needs, and intended production use

Subcontractor and specialist oversight

Specialists may be engaged for defined expertise or capacity. Appropriate oversight can include:

Role suitability, identity, experience, conflicts, and engagement boundaries
Confidentiality, acceptable-use, security, and data-handling obligations
Need-to-know access, supervision, deliverable review, and quality accountability
Timely access removal and confirmation of return or deletion requirements

Sub-processor transparency where applicable

When a provider processes personal data on our behalf, engagement-specific obligations may require notice, approval, flow-down terms, or supporting information.

Confirm whether the provider is acting as a sub-processor for the relevant activity
Address approved processing purposes, locations, transfers, and downstream use
Apply contractual obligations appropriate to the processing relationship
Support client notice or approval processes where agreed or legally required

Ongoing oversight

Review continues when risk changes

Material changes can alter whether a provider remains suitable for its approved purpose.

Possible reassessment triggers

Expanded scope, new data categories, privileged access, incidents, control changes, ownership changes, material service changes, renewal, client requirements, or evidence that the existing assessment is no longer sufficient.

Ongoing review and change monitoring

Maintain an accountable owner for the relationship where appropriate
Review material incidents and service changes relevant to the approved use
Reassess when access, information use, scope, or criticality materially increases
Consider corrective action, restriction, replacement, or exit when risk becomes unacceptable

Important consideration

Monitoring is risk-based. It does not mean continuous surveillance of every provider or guarantee that all provider changes will be identified immediately.

Offboarding and access removal

Closure should reduce residual access and prevent a former provider relationship from remaining an unmanaged dependency.

Disable user, service, API, and integration access that is no longer required
Recover assets, credentials, documentation, and operational knowledge where applicable
Address return, deletion, retention, and evidence requirements under relevant terms
Close recurring services and confirm ownership of replacement or transition activity
Retain appropriate records of the decision and completed closure actions

Client approval for project-specific third parties

Some engagements require client notice or approval before a project-specific provider, specialist, subcontractor, or sub-processor is used.

How this is handled

Where the contract, data-processing terms, security requirements, or agreed governance process requires it, we seek to identify the proposed role, purpose, access, information use, and relevant provider details before proceeding.

Client-controlled environments: Clients may retain responsibility for approving, configuring, granting, monitoring, or removing access in systems they control.

Shared responsibility

What this means for clients

Effective third-party governance depends on clear information and coordinated decisions between us, the client, and relevant providers.

Our role may include

Identifying proposed third parties and their intended delivery role
Applying a proportionate review and documenting relevant requirements
Controlling access within environments and accounts we administer
Escalating material concerns, incidents, or changes where required
Supporting agreed information requests and offboarding steps

Client responsibilities may include

Communicating contractual, regulatory, security, privacy, and data-location constraints
Approving project-specific providers where the engagement requires client approval
Provisioning and governing access in client-controlled systems
Reviewing provider choices that become part of the client’s own operating environment
Supporting timely decisions, change notifications, and transition planning

Scope and limitations

This page describes a general, risk-based approach. It is not a warranty, certification, audit report, legal opinion, or statement that every described activity applies identically to every provider or engagement.

Provider practices and documentation can change over time
Some information may be subject to confidentiality or provider restrictions
Residual risk remains after due diligence and control implementation
Contract terms and client requirements govern where they differ from this overview

Information available on request

Subject to engagement relevance, availability, approval, and confidentiality restrictions, the Trust Team may help coordinate:

Descriptions of the proposed third party and its intended role
Engagement-specific data-flow or access information
Relevant provider documentation approved for sharing
Responses to procurement, legal, privacy, and security questions
Applicable sub-processor information where required

Related Trust Center pages

Explore related topics or contact the Trust Team for engagement-specific information.

Frequently asked questions

Vendor and third-party management FAQs

Answers for procurement, legal, privacy, security, technical, and operational stakeholders.

What is vendor risk management in a data consulting engagement?

Vendor risk management is the structured consideration of third parties that may support an engagement. It can include identifying the service and information involved, reviewing relevant security, privacy, legal, operational, and technical factors, documenting appropriate requirements, controlling access, monitoring significant changes, and completing offboarding activities.

Do all vendors receive the same assessment?

No. The depth of review should reflect factors such as the service provided, access level, information sensitivity, business criticality, integration scope, geographic considerations, and client requirements. A low-risk administrative tool would not normally require the same assessment as a cloud platform processing client data.

How do you evaluate cloud and SaaS providers?

Our approach may consider the intended use, information categories, access model, hosting and data-location options, authentication and administration features, relevant security and privacy documentation, service dependencies, contractual terms, sub-processors, incident practices, portability, and exit requirements. The precise review depends on engagement scope.

Will a client be told when a project-specific third party is proposed?

Where a contract, data-processing arrangement, security requirement, or agreed project governance process requires notice or approval, we seek to address that requirement before the third party is used for the relevant activity. The applicable process depends on the engagement terms and the third party’s role.

What is the difference between a subcontractor and a sub-processor?

A subcontractor supports delivery of contracted work. A sub-processor is a type of downstream provider that processes personal data on behalf of a processor. A provider may be one, both, or neither depending on its actual role. Contractual and privacy review should confirm the correct classification.

Do you maintain a public sub-processor list?

The specification of confirmed public sub-processor information has not been provided for this page. Where applicable, clients may request engagement-relevant third-party information or documentation from the Trust Team. Publication of a formal list should occur only after legal and privacy approval.

How are third parties restricted from using client data?

Where a third party receives client information, the intended purpose, permitted use, confidentiality duties, access conditions, retention expectations, and other relevant restrictions may be addressed through the service configuration, written instructions, and contractual terms. Exact controls depend on the service and engagement.

How do you manage open-source software risk?

Open-source components may be reviewed for their function, source, licence, maintenance activity, known security concerns, dependencies, compatibility, and client restrictions. Components should be used only where their licence and risk profile are suitable for the intended solution and delivery context.

Can vendors or specialists access production systems?

Access is not assumed. Where access is necessary, it should be specifically authorised, limited to the minimum required scope and duration, protected by appropriate account controls, and removed when no longer needed. Client-controlled environments may require additional client approval or provisioning.

How are vendor security incidents handled?

Relevant incidents should be assessed according to their impact on the service, information, systems, and contractual obligations. The response may include containment coordination, evidence gathering, client communication where required, corrective action, and review of continued use. Exact notification duties depend on applicable agreements and circumstances.

How often are vendors reviewed?

Review frequency is risk-based rather than identical for every provider. Reassessment may be triggered by material scope changes, new data use, expanded access, incidents, significant control or ownership changes, renewal, client requirements, or other indicators that alter the risk profile.

What happens when a third-party relationship ends?

Offboarding may include disabling accounts and integrations, recovering assets, confirming data return or deletion where applicable, transferring operational knowledge, ending recurring access, reviewing surviving confidentiality obligations, and retaining appropriate records of the closure.

Can clients request vendor due-diligence documents?

Clients may request information relevant to their procurement, legal, privacy, or security review. Availability can depend on confidentiality restrictions, provider terms, the engagement scope, and whether the requested material exists in an approved form. The Trust Team can coordinate an appropriate response.

Does this page guarantee that every third party is risk-free?

No. Third-party use always involves dependencies and residual risk. This page describes a risk-based approach intended to support informed selection, proportionate controls, transparency, and lifecycle oversight. It does not guarantee uninterrupted service, eliminate all risk, or replace engagement-specific review.