Five customer data platform failure scenarios to rehearse before they happen

Customer data platforms risk scenarios are rehearsal records, not predictions. No production system, incident or supplier was provided. Each scenario below concerns one fictional England membership journey and leaves probability, loss and recovery time blank.

The journey receives an authorised source record, makes an identity decision, carries correction and suppression states, and exports an approved audience. CRM, warehouse or lake, identity service, preference management, tag or device access, analytics, activation, clean room and managed integration remain separate affected units.

What to take away

Scenario 1: two members are joined incorrectly

Trigger: a match-rule or model change enters the identity service. Observable signal: two similar fictional people become one profile, or provenance no longer explains the join. Control: predeclared negative-match fixtures and human review of uncertain merges. Fallback: restore the previous rule version and quarantine downstream exports. Owner: data steward. Review point: after correction reaches every destination and the identity log explains both the error and remedy.

The ICO's accuracy guidance sets out the UK GDPR Article 5(1)(d) accuracy principle and the Article 16 right to rectification. The page is under review following the DUAA, so a named privacy and legal reviewer must recheck it.

Scenario 2: refusal or suppression is lost

Trigger: a schema, destination connector or preference rule changes. Affected unit: one recorded refusal, objection or suppression state. Signal: the destination receives an identifier that the approved export should exclude. Control: synthetic refused-tracking and suppression fixtures at every hand-off. Fallback: stop the audience export and use the previous approved list. Owner: privacy operations owner. Review point: propagation and deletion evidence is complete.

The ICO records 29 April 2026 as the finalisation date for its storage and access technologies guidance. That guidance triggers PECR regulation 6 consent for non-essential storage or access, but it does not settle later processing or direct-marketing questions.

Scenario 3: an AI-assisted field becomes untraceable

Trigger: a model, prompt, input or supplier component changes. Affected unit: one generated classification. Signal: the reviewer cannot reproduce its source or distinguish observation from inference. Control: versioned inputs, outputs and human acceptance. Fallback: remove the generated field. Owner: AI task owner. Review point: a fictional rerun explains every retained output and permits accessible rejection and correction.

The NCSC's secure AI operation guidance advises monitoring behaviour and inputs and treating changes as new versions where appropriate. The UK GDPR duty it supports is Article 5(1)(a) fairness and transparency, plus Article 22 safeguards if the field drives a solely automated decision.

Scenario 4: privileged access survives withdrawal

Trigger: a human or service identity changes role. Affected unit: administrative access. Signal: the revoked identity can still read or export the fixture. Control: named access owner, least privilege and reviewable logs. Fallback: disable the integration, rotate credentials and preserve approved investigation evidence. Owner: security owner. Review point: every path is tested from a known state.

The NCSC's secure SaaS guidance addresses identity, audit, incidents and recovery questions. The UK GDPR obligation it supports is Article 32 security of processing, including access control and confidentiality.

Scenario 5: export exists but recovery fails

Trigger: supplier exit, outage or destructive change. Affected unit: source, identity, rights and destination records. Signal: an isolated restore fails or loses suppression meaning. Control: documented format, field definitions, hashes and restore rehearsal. Fallback: retain the approved route and suspend changes. Owner: continuity and commercial owners. Review point: the restored record remains usable without reactivating suppressed people.

The NCSC supplier assurance questions provide an official agenda for dependencies, incidents and recovery evidence. The UK GDPR obligation it supports is Article 28 processor terms and Article 32(1)(c) restoration of availability and access. Supplier answers still require buyer verification.

A restore proof must contain:

Run the exercise without pretending it happened

For one selected scenario, write the actual trigger, affected record, observer, timestamp, containment authority, fallback version and evidence needed to restart. Use fictional or specifically authorised data. Record untested areas and blank thresholds. The scenario expires when the journey, supplier, model, law or destination changes.

Worked fictional rehearsal record:

Before you act

Common questions

What should a reader do before running the exercise?

Use fictional or specifically authorised data only. The gating condition and approval list sit in What to take away.

How does the article treat probability, loss and recovery time?

Those values are not set in the scenarios. Record untested areas and any missing thresholds in the rehearsal record.

What happens when the journey, supplier, model, law or destination changes?

The scenario expires when the journey, supplier, model, law or destination changes. The rehearsal record must then be reviewed or replaced to remain valid.