Trust Center · Vendor Management

Vendor Management for Responsible Third-Party Data & AI Delivery

DataConsultant considers the role, access, information use and operational importance of third-party platforms, providers, tools and specialists before they support data consulting and Data & AI delivery. Review and approval are proportionate to the service, information, access, risk, contract and client requirements involved.

Request Third-Party Information Review Our Vendor Lifecycle

Risk-based classification Proportionate due diligence Defined requirements Reassessment & offboarding

From Business Need to Controlled Third-Party Use

Why Vendor Management Matters in Data & AI Delivery

Third-party dependencies can affect information handling, system access, resilience, legal obligations, client commitments and the ability to transition or exit cleanly. A one-time questionnaire alone is not enough to understand those dependencies.

Information exposureProviders may receive or process engagement information, metadata or operational context.

System accessSpecialists, integrations or tools may require accounts, APIs or environment access.

Security & privacyProvider practices can affect confidentiality, processing roles, incidents and client obligations.

Operational dependencyCritical services may introduce continuity, concentration, portability and exit considerations.

Contract alignmentSupplier terms need to support relevant client, legal, confidentiality and data requirements.

Location & downstream useGeography, transfer arrangements and downstream providers can change the review context.

From Informal Adoption to Controlled Third-Party Use

Vendor governance should make the intended purpose, review decision, conditions and ownership visible before access expands.

Uncontrolled State

Provider selected without clear purpose
Unknown information or access scope
Same review applied to every supplier
Contract terms disconnected from risk
No trigger for reassessment
Access persists after the need ends

Controlled State

Defined business purpose and owner
Risk-based review depth
Documented requirements and approval
Necessary, authorised access
Material-change review
Structured offboarding and closure

Need to Review a Proposed Third Party or Supplier Dependency?

Share the engagement context, provider role and due-diligence question so the Trust Team can route the request appropriately.

Submit a Vendor Risk Question

Third-Party Landscape: Different Providers Create Different Risks

External services can support delivery, but their roles are not interchangeable. Review should focus on what the provider does, what it can access, how important it is to delivery and which client or contractual conditions apply.

Cloud Infrastructure

Hosting, storage, compute, databases, networking, backup and observability dependencies.

SaaS & Productivity

Collaboration, analytics, development, communication, documentation and project tools.

Specialists & Subcontractors

External experts or delivery partners used for defined skills, capacity or project needs.

Open-Source Components

Libraries, frameworks, packages, models and utilities with licence and maintenance considerations.

Data & Integration Services

APIs, connectors, data platforms, enrichment services and operational integrations.

Professional Services

Legal, finance, communications or operational providers supporting business administration.

Vendor Lifecycle: From Need Identification to Structured Offboarding

The lifecycle makes ownership and decision points visible throughout the relationship. The precise evidence and controls depend on risk, engagement scope and the provider’s role.

Identify & Classify

Define purpose, service, information, access, criticality, geography and engagement context.

Assess Due Diligence

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

Set Requirements

Document appropriate confidentiality, processing, access, notification, cooperation and exit terms.

Approve & Onboard

Record the decision, assign ownership, provision necessary access and communicate conditions.

Monitor & Reassess

Review material changes, incidents, dependency shifts, scope expansion and relevant risk indicators.

Offboard & Close

Remove access, address return or deletion, confirm handover and retain appropriate closure records.

Due Diligence: Review Depth Follows the Risk Presented

This matrix illustrates how review emphasis may change with context. It is not a fixed scoring model, a set of universal thresholds or a statement that every control applies to every provider.

Provider context	Typical situation	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 purpose with restricted information use
Client data involved	Analytics, cloud, integration or collaboration service processing engagement data	Security, privacy, data roles, access, location, downstream providers, 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 delivery	Resilience, support, concentration, portability, exit, material change and continuity impact	Documented dependency plan with appropriate continuity or transition measures

Written Requirements Support Accountable Third-Party Use

Contract terms should reflect the provider’s role and risk. Written obligations do not replace technical controls, client approvals or day-to-day operational ownership.

Purpose & authorised useIdentify the intended service and limit use of engagement information to permitted purposes.

ConfidentialityAddress confidentiality duties for relevant personnel and approved downstream providers.

Security & accessSet relevant safeguarding, account-management and cooperation expectations.

Data processingWhere applicable, address roles, instructions, transfers, retention, deletion and sub-processing.

Incident & change noticeDefine appropriate notification expectations for material incidents or service changes.

Exit & closureCover access removal, information return or deletion, transition and surviving obligations.

Cloud & SaaS

Consider workload, information categories, administration model, identity options, hosting location, resilience, downstream dependencies, portability and exit feasibility.

Open Source

Consider source, licence obligations, maintenance, dependencies, known security concerns, update path, replacement feasibility and client restrictions.

Specialists & Subcontractors

Consider role suitability, engagement boundaries, confidentiality, need-to-know access, supervision, quality accountability and timely access removal.

Sub-Processors Where Applicable

Confirm the processing role, approved purposes, locations, transfers, downstream use, contractual flow-downs and client notice or approval requirements where relevant.

Vendor Evidence Should Be Relevant, Approved and Shared in Context

Use the Trust Documents area to understand what information may be public, available on request, restricted or engagement-specific.

Review Trust Documents

Ongoing Oversight: Review Continues When Risk Changes

Material changes can alter whether a provider remains suitable for its approved purpose. Monitoring is risk-based; it does not imply continuous surveillance of every provider or guarantee that every provider change will be identified immediately.

Possible Reassessment Triggers

Expanded scope or a materially different intended use
New information categories or increased sensitivity
New privileged, system or integration access
Material incidents or evidence of relevant control weakness
Significant service, ownership, geographic or downstream-provider change
Renewal, client requirements or evidence the prior assessment is no longer sufficient

Structured Offboarding & Closure

Disable user, service, API and integration access no longer required
Recover relevant assets, credentials, documentation and operational knowledge
Address information return, deletion, retention and evidence requirements
Close recurring services and confirm transition or replacement ownership
Review surviving confidentiality or contractual obligations
Retain appropriate records of the closure decision and completed actions

Client approval matters: where a contract, data-processing term, security requirement or agreed governance process requires client notice or approval for a project-specific provider, specialist, subcontractor or sub-processor, that requirement should be addressed before the relevant use proceeds.

Shared Responsibility for Third-Party Risk

Effective vendor governance depends on clear ownership between DataConsultant, the client and the external provider. Control responsibility follows the environment, access model, contract and service role.

DataConsultant

Identify proposed third parties and their intended delivery role where applicable.
Apply proportionate review and document relevant requirements within our scope.
Control access in environments and accounts we administer.
Escalate material concerns, incidents or changes where required.
Support agreed information requests and offboarding steps.

Client

Communicate contractual, regulatory, security, privacy and data-location constraints.
Approve project-specific providers where engagement terms require client approval.
Provision and govern access in client-controlled systems.
Review providers that become part of the client’s own operating environment.
Support timely decisions, change notifications and transition planning.

Third-Party Provider

Operate the provider-controlled service and its underlying controls.
Meet applicable contractual, security, privacy and cooperation obligations.
Provide relevant information subject to availability and confidentiality restrictions.
Manage provider-side personnel, infrastructure and downstream dependencies.
Support agreed incident, change, transition and termination processes.

Scope and limitation: this page describes a general, risk-based approach. It is not a warranty, certification, audit report, legal opinion or statement that every activity applies identically to every provider or engagement. Provider practices can change, some evidence may be confidential, residual risk remains after review, and engagement-specific contract terms govern where they differ from this overview.

Information That May Be Available for Due Diligence

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

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

Contact the Trust Team Explore Trust Documents

Continue Your Due-Diligence Review

Use related Trust Center pages to examine the security, privacy, resilience, compliance and AI-governance context around third-party use.

Vendor Management & Third-Party Risk FAQs

Answers for procurement, legal, privacy, security, technical and operational stakeholders reviewing third-party dependencies.

What is vendor management in a data consulting engagement?

Vendor 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. Review depth 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 review as a platform processing client data or a provider supporting a critical delivery dependency.

How are cloud and SaaS providers considered?

Review may consider intended use, information categories, access model, hosting and data-location options, authentication and administration features, relevant security and privacy information, 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, that requirement should be addressed 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 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 for the engagement.

How is client information restricted when a third party is involved?

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 service configuration, written instructions and contractual terms. Exact controls depend on the service, information and engagement.

How are open-source components considered?

Open-source components may be reviewed for function, source, licence obligations, maintenance activity, known security concerns, dependencies, compatibility, update path, replacement feasibility and client restrictions. Suitability depends on 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 incidents or material changes handled?

Relevant incidents or material changes should be assessed against their impact on the service, information, systems, dependencies and contractual obligations. Actions may include investigation, access restriction, corrective action, client communication where required, reassessment, replacement or exit.

How often are vendors reviewed?

Review 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 information return or deletion where applicable, transferring operational knowledge, ending recurring access, reviewing surviving confidentiality obligations and retaining appropriate closure records.

Can procurement or security teams request vendor due-diligence information?

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

Make Third-Party Decisions with Clear Context, Ownership and Evidence

For an engagement-specific vendor assessment, security questionnaire, sub-processor question or procurement review, provide the proposed service, provider role, relevant data or access context and the decision your team needs to support.

Discuss a Vendor Requirement Return to Trust Center

Proportionate review Defined requirements Controlled access Material-change review Structured offboarding