The value of analytics data depends on its accuracy, consistency, and governance. A structured vendor risk assessment is an appropriate approach when an organisation relies on third-party tagging, analytics, consent, hosting, or data-processing services. It does not, however, resolve inaccurate specifications, weak implementation controls, inadequate consent management, unclear accountability or ineffective contractual enforcement.

Analytics and tagging tools can influence the data collected from websites and applications, where it is sent, and who can access it. Their risk profile therefore extends beyond the visible tag or software interface.

Treat a vendor assessment as one part of a wider control framework. It can support informed selection and oversight, but it does not replace contracts, technical testing, privacy analysis, incident management or operational ownership.

1. Rationale and limits

A tagging or analytics estate often contains more suppliers than the implementation documentation suggests. A typical arrangement may include:

• A tag management platform, such as Tealium iQ, Google Tag Manager or Adobe Launch.
• Analytics platforms, such as Google Analytics, Adobe Analytics or Matomo.
• A consent management platform and associated consent storage.
• Advertising, personalisation, testing and customer data services.
• Server-side tagging infrastructure, cloud hosting and observability tools.
• Data warehouses, reporting platforms and specialist implementation partners.

Each supplier may have a different role in the data flow. A tag vendor may execute code in the browser. An analytics vendor may receive event data. A server-side provider may process requests before forwarding them. A cloud provider may host the processing environment without determining the purpose of processing.

The assessment should therefore distinguish between:

1. The supplier’s security and privacy posture.
2. The organisation’s configuration and use of the service.
3. The contractual controls governing the relationship.
4. The ongoing monitoring and response arrangements.

The assessment itself does not certify that a deployment is compliant or that a supplier will not suffer an incident. It also does not confirm that a tag is firing only after valid consent, that the data layer contains appropriate values or that the chosen analytics configuration reflects the approved specification.

Recommended action:

• Record the purpose, role and criticality of each vendor.
• Separate supplier risk from implementation risk.
• Link each assessment to a contract, data protection agreement and system owner.
• Document residual risks that require treatment rather than assuming that a completed questionnaire closes them.

2. The analytics vendor landscape and where risk concentrates

Risk tends to concentrate at points where data crosses organisational or technical boundaries. The browser is often the first point of exposure because third-party scripts may access page context, identifiers, URLs, form states or data layer values.

A tag management platform may provide considerable control over what is loaded and when. That control can also create concentration risk: an incorrectly configured rule may affect many websites, applications, regions or customer journeys.

Consent management platforms create a separate dependency. They may determine whether other vendors are permitted to run, store consent choices and transmit signals to downstream services. If consent records are unavailable, incomplete or difficult to reconcile, the organisation may face both operational and regulatory uncertainty.

Server-side tagging can reduce direct browser-to-vendor connections in some architectures. It does not eliminate risk. The server-side environment becomes a significant processing point, and the hosting provider, implementation code, access model, logging configuration and forwarding rules require assessment.

Analytics platforms may also provide integrations with other services. These connections can introduce additional processors or sub-processors that are not visible from the main interface. The result is a supply chain rather than a single vendor relationship.

The vendor inventory should include direct suppliers and material dependencies, including:

• Tag management and analytics platforms.
• Consent management and preference storage providers.
• Server-side tagging infrastructure and cloud hosting.
• Data warehouses, customer data platforms and reporting tools.
• Vendors receiving advertising, identity or personalisation data.
• Specialist implementation, testing and monitoring providers.

A tagging implementation service may help clarify which services are active, but the supplier inventory should remain owned by the organisation rather than treated as a one-off project deliverable.

3. Data flow mapping: what leaves the browser, where it lands, who touches it

You cannot assess vendor risk effectively without understanding the data flow. A supplier’s published security controls may be appropriate for the service in general but unsuitable for a particular implementation if excessive or sensitive data is being transmitted.

The mapping exercise should identify:

• Events, parameters and user properties sent from websites or applications.
• Cookies, local storage values, device identifiers and other persistence mechanisms.
• Consent signals and the conditions under which tags are permitted to run.
• Collection endpoints, regional routing and storage locations.
• Access by vendor personnel, support teams and sub-processors.
• Retention periods, deletion processes and onward transfers.

The analysis should account for data that may appear harmless in isolation but become personal data when combined. A URL containing an account reference, a search term containing an email address or an event parameter containing an order identifier may create a different risk profile from a generic page-view event.

Server-side designs require a second layer of mapping. The browser may send a request to an organisation-controlled endpoint, but the request can then be enriched, logged, transformed and forwarded to several suppliers. Each step should be recorded.

The mapping should also distinguish between:

• Data necessary for the stated analytics purpose.
• Data retained for troubleshooting or operational logging.
• Data used for advertising, profiling or audience creation.
• Configuration data, such as tag rules, consent categories and destination settings.
• Data that should be excluded, redacted or pseudonymised before transmission.

Recommended action:

• Produce a source-to-destination diagram for each material data flow.
• Record the fields transmitted rather than documenting only the tool name.
• Identify the controller, processor and sub-processor roles for each stage.
• Compare the actual flow with the approved privacy notice and consent design.
• Review data layer values and request payloads through technical testing.

This work should connect with wider analytics data quality controls. A technically secure vendor can still receive incorrect, excessive or unauthorised data if the implementation is not governed.

4. Due diligence dimensions: certifications, security posture, breach history and financial stability

Due diligence should use evidence proportionate to the vendor’s role and risk. A short questionnaire may be suitable for a low-impact service with no personal data access. A critical analytics or hosting provider may require documentation review, contract negotiation and a structured security assessment.

The following dimensions are typically relevant.

Security governance and certifications

Possible evidence includes:

• ISO/IEC 27001 certification and the scope of the certified environment.
• SOC 2 reports, including the reporting period and control objectives.
• Penetration testing summaries and vulnerability management processes.
• Access control, encryption, logging, backup and disaster recovery arrangements.
• Secure software development and change management practices.

A certification is evidence of a defined control framework, not a complete assessment of the organisation’s use of a service. The scope, exclusions, expiry date and complementary customer responsibilities should be reviewed.

ISO/IEC 27001 addresses information security management systems and supplier-related controls, but it does not prescribe a specific analytics architecture. Its relevance depends on what the vendor’s certification covers and how the service is configured.

Security posture and resilience

The assessment should consider the service’s operational resilience, including:

• Availability targets and service-level commitments.
• Dependency on cloud providers and other infrastructure suppliers.
• Recovery time and recovery point objectives.
• Incident detection, notification and customer communication.
• Administrative access to customer environments and data.
• Vulnerability disclosure and remediation processes.

For critical services, an organisation may need to understand what happens if the vendor becomes unavailable during a campaign, product launch or regulatory incident.

Breach and incident history

Past incidents should be assessed in context rather than used as an automatic exclusion. Relevant evidence may include:

• The date, nature and scope of previous incidents.
• Whether personal data or credentials were affected.
• The time taken to detect, contain and notify customers.
• Root-cause analysis and remedial actions.
• Evidence of recurring control weaknesses.
• Regulatory action, litigation or unresolved customer concerns.

A supplier that has experienced an incident may present a lower current risk than one with limited transparency. The quality of its response and the improvements made afterwards are material considerations.

Financial and organisational stability

Financial viability can affect service continuity, support capacity and the likelihood of acquisition or withdrawal from a market. Review may include:

• Published accounts or appropriate financial information.
• Ownership structure and material corporate changes.
• Product roadmap and support commitments.
• Dependence on a small number of customers or infrastructure providers.
• Recent changes to pricing, licensing or data retention terms.

The assessment should not become a general corporate review. It should focus on factors that could affect data access, service continuity, contractual obligations or exit planning.

5. Sub-processors and onward transfers

A vendor may use sub-processors for cloud hosting, customer support, security monitoring, analytics infrastructure, communications or payment services. These relationships can alter where data is processed and which legal, technical and operational controls apply.

Under UK GDPR Article 28, processor arrangements should address the use of sub-processors and require appropriate obligations to flow through the processing chain. The relevant requirements are set out in the UK GDPR provisions on processor contracts. The ICO also provides guidance on contracts between controllers and processors.

The assessment should establish:

• Whether a current sub-processor list is available.
• How much notice is provided for changes.
• Whether the organisation can object to a new sub-processor.
• The locations from which data may be accessed or processed.
• Whether equivalent security and confidentiality obligations apply.
• How deletion, return and assistance obligations extend to sub-processors.

International transfers require separate analysis. A vendor may be incorporated in one country while using personnel, support teams or infrastructure in several others. The assessment should record the relevant transfer mechanism, supplementary measures and transfer risk assessment where applicable. The ICO’s international transfers guidance explains the relevant UK framework.

Recommended action:

• Obtain the current sub-processor list before approval.
• Record processing locations separately from the supplier’s registered office.
• Identify remote access from countries outside the primary hosting region.
• Confirm the contractual mechanism for sub-processor changes.
• Review international transfer arrangements when architecture or suppliers change.

The organisation’s data privacy management process should connect these findings to records of processing, DPIAs, consent design and contractual review.

6. Exit planning and data portability

Vendor selection often receives more attention than vendor exit. This can create operational dependency, particularly where the supplier stores historical analytics data, consent records, audiences, configuration or proprietary schemas.

An exit assessment should establish whether the organisation can:

• Export raw and processed data in a structured, commonly used format.
• Retrieve configuration, tag rules, triggers, variables and consent mappings.
• Preserve historical reporting during a migration period.
• Transfer data to another analytics or warehouse platform.
• Obtain assistance with migration and validation.
• Confirm deletion from production, backup and sub-processor environments.

Data portability under UK GDPR may apply in specific circumstances and is not identical to general business continuity. A contractual exit clause may need to cover information that falls outside the legal right to portability, such as implementation configuration, operational logs or platform-specific audience definitions.

The practical questions are often technical:

• Is an API available, and does it provide complete access?
• Are exports subject to volume limits or additional charges?
• Can event schemas and custom dimensions be reproduced elsewhere?
• Are consent records exportable with timestamps and policy versions?
• Can the organisation continue to access data after termination?
• What evidence confirms deletion?

An exit test may be appropriate for a critical service. A documented export from a non-production environment can reveal limitations before a contractual dispute or urgent migration occurs.

7. Scoring and tiering vendors by risk

A scoring model can make assessments more consistent, but a numerical score should not create false precision. Its purpose is to support prioritisation and ownership rather than replace judgement.

A practical model may consider:

Vendors can then be placed into tiers such as:

• Critical: material personal data processing, broad technical reach or significant dependency.
• High: important service or sensitive data with meaningful operational or privacy impact.
• Moderate: limited data or operational effect, with manageable alternatives.
• Low: low-impact service with restricted access and limited dependency.

The tier should influence the assessment depth, approval route, contract requirements and review frequency. A critical server-side hosting provider may warrant detailed evidence and executive ownership. A low-impact testing tool may be assessed through a shorter process.

Do not interpret a low score as approval to send unrestricted data. Data minimisation, consent controls and implementation testing remain necessary regardless of tier.

Recommended action:

• Define scoring criteria before assessing individual vendors.
• Record the evidence supporting each score.
• Give higher weight to data sensitivity and technical reach.
• Assign a risk owner and treatment plan for material findings.
• Review the score when the vendor’s purpose, architecture or data access changes.

8. Ongoing monitoring and periodic review

Vendor risk changes after onboarding. Product acquisitions, new integrations, revised retention policies, cloud migrations and sub-processor changes can materially alter the original assessment.

Ongoing monitoring may include:

• Reviewing vendor security notices and incident communications.
• Checking certification renewal and report periods.
• Tracking sub-processor and hosting-location changes.
• Reviewing service availability, support performance and unresolved issues.
• Testing data flows after significant implementation changes.
• Confirming that consent and privacy configurations remain effective.
• Monitoring contract expiry, renewal and price or licence changes.

Review frequency should reflect risk. A critical vendor may require formal review at least annually, with event-driven reviews between scheduled cycles. A lower-risk provider may be reviewed less frequently if its access, purpose and architecture remain stable.

Trigger events for an earlier review may include:

• A security incident or material vulnerability.
• A new country of processing or remote-access location.
• A new sub-processor.
• A major product or API change.
• A merger, acquisition or change in ownership.
• A change in data categories, retention or profiling.
• A significant discrepancy between vendor documentation and observed behaviour.

Monitoring should have an accountable owner. A document stored without a review process is unlikely to provide useful assurance during an incident, audit or migration.

9. When a formal vendor risk assessment is likely to be appropriate

A formal assessment is likely to be appropriate where:

• A vendor will process personal data or persistent identifiers.
• The service will receive behavioural, financial or customer journey data.
• A tag can load code across several websites, applications or markets.
• A CMP will determine whether other vendors can collect data.
• Server-side tagging will centralise requests, enrichment or forwarding.
• The service is difficult to replace or has limited export capability.
• The vendor uses multiple sub-processors or international processing locations.
• The service supports regulated reporting, consent evidence or material business decisions.
• A new vendor is replacing an established platform.
• A material product, contract or architecture change is proposed.

The process may be less urgent where the supplier has no access to personal or confidential information, has a narrow technical scope, can be replaced readily and does not influence consent or downstream data sharing. Even in those cases, a proportionate record of the decision may be appropriate.

The threshold should be based on actual use rather than product category. An analytics platform configured only for aggregated, non-personal measurements may present a different risk from the same platform receiving detailed user identifiers and account activity.

10. A practical approach

A repeatable process can be organised into five stages.

1. Inventory vendors and dependencies

Create a current register covering tools, suppliers, service owners, websites, applications, data categories and technical dependencies. Include direct vendors and material sub-processors where known.

2. Map data and processing

Document what is collected, where it is sent, where it is stored, who can access it and how long it is retained. Include browser-side, server-side and downstream flows.

3. Assess evidence and contractual controls

Review certifications, security documentation, incident history, financial stability, sub-processors, transfer arrangements and exit provisions. Compare the findings with the DPA, service agreement and approved privacy documentation.

4. Tier and treat risk

Assign a risk tier using defined criteria. Record findings, owners, deadlines and accepted residual risk. Apply technical or contractual treatments, such as data minimisation, access restrictions, additional testing, improved termination rights or alternative suppliers.

5. Review and monitor

Set a review date based on risk and define event-driven triggers. Reassess after incidents, architecture changes, new sub-processors, changes in data use or material contract amendments.

Recommended action:

• Maintain the vendor register alongside the tagging and analytics documentation.
• Link each vendor to an accountable business and technical owner.
• Require evidence for material conclusions rather than relying on supplier assertions.
• Periodically test critical data flows and exit procedures.
• Retain assessment history so you can identify changes over time.

A practical assessment should lead to implementable decisions. If a finding cannot be resolved immediately, the organisation should record the limitation, assign ownership and define the conditions for acceptance or remediation.

Vendor risk assessment can provide useful structure across a complex analytics and tagging estate. Its value depends on accurate data-flow mapping, proportionate evidence, clear contracts and active review.

Capability does not remove the need for specification, testing, consent control, governance and operational ownership. A vendor assessment does not fix inaccurate tagging, excessive data collection, weak contractual terms, ineffective monitoring or an exit path that has never been tested. Those controls remain necessary throughout the life of the implementation.

If you’d like to hear more on this topic and set up a 1:1 call with us, please use the contact form. Contact a Consultant.