Customer data platforms data protection: DPIA and breach

Two moments test a customer data platform under UK data protection law. One comes before a journey runs, when a DPIA is either required or not. The other comes after something goes wrong, when a clock starts. Both need decisions and records that exist before they are needed.

What to take away

A data protection impact assessment (DPIA) is a pre-launch duty for processing likely to result in high risk, not a document written afterwards.
Record why a DPIA is or is not required for each journey, and keep the real assessment, not just a template.
Treat false joins, stale values, lost suppression and incomplete deletion as events to assess, not as routine defects.
Note the moment the organisation becomes aware of a breach, because the ICO notification window runs from that point.
Agree supplier notification duties in writing before the platform goes live.

Why a journey can trigger a DPIA

Under UK GDPR Article 35, a DPIA must be completed before processing likely to result in high risk to people's rights and freedoms. The controller carries the duty. A platform combines collection, joins, profiles and activation, so ask the question for the whole journey.

The regulation names three situations where a DPIA is required. Each maps onto something a platform can do, which makes them a useful screen. A journey that touches none of them may still carry high risk, so the screen informs a judgement and never replaces one.

Situation named in Article 35(3)	Platform behaviour to check	Question to ask
Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, that leads to decisions with legal or similarly significant effects	Scores, segments and inferences that feed an offer, a price or access to a service	Does a person feel the result, and can anyone intervene?
Large-scale processing of special categories of data or of criminal convictions data	Fields or inferences that reveal health, beliefs or similar matters	Is any such data collected, inferred or imported?
Systematic monitoring of a publicly accessible area on a large scale	Location or sensor feeds joined to profiles	Does the journey follow people through physical space?

What a DPIA record has to contain

Article 35(7) sets the minimum content. First comes a description of the processing and its purposes. Then an assessment of necessity and proportionality in relation to those purposes, an assessment of the risks to people, and the measures planned to address those risks, including safeguards and security.

Where a data protection officer has been designated, the controller must seek their advice while carrying out the assessment. If the assessment shows high risk that nothing planned reduces, Article 36 requires the controller to consult the ICO before processing starts. That outcome should stop a launch date, not follow it.

A template does not satisfy any of this. The assessment has to describe the real journey: its sources, the join rule, the profile fields, each destination and the deletion route. Where the evidence cannot support the intended profile, the sensible response is to reduce the fields or stop the join.

Recording a decision that no DPIA is needed

Sometimes the honest answer is that a journey does not need a full DPIA. That answer still belongs on the record. Write down the journey version, the reviewer, the date and the reasons, including which Article 35(3) situations were considered and why each did not apply.

This note has a second use. When a source, identity rule, inferred field, purpose or recipient changes, the earlier note shows what was assumed. A change can turn a low-risk journey into one that needs an assessment, and only a written baseline makes that visible.

Reopen the decision, rather than the whole assessment, whenever a failure scenario is rehearsed and the rehearsal exposes a gap. Rehearsals often find the facts that the first screening missed.

When a data error becomes an incident

A personal data breach is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That definition is wider than hacking. A platform can fall within it through its own configuration and its own joins.

A useful habit is to keep an error ledger for false joins, stale values, lost suppression and incomplete deletion. Each entry then gets a second question: could this have exposed someone's data to the wrong people, or changed or lost it in a way that matters? Only an assessment can answer, and the ledger shows where to look.

Examples of how the questions might arise:

a false join attaches one person's records to another person's profile, and an activation destination receives the merged profile for an advertising audience;
a suppression is lost after a later source import, and a refused state is recreated;
a deletion request is applied in the platform but not in a downstream copy;
a support account is given export access it should never have held.

The first 72 hours

The ICO's breach guide says a notifiable breach must be reported without undue delay, within 72 hours of becoming aware of it. Where the risk to people is high, they must also be told without undue delay.

The steps below follow the order in which decisions fall due. They are a sequence to rehearse, not a legal script, and a privacy lawyer should review them against the real journey.

Record the date and time the organisation became aware, and who found it.
Contain the problempause the activation, revoke the access or stop the join that caused it.
Assess whether the breach is likely to risk people's rights and freedoms, and write down the reasons either way.
If it is, notify the ICO without undue delay and, where feasible, within 72 hours, even if some details are still missing.
Where the risk to people is high, tell them promptly, clearly what happened and what they can do.
Keep a record of the breach, its effects and the action taken, whether or not it was reported.

Supplier duties before anything goes wrong

A platform supplier or implementation partner may hold the evidence needed for steps 1 to 3. Article 33(2) requires a processor to notify the controller without undue delay after becoming aware of a breach. That duty sits alongside, and does not replace, the controller's own clock.

For that reason the contract should say how quickly the supplier reports, what detail it supplies, who may contact the ICO, and how logs are preserved. Check these terms during commercial contract review, not after an incident, when the chance to negotiate has gone.

Contractual labels cannot settle who the controller is. Test the facts: who decides the purposes and essential means for the activity that failed? The answer decides who notifies whom, and a platform supplier may be a processor for one activity and not for another.

Who owns each decision

Breach handling needs named owners. Name a person who can stop an activation, a person who assesses risk, a person who speaks to the ICO and a person who writes to those affected. One individual may hold several of these, but the list should exist.

Access logs support that accountability. They do not replace it. Review who can query, export, correct and activate records after every role or supplier change, and align the answers with the team roles that the organisation has defined for governance.

Rights requests belong in the same plan. A correction, objection or deletion that fails to reach every copy can be the first sign of an incident, so route those failures into the error ledger. The wider legal map sits in the UK rules and ethics guide.

Disclosure after the event

Telling people what happened is part of recovery, and the wording should be decided before an incident. The same principle applies to everyday transparency: describe material sources, purposes, recipients and rights in terms that match the real journey.

A disclosure procedure written from a blank record gives the organisation a place to log corrections, conflicts and changes. When an incident occurs, the same record shows what the organisation said before and whether it still holds.

After the incident, review the journey itself. Ask which evidence was missing, which access was too wide and which test would have caught the fault. Feed the answers into the next version of the journey, so the assessment changes with the facts.

Before you act

Write down whether a DPIA is required for each journey, with reasons.
Check every Article 35(3) situation against the real profile fields and destinations.
Put an error ledger in place for joins, stale values, suppression and deletion.
Name who can pause a journey, assess risk and notify the ICO.
Agree supplier breach notification terms in writing.
Rehearse the six-step sequence once before launch.

Common questions

Does every customer data platform journey need a DPIA?

No. The duty applies to processing likely to result in a high risk to people's rights and freedoms. Decide that for each journey and record the reasons whichever way the answer falls, because a later change can alter it.

What starts the 72-hour period?

The point at which the organisation becomes aware of the breach. For that reason the time and the person who found it should be recorded at once, before any investigation begins.

Do all breaches have to be reported to the ICO?

A notifiable breach must be reported. Whether a breach is notifiable depends on the likely risk to people, so every incident needs a recorded assessment, and the record is kept even where no report is made.