Building a Change Management Process for New Personal Data Uses

Collecting new personal data goes through design review almost by default, because it usually requires new fields, new consent language, or new infrastructure. Reusing data you already lawfully hold for a new purpose is far easier to miss, because no new collection is happening — someone simply queries an existing data set for a new reason.

This is exactly the scenario the Act is alert to: a legal basis that was valid for the original purpose doesn't automatically extend to a new one. A marketing team repurposing support ticket data for a targeting model, for instance, needs its own answer under Sections 4, 6, and 7, not a free pass because the underlying data was already collected legitimately.

Create a single, lightweight intake form for 'new use of existing data' requests, routed to the privacy function before implementation begins. Ask what data, what new purpose, whether the original consent or legitimate use basis covers it, and whether the new use touches children's data, sensitive inference, or a new vendor.

Make this intake a required step wherever teams already request data access — through the data platform's access request process, for instance — so it's a natural checkpoint rather than a separate compliance form that's easy to skip under deadline pressure.

Most new-use requests are low risk and can be cleared quickly: reusing data within a purpose a Data Principal would reasonably expect, with no new sharing or retention change. Reserve deeper review — potentially a full DPIA — for requests that expand purpose meaningfully, introduce a new vendor, or increase retention.

Where the original legal basis doesn't clearly cover the new purpose, the options are limited and should be treated as such: seek fresh consent, confirm a genuinely applicable Section 7 legitimate use, or don't proceed. Rationalizing a stretch under the original basis is the failure mode this process exists to prevent.

Every approved new use should be logged against the data inventory and data flow map with the new purpose, basis, and approval date, so the record of why a data set is being used a particular way is traceable later rather than reconstructed from memory.

Periodically sample approved new uses to confirm they were actually implemented as approved — a scope that quietly expands after sign-off is a common source of drift between what was approved and what's actually running in production.

The Obligation Finder is a fast way to check which legal basis realistically supports a proposed new use, and the Checklist Generator can produce the intake form itself so the process has a concrete artifact from day one.