Customer data platforms: five evidence gates

Mistake: Approving because the deadline arrived

This guide sets out five evidence gates for an England buyer deciding whether to adopt, extend or retain a customer data platform; it is not a dated schedule or delivery promise.

It cannot guarantee every approval will fit, and any open evidence gate means the plan must pause or end.

Why it goes wrong: Dependencies and reviewer availability determine whether a bounded decision is possible within the buyer-chosen envelope. Compressing an unresolved assessment to protect the calendar can conceal waiting and leave changes to a source, purpose, identity, destination, supplier, subprocessor or ownership arrangement outside the current evidence record.

Fix: Build a buyer-owned calendar only after dependencies and reviewer availability are known. Record each gate's earliest start, evidence owner, reviewer availability, external dependency, decision meeting and latest useful date. Set the day-ninety envelope only when those conditions are known, so assumptions do not become approved estimates.

Keep duration estimates blank until the responsible people confirm them. Parallel work is reasonable only when neither task assumes the other gate has passed. If dependencies, review times or approval requirements remain unknown, leave the schedule uncertain rather than filling it with invented duration estimates.

Track waiting separately from active work. If a supplier record, reviewer decision or source-authority answer is delayed, move dependent work or reduce scope. Never relabel an untested item as accepted to preserve the date; record it as a dependency, not completed progress.

A weekly exception review can consider new risks, missing records, journey changes and tests that need rerunning. The meeting itself is not progress evidence: retain the resolved record or decision. Use that cadence only if the buyer wants it, and report decisions rather than activity as evidence of movement.

Treat an extension as a fresh decision, with an owner and revised evidence expiry. Reopen the record if a source, purpose, identity rule, destination, supplier, subprocessor or ownership arrangement changes. Do not compress an unresolved assessment to save the calendar; move dependent work or reduce scope.

Mistake: Buying the label before defining the job

Buying the CDP label before naming a buyer outcome reverses the decision. A category cannot establish whether the organisation should adopt a CDP, extend existing arrangements or retain the current route. That choice must follow a named buyer decision, an accountable owner and a defined workflow.

Why it goes wrong: A customer data platform (CDP) aggregates and organises customer data from different touchpoints into a unified customer profile, then makes it available to other systems for marketing, service and customer experience work. This category description does not establish which buyer decision or workflow needs that capability.

Fix: At Gate A, name one England buyer decision and its accountable owner. Record the organisation geography rule, recent workflow problem, current manual route and latest useful decision date. Across Gates A to E, the intended outcome remains whether the buyer adopts a CDP, extends what already exists or keeps the current route.

Use these five gates in sequence; keep each gate open until its required evidence is recorded:

Describe the specific source-to-output journey before comparing routes. Reject a single customer view unless the record names the records, joins, profile states and intended action. Limit the choice to a workflow the buyer can describe, so the required output is not left undefined.

Keep CRM, warehouse or lake, identity resolution, preference management, tag management, analytics, activation, clean-room work and managed integration distinct in the record. Each has a different place in the decision. That separation makes clear which function the described journey requires for this buyer.

Mistake: Assuming a technical join establishes authority

Joining or activating customer records before establishing authority confuses technical capability with permission. A feature that connects data does not prove the proposed use is authorised. The buyer must assess the actual facts, including purpose and collection context, before allowing the journey to proceed.

Why it goes wrong: Gate B needs a source and identity record for every join. Without source owners, collection authority, identifiers and known quality limits, a match can conceal uncertainty. Corrections, objections, suppression and deletion also need traceable routes through recipients, so responsibility remains clear for each source and destination.

Fix: Inventory source owners, collection authority, identifiers, quality limits and retention. Version every join and mark uncertainty. Trace how corrections, objections, suppression and deletion move through each recipient, so the record shows where each action must be handled and which source or destination remains responsible.

Apply UK GDPR data-protection principles to purpose, minimisation, accuracy, storage limitation and security. The qualified buyer reviewer must assess actual facts; a data-protection review does not grant permission or replace that assessment for the buyer's proposed use.

ICO guidance on data protection by design and default can inform the design record, but cannot act as approval. It does not replace a qualified assessment of actual facts and collection context for the proposed journey. Keep that distinction visible in the approval record rather than treating guidance as permission.

Where tags, pixels or similar technologies feed the journey, screen the design separately against ICO guidance on storage and access technologies under the Privacy and Electronic Communications (EC Directive) Regulations 2003 (PECR). The PECR regulation text is relevant; stop if the purpose, technology or user control cannot be described under regulation six.

Mistake: Comparing routes that do different jobs

Comparing options that perform different jobs can make a favourable answer look like proof of feasibility. Gate C should not admit a route because a supplier describes broad customer-data capability. Each candidate must address the same defined function and use the same comparison basis.

Why it goes wrong: Gate C opens only after Gates A and B have evidence. If options are assessed against different functions or assumed supplier scopes, unlike scope and assumptions disappear inside the comparison. That leaves no reliable basis for judging which route can perform the buyer's defined job.

Fix: Admit the manual and existing-tool route, buyer-built route, licensed hosted service and managed integration only when each can address that function. Options must answer the same job, not simply share a customer-data label; otherwise the comparison mixes unlike scope and assumptions.

Use common fields for legal entity, roles, inputs, joins, outputs, buyer work, commercial unit, security, accessibility, contract, support, export and deletion. A common-field comparison keeps evidence tied to Gate A's function rather than a supplier's preferred scope, exposing unlike assumptions.

Licensed choices have recognisable forms. A traditional CDP unifies data within one platform; a composable CDP builds profiles inside the enterprise data warehouse already used by the buyer; marketing clouds such as Salesforce Data 360 and Adobe Marketing Cloud bundle CDP functions with other marketing tools. Compare every form against the same defined function and fields.

Leave costs and decision weights blank until current evidence exists. For external services, NCSC supplier assurance questions can prompt requests about audit, incident, return and termination. Treat replies as requested evidence, never automatic approval, and mark unanswered fields unknown rather than favourable to the buyer.

Gate D: Treating a successful demonstration as readiness

Gate D is the reversible-test and readiness gate. A successful demonstration does not establish live readiness: its evidence must identify the test scope and fixtures, predeclared expected states, operator, reviewer, rollback, observed results and failures. It must also keep separate evidence for privacy and PECR authority, accuracy and rights, security, accessibility, export and deletion before production approval; no open required condition may be overlooked.

Why it goes wrong: A fixture shows only the behaviours and conditions selected for testing. Treating that observation as wider proof leaves uncertainty about whether the real journey handles uncertain records, preferences, corrections and user rights safely. It cannot justify enabling production destinations while a required condition remains open.

Fix: Use fictional or specifically authorised fixtures, with production destinations disabled. Before testing, use a quality checklist and predeclare expected states, operator, reviewer and rollback. Keep buyer thresholds blank until justified; the result should cover only behaviours and conditions actually exercised.

Stop for unexplained joins, recreated suppression, unknown right-of-access handling, an inaccessible critical task or an export that cannot be restored. Record each failure and its owner rather than waiving the condition to preserve a successful demonstration; production destinations stay disabled until the unresolved issue is addressed.

Mistake: Turning a fixture result into a wider claim

Recording a fixture result as proof of live performance, commercial return or legality overstates what the test establishes. Even an expected outcome proves only what was exercised. The decision record must separate that finding from unresolved claims and unknowns that remain open.

Why it goes wrong: Test evidence remains limited to its fixture and the conditions actually exercised. It cannot settle commercial return, legal authority or performance beyond those conditions. Treating an observed result as a wider conclusion converts unknowns into claims that the available evidence does not support.

Fix: At Gate E, record the selected route or decision not to proceed, rejected options, evidence, dissent, unknowns, conditions, review date and exit trigger. Keep the entry to material needed to support the choice, rather than allowing successful test output to stand in for missing evidence.

Store only evidence needed for the decision, then follow the approved retention and deletion route. Keep unknowns visible instead of converting them into accepted claims, and make the review date and exit trigger clear in the record. A test result remains bounded to its fixture and exercised conditions.