Four customer data platform operating models and who is controller or processor under each

The most expensive mistake is assuming a hosted or managed service removes the buyer's controller accountability. Suppliers may take on more operational work, but the buyer remains primarily responsible under every model. Role and contract decisions must reflect the service actually delivered, rather than the product label or the amount of work performed by the provider.

Mistake: Treating outsourced work as transferred accountability

What goes wrong: Outsourcing can be mistaken for an accountability hand-off, especially when a supplier operates the journey. Hosted and managed arrangements may shift operational tasks, but they do not remove the buyer's controller responsibilities. A provider running the service does not, by itself, take over the buyer's accountability.

Why: The buyer is the controller in every model and is primarily responsible for its own compliance and for ensuring processors comply, as the ICO explains in its controller liability guidance. A processor must also allow for and contribute to audits and inspections, so assigning service work does not assign away accountability.

Fix: For a hosted or managed route, select a processor that gives sufficient guarantees, establish a contract meeting Article 28(3), and provide documented instructions. Review the service in legal terms rather than relying on labels, and use the commercial contracts checklist to identify the areas requiring coverage.

Mistake: Assigning legal roles from product labels

What goes wrong: Assigning legal roles from labels such as hosted service or managed integration can produce a role call that does not match who makes decisions. In England, the UK GDPR determines controller and processor status, and ICO guidance explains the distinction; the product name alone is not decisive.

Why: A controller decides the purposes and means of processing, alone or jointly with others, while a processor handles personal data on a controller's behalf. The ICO's controller and processor definitions make the relevant distinction who makes decisions, rather than the commercial label assigned to a route.

Fix: The managed model needs particular scrutiny: a provider acting under its own professional obligations is a controller in its own right, and a contract cannot transfer those duties away. Before reviewing terms, record who decides each purpose and means, then classify every route according to its actual decision-making arrangement.

Apply one comparison case across every route: reconcile authorised records, retain source provenance, send corrections and suppression downstream, and export an audience only after separate approval. Then record who runs the journey and who makes decisions within the real operating arrangement. This keeps the legal role question tied to the work being assessed.

Mistake: Ranking prices built from unlike quotes

What goes wrong: Comparing quotes with unlike scopes or commercial units can create a price ranking that looks precise but cannot be trusted. Profiles, identifiable people, events and rows are not interchangeable, and a supplier fee alone does not represent the cost of the route under consideration.

Why: Routes allocate work differently, and a quote's native unit may not match another supplier's. Until the units reconcile, leave the price cell blank. Whole-life cost also includes buyer-owned work, alongside implementation, support, tax, overage and minimum terms that affect a route's overall expense.

Fix: Write one comparison case and fill the same fields for each route: function, legal entity, role, buyer work, commercial unit and exit. Show every quote in its native unit; keep the price cell blank until profiles, identifiable people, events or rows have been reconciled.

Use the budget template to check implementation, support, tax, overage and minimum terms; consult hidden costs, supplier comparison and pricing models when setting whole-life costs and reconciling unlike quote units. These checks keep buyer-owned work visible and prevent unmatched native units from being treated as directly comparable.

Mistake: Choosing before the same journey has been tested

What goes wrong: Selecting a route before exercising the same journey can conceal failure in joins, corrections, objections, exports or recovery. A test on fictional data makes these behaviours visible before the buyer accepts residual risk across the models under consideration and makes the result available for review.

Why: A lower charge cannot make up for failed suppression, just as a strong security file cannot compensate for an unusable administration task. These checks do not compensate for one another. Record each result as pass or hold instead of blending strengths against failures when comparing route evidence.

Fix: Test a false join, a correction, an objection, an export and a recovery using fictional data. Set evidence thresholds before selection, name an owner to accept remaining risk, and record unresolved points as unknown rather than treating them as zero in the decision record.

Mistake: Buying when the manual baseline already works

What goes wrong: Buying despite a reliable controlled manual baseline can add a route without fixing a problem. Spreadsheets, SQL and versioned extracts may already support the bounded decision reliably, so the buyer should not assume a platform purchase is necessary for the comparison case being assessed.

Why: The manual baseline belongs in the same assessment as hosted, buyer-built and managed alternatives; it is not an exemption from controls. If the buyer's own staff reliably manage the defined decision, a purchase may not be justified. Apply the same evidence thresholds to every route before deciding.

Fix: Keep the baseline in the comparison, identify who owns the risk, and retain unknowns as unknown rather than entering zero. Before signing with any supplier still shortlisted, run a vendor due diligence review. Choose only after the evidence thresholds are met and an owner accepts the remaining risk.