Strategy
Part of Planning a customer data platform decision around the data journey, not the product class
Customer data platforms planning template: traceability fields
Use a customer data platforms planning template to trace journey stages, role decisions and evidence links so a UK reviewer can follow each record.
This customer data platforms planning template is for documenting traceability: how a reviewer can follow a piece of data from its source, through the activity that changes or uses it, to its destination and retention record.
It focuses on the fields that connect journey details, role decisions and evidence. Use it for one defined journey at a time; it is a documentation aid, not a legal assessment or approval to process data.
Create an identifiable journey record
Give the record a stable identifier and version. The aim is to let a reviewer distinguish this journey from another one and identify which description was current when a review took place.
Record a short journey name, the organisation or business activity it concerns, the declared geographic scope, the record owner and the date it was last checked.
Keep this header deliberately narrow. It identifies the record; it does not determine whether the activity should proceed. For each field, point to the record or document that supports it rather than relying on an unsupported summary. If a description changes, retain the earlier version and note what changed.
Decision and scope fields
- Buyer decision question
- England geography rule
- Accountable owner name and role
- Decision date and evidence expiry
- Recent workflow problem event
- Included CDP function
- Excluded adjacent functions
A useful header can also name the systems and teams in scope, while distinguishing them from adjacent functions that are not part of this journey. Keep the boundary consistent throughout the record: a reviewer should be able to tell whether a later destination, data field or activity is included, excluded or not yet described.
Trace the data journey stage by stage
Use one row for each stage and connect rows with identifiers. The fields below make the description auditable: they identify what was handled, what happened to it, and where the supporting detail sits.
Tailor the entries to the actual journey rather than filling them with generic labels such as "customer data" or "integrated profile".
| Stage | Fields to capture for traceability |
|---|---|
| Source | Source record ID; system or collection point; data set or event; responsible owner; person or organisation represented; identifiers present; date range; known defects; reference for collection authority and transparency information. |
| Join | Join record ID; input source IDs; rule and version; whether the match is deterministic or probabilistic; fields used; output record ID; uncertainty or known mismatch cases; reference to how corrections are recorded. |
| Profile or inference | Field or inference name; output record ID; input IDs; derivation or transformation; purpose recorded for this use; status; provenance reference; review or expiry information where applicable. |
| Destination | Destination record ID; receiving legal entity and system; purpose; fields sent; action taken; transfer details where relevant; references for correction and deletion routes. |
| Retention | Record or data set covered; event that starts the retention period; applicable period as recorded by the organisation; exceptions; responsible owner; location of deletion or retention evidence. |
Data journey stages
- Source: system, owner, authority, identifiers
- Join: rule, version, deterministic or probabilistic
- Profile or inference: fields, provenance, purpose
- Destination: entity, purpose, fields, transfer
- Retention: clock event, period, exception, deletion
For example, do not write only "profile created". Link the profile entry to the input records and the transformation description, and identify where a reviewer can inspect the resulting field and its provenance.
If a detail is unknown, record it as unknown and identify who is responsible for resolving or reviewing it; do not make the template imply that an unrecorded step did not occur.
The ICO's data protection principles guidance should inform qualified review of purpose, minimisation, accuracy, storage limitation and security. The ICO notes the guidance is under review following the Data (Use and Access) Act and may change.
The fields here help organise that review; they do not establish that a particular use meets those principles. The publication's data protection journey review covers the review in more detail.
Record roles by activity, not by product label
A platform name or supplier contract is not, by itself, a record of who determines what happens to personal data. For each activity in the journey, record the parties involved and the basis for the role recorded.
The ICO explains that a controller determines the purposes and means of processing, while a processor acts on behalf of a controller; where parties jointly determine purposes and means, they are joint controllers. See the ICO's controllers and processors guidance.
| Activity | Role and evidence fields |
|---|---|
| Collection or receipt | Activity ID; party making the relevant decisions; role recorded; rationale; source of the collection and transparency record; reviewer and review date. |
| Joining or profile creation | Activity ID; parties deciding the purpose and means; role recorded for each party; rationale tied to the actual activity; related journey-stage IDs. |
| Sending data to a destination | Activity ID; sender and recipient legal entities; role recorded for each; purpose of the disclosure or access; contract or other supporting record reference. |
| Retention or deletion | Activity ID; party determining the applicable action; role recorded; evidence location; owner responsible for keeping the entry current. |
Roles and permissions fields
- Controller, processor or other role
- Collection and transparency record
- PECR storage or access assessment
- Direct-marketing assessment
- Rights route and propagation
- Transfers and subprocessors
Keep the role rationale short but specific: identify the decisions made and link to the evidence that supports the description. A qualified reviewer should check the classification against the real activity. For substantive UK GDPR considerations, use the publication's roles under UK GDPR guide as a companion, not as a substitute for that activity-specific review.
Build an evidence register that connects to the fields
Give each item of evidence an ID, then cite that ID beside the journey or role field it supports.
One document may support several entries, and one entry may need several kinds of evidence; make those relationships visible instead of copying a document title into a notes field without saying what it establishes. The budget template with evidence IDs applies the same habit to costs.
For each evidence item, record:
- evidence ID and storage location;
- publisher or evidence owner;
- exact subject, version, legal entity and service edition, where relevant;
- observation date and date accessed;
- geography and population covered;
- the bounded claim it supports, and the journey or role field IDs it relates to;
- limitations, missing information and any recheck date.
Label supplier statements as supplier statements. A security page, accessibility statement, demonstration and contract are different evidence items and may support different claims.
The publication's security page, accessibility statement due-diligence guidance can help organise supplier evidence, but the plan should still identify exactly which claim each item supports. If evidence cannot be matched to the entity or service being described, record that mismatch rather than silently treating it as proof.
Keep changes and hand-offs traceable
Add a change log with the record version, date, changed field IDs, reason for the change, person making it and reviewer. When a source, purpose, join, destination or supplier description changes, identify the entries that may no longer be accurate and assign them for review.
This makes it possible to distinguish a current description from an earlier one without relying on memory or scattered email threads.
For a hand-off, record the receiving reviewer or team, the specific entries needing attention, the evidence IDs available to them and the unresolved points. Keep the hand-off attached to the journey record.
Do not turn a summary into a substitute for the linked evidence: a reviewer should be able to move from a statement in the plan to the item that supports it, then see its scope and limitations. The quality checklist lists the checks to clear before a journey runs.
A completed record should let someone unfamiliar with the work follow the same chain: journey stage, relevant activity, role rationale, supporting evidence and version history. That is the purpose of the fields; the template does not itself certify lawfulness, accuracy or suitability.
Where the record feeds a purchasing decision, the five evidence gates set out what has to be in place first.
