Rules and ethics
Part of Customer data platforms rules and ethics: UK guide
Writing a customer data platform disclosure procedure from a blank record
Build a blank CDP disclosure procedure covering data sources, inferences, purposes, recipients, AI assistance, conflicts, corrections and accessibility.
This blank framework turns customer data platform disclosure into a versioned operating procedure. It is not a privacy notice, legal safe harbour or claim that wording alone makes customer-data processing lawful. Replace brackets only with verified facts from the journey, platform and version you are documenting.
What to take away
- A blank framework turns disclosure into a versioned operating procedure, not a privacy notice or legal safe harbour.
- Replace every bracket only with verified facts from the journey, platform and version you are documenting.
- Do not call an inferred attribute a known fact; explain material uncertainty in language the reader understands.
- A commercial disclosure must appear in the real rendering, because burying it in this policy cannot fix the advert.
- When a source, purpose, recipient, join rule, AI task or law changes, pause affected use and reopen review.
Policy record
- owner and approving reviewers[names and roles]
- journey, service and version[exact record]
- effective date, review date and expiry[dates]
- intended readers and accessible formats[populations and routes]
- evidence location and correction contact[controlled references]
The ICO page on privacy information is marked under review following Data (Use and Access) Act changes. Use it as a current regulator starting point, then require publication-day checking and qualified privacy review.
Legal anchors for the disclosure
The duty to give privacy information comes from the UK GDPR and the Data Protection Act 2018. Articles 13 and 14 set out what must be told to people, and the blank record carries the same items:
- controller identity and contact details, and the data protection officer or representative: [facts]
- purpose of each processing activity and the lawful basis for it: [purposes and lawful basis]
- legitimate interests relied on, where that is the basis[statement]
- recipients, categories of recipient and subprocessors[records]
- international transfers and the safeguards used[destination and mechanism]
- retention period, or the criteria that set it[facts]
- data subject rights, including access, erasure, portability and objection: [route]
- the right to withdraw consent where consent is the basis[route]
- the right to complain to the ICO[route]
- automated decision-making and profiling, including the logic and the consequences: [facts]
Article 13 covers data collected from the person; Article 14 covers data obtained from another source, which is why the indirect-source row needs its own entry. The ICO's right to be informed guidance is the regulator's version of the same list, and it is the page to check on publication day.
Data sources and identity
- direct sources[system, collection event, purpose and date]
- indirect or public sources[provider, provenance and authority]
- identifiers and join rules[version and uncertainty]
- profile fields and inferences[meaning, evidence, confidence status and expiry]
- correction, objection, suppression and deletion route[procedure]
Do not call an inferred attribute a known fact. Explain material uncertainty in language the intended reader can understand. A source list should distinguish collection from later analytics and activation.
The disclosure fields are the same across the major customer data platforms: Adobe Real-Time CDP, Salesforce Data Cloud, Segment and Tealium all collect, join and activate data, and what changes is where in the journey each of those steps happens. Name the platform you are describing rather than writing about "the CDP" in general.
Direct versus indirect sources
Direct sources
- Provider
- System
- Provenance
- Collection event
- Purpose
- Stated purpose
- Date
- Collection date
- Uncertainty
- Join rules
Indirect or public sources
- Provider
- External provider
- Provenance
- Provider authority
- Purpose
- Stated purpose
- Date
- Acquisition date
- Uncertainty
- Provenance limits
Purposes, recipients and choices
- purpose by activity
- [collection, storage/access, joining, analytics, activation]
- lawful basis for each purpose
- [basis, and the Article 9 condition where special category data is involved]
- responsible legal entities and roles
- [facts]
- recipients, subprocessors and access locations
- [records]
- international transfers and safeguards
- [destination, mechanism and assessment reference]
- retention event, period and deletion evidence
- [facts]
- data subject rights route
- [access, erasure, portability, objection and how each request is handled]
- applicable choices, objection and withdrawal routes
- [procedure]
- ICO complaint route
- [how a reader complains to the ICO]
The ICO's controllers and processors guidance makes roles dependent on actual purposes and means. Do not copy a contract heading into the disclosure without checking the facts.
Advertising, AI assistance and conflicts
- advertising or commercial relationship[party, nature and placement]
- audience-targeting method and exclusions[bounded description]
- objective claims and supporting evidence[reference]
- AI assistance actually used: [task, provider, model/version, human review and limits]
- funding, incentives or other conflict[fact or none evidenced]
CAP Code Section 2 addresses recognition of marketing communications. A commercial disclosure must appear in the real rendering and context; burying it in this policy cannot fix the final advert. Do not assert AI involvement when none is evidenced, and do not imply a universal AI-disclosure rule.
Publication, correction and withdrawal
Record the approved wording, placement, preview, accessibility test, reviewer and date. Capture the final rendered version rather than only the source text. State how a reader can challenge an inference or report an inaccessible disclosure.
Use a placement matrix for the real journey:
| Decision point | Disclosure location | Evidence owner | Failure action |
|---|---|---|---|
| Collection | [form, page, device interface or other surface] | [owner] | [pause or alternative route] |
| Identity join or inference | [layered explanation and rights route] | [owner] | [hold join or remove field] |
| Audience activation | [platform and advertiser context] | [owner] | [exclude destination] |
| Marketing communication | [label and qualification in final rendering] | [owner] | [withdraw creative] |
| Correction | [notice, history and affected recipients] | [owner] | [stop reuse until resolved] |
Test the matrix with fictional or specifically authorised fixtures. A reviewer should find the material fact, name the responsible organisation and follow the correction route in each configured format.
Record what was inspected, device or channel, date, result and unresolved issue. An automated accessibility check may support the record but cannot show a person can understand and use the disclosure.
Where a profile or inference affects a person, connect the disclosure to its provenance and expiry. Do not reveal another person's information or confidential model detail merely to appear transparent; qualified privacy and legal reviewers should resolve that tension for the actual case.
When a source, purpose, recipient, join rule, AI task, commercial relationship or law changes, pause affected use and reopen review. Publish a dated correction where needed, preserve the decision trail and withdraw obsolete wording. Privacy, PECR, advertising, consumer, accessibility, IP, security and contract approvals remain separate; no disclosure compensates for a failed gate.
Before you act
- Replace brackets only with verified facts from the journey, platform and version you are documenting.
- Record owner, approving reviewers, journey version, effective date and review date.
- Name the lawful basis for each purpose and the rights route for access, erasure, portability and objection.
- Give the international transfer destination and mechanism, and the route for complaining to the ICO.
- Distinguish collection from later analytics and activation in the source list.
- Check the ICO privacy information page on publication day and require qualified review.
- Test the placement matrix with fictional or specifically authorised fixtures.
- Publish a dated correction and withdraw obsolete wording when facts change.
Common questions
What should replace the brackets in the policy record?
Only verified facts from the journey, platform and version being documented. The record covers the owner and approving reviewers, the journey and version, and the effective and review dates. It also covers intended readers, accessible formats, evidence location and correction contact. The framework is not a privacy notice, legal safe harbour or claim that wording alone makes processing lawful.
How should a reader handle an inferred attribute in the disclosure?
Do not call an inferred attribute a known fact. Explain material uncertainty in language the intended reader can understand, and record profile fields and inferences with meaning, evidence, confidence status and expiry. Where a profile or inference affects a person, connect the disclosure to its provenance and expiry rather than revealing another person's information.
What happens when a source, purpose or law changes?
Pause the affected use and reopen the review. If needed, publish a dated correction, keep the decision trail and withdraw outdated wording.
