An ICO review routine for audience management

What to take away

What an ICO enforcement notice tells an audience management team

An ICO enforcement notice is a legal instruction, but for a data team it works as a specification. The recitals describe what the controller did with personal data. The findings describe what was missing. The action required describes what must exist next.

Start with the parties. A notice names the controller, the data types and the processing purpose. If your organisation runs a customer data platform for retail loyalty, financial services marketing or a public body's service communications, that section tells you whether the fact pattern resembles yours.

Then treat the findings as control failures rather than legal conclusions. A finding that consent was not validly obtained is, in platform terms, a missing or malformed consent record. A finding that data was kept too long is a missing retention rule or a failed deletion job.

The ICO lists its enforcement notices, fines and audits on its enforcement action page, which is the correct starting point for a monthly routine. The wider action we have taken page groups fines, notices and other outcomes so you can see the pattern across sectors rather than one case in isolation.

Study the action required section last, and study it twice. Here the notice states what the controller must do, and by when. Those obligations are the closest thing to a regulator-authored backlog for audience management compliance.

One warning. A notice is addressed to one controller, so it does not bind you directly. It does show how the ICO interprets UK GDPR and PECR in a live case. Treat it as evidence of regulatory direction, not as a template you can copy without checking your own facts.

What each part of the notice tells you

Control themes to review: consent, retention and transparency

Consent evidence, retention and transparency are useful review themes when reading ICO material. Check whether your organisation can show what a person was told, when they agreed, or which version of the notice they saw.

The second is retention. Data is collected for one purpose and kept indefinitely because no rule says when it should go. Audience segments are the usual hiding place: a segment built for a seasonal campaign quietly persists for years.

The third is transparency. Privacy information is written for a launch, not maintained as processing changes. When a new data source is added to a customer data platform, the notice often is not updated.

These three failures reinforce each other. Without a retention rule, you cannot show deletion. Without deletion evidence, you cannot show that consent still applies to the data you hold. Without transparency, the consent itself is weakened.

The ICO's Guide to accountability and governance sets out the governance duties that sit behind all three, including record keeping and the need to demonstrate compliance. That guidance is the reference point when you argue internally about what evidence is enough.

The recurring finding pattern

Mapping review themes to customer data platform controls

A customer data platform is where identity resolution, segmentation and activation happen. That makes it the place where consent, retention and transparency either hold or break.

Take consent evidence first. The control is a consent record attached to the identifier, not to the channel. If the same person appears as an email subscriber, a loyalty member and a mobile app user, the consent state must resolve to one answer per purpose, with a timestamp and the notice version.

Retention rules are the second control. Each attribute and each segment needs a stated purpose and a stated life. When the life ends, the platform must delete or anonymise, and write a log entry that names the rule applied.

Transparency is the third control. Every data source feeding the platform needs a corresponding privacy notice reference. When a source is added, the notice update should be part of the same change ticket.

Accountability is the fourth. Someone must own each control, and the ownership must be visible in the platform's configuration rather than in a spreadsheet. This is also where the question of who owns each one becomes practical rather than philosophical, because a control without an owner fails quietly.

Before any of this is trusted, the data itself has to clear non-compensating quality checks, because a consent record attached to a duplicate or stale identity is not evidence of anything.

Worked example: a retail loyalty segment

A retailer builds a segment of lapsed loyalty members for a reactivation campaign. The platform holds email addresses, purchase history and app activity.

Consent evidence: the platform can show the opt-in timestamp, the notice version and the purpose. It cannot show consent for app activity because that was collected under a different notice. The segment is rebuilt to exclude app-derived attributes.

Retention: purchase history has a stated life of seven years for financial records, but marketing use has a shorter life. The retention rule is split by purpose, and the marketing copy is deleted on schedule with a log entry.

Transparency: the privacy notice is updated to name the reactivation purpose and the data sources used. The change ticket links the notice version to the platform configuration.

Accountability: the CRM manager owns consent, the data governance lead owns retention, and the marketing operations lead owns activation. Each control has a named owner and a test date.

Retention rules and deletion evidence in audience management

Retention rules are the part of audience management compliance that most teams underbuild. A rule has four parts: the data category, the purpose, the retention period and the trigger that starts the clock.

Write them down in that form. A rule that says "keep marketing data as long as needed" is not a rule. A rule that says "inactive subscriber records are deleted 24 months after the last engagement, measured from the last open or click" can be tested.

The trigger matters more than the period. For a customer data platform, common triggers are last purchase, last engagement, account closure and consent withdrawal. Each trigger needs a job that runs, and each job needs a log.

Deletion evidence is the log. It should record the rule applied, the number of records affected, the date, and the system of record. Keep deletion logs for as long as you keep the retention schedule itself, because they are the proof that the schedule operates.

Backups and archives are the usual gap. If deleted records persist in backups beyond the retention period, say so in the schedule and explain the restoration controls. A deletion claim that ignores backups is easy to challenge.

Suppression lists need their own rule. Keeping a minimal record to honour an opt-out is legitimate, but the record must be limited to what suppression requires, and the rule must say so.

Consent evidence trails and the accountability principle

The accountability principle requires you to be able to demonstrate compliance, not merely to intend it. Consent evidence is the clearest test of that duty because it is binary: either you can produce the record or you cannot.

A usable consent trail has five elements. Who consented, what they were told, when they consented, how they consented, and which version of the notice applied. If any element is missing, the consent is weak.

Purpose granularity is where trails usually fail. A single opt-in that covers email, SMS, profiling and third-party sharing is not evidence of consent for each purpose. The platform must store consent per purpose, and activation must check the purpose before a message is sent.

Withdrawal must be as easy as consent, and the withdrawal must propagate. In a customer data platform, that means a suppression state that overrides segment membership at activation time, not a manual list that someone remembers to check.

Vendor and partner data needs the same treatment. If a partner supplies audience data, the contract should state the consent basis, and the platform should record the source against the identifier.

When your team debates whether a control is ready, use a pass, fail or unresolved selection checklist rather than a discussion. Consent evidence either exists or it does not, and unresolved items should be treated as failures until proven otherwise.

Audits, decision notices and overview reports as early warning

Enforcement notices are the end of a process. Audits, decision notices and overview reports show the process earlier, which is why they are better material for a compliance team.

ICO audits and overview reports show what the regulator examines when it looks at a sector. They describe the questions asked, the records requested and the common weaknesses found. That is a free preview of your next internal audit.

Decision notices show how the ICO applies the rules in practice, including on access requests and other individual rights. For audience management, they matter because access and erasure requests are where your platform's identity resolution is tested under pressure.

The ICO's decision notices are published in full, and they are useful for testing your own procedures against a real fact pattern. Ask whether your platform could produce the same records within the statutory timeframe.

Overview reports are the most underused of the three. They summarise sector-wide findings, so they tell you what the ICO expects to see before it opens a case. If your sector has an overview report, treat its findings as a control checklist.

Early warning sources and what each gives you

A reading routine for UK audience management teams

A routine beats a scramble. Set a monthly slot, keep it short, and produce one artefact: a control backlog with owners and dates.

Keep the backlog small. Five open items with owners is more useful than fifty without. Close items only when you can show the evidence, not when the configuration change is deployed.

Run the routine before your next platform change, not after. Most control failures are introduced by a change that nobody mapped to a compliance obligation.

Common questions