Expanding purpose requires renewed notice and consent
Aliases: re-consent · consent renewal · secondary consent
What it is
When data will serve a materially different objective, renewed consent for a purpose change, or re-consent, requires fresh notice and a valid choice before the new processing begins. Earlier consent is not a blank authorization for future uses. The new decision should isolate what changed—processing, recipients, consequences, and the state after refusal—rather than making people rediscover differences in a full policy.
Why it happens
Consent is meaningful only relative to the exchange a person could foresee when choosing. Purpose expansion changes benefits, risks, or social context and invalidates information underlying the earlier choice. Treating silence, continued use, or acceptance of generic updated terms as agreement lets switching costs and service dependence masquerade as voluntariness. A focused delta notice and separate decision restore a control point before data enter the new use.
Studying it
Experiments can compare full policies, change summaries, and just-in-time prompts on change detection, consequence comprehension, uptake, and task disruption, including delayed recall. Interviews can test whether participants understand old and new uses as one exchange. Acceptance rate alone is not evidence of informed or free consent; refusal cost, visual symmetry, deferral, and continued access to the original service must be measured.
Where it stops holding
Not every implementation change requires re-consent. Equivalent technical changes that preserve purpose, data scope, recipients, and user consequences may be handled through change records. Emergency security actions or legal duties may rely on a different basis rather than fictional consent. When refusal is not genuinely possible, another prompt cannot cure the defect; the use must be narrowed or justified on a more appropriate basis.
Applying it
- Version purposes and trigger reassessment when purpose, data, operation, recipient, or consequence changes.
- Present a concise delta before first execution, with equally legible accept, decline, and decide-later actions.
- Preserve the original service and data state for people who decline; do not force migration through account deletion or repeated prompts.
- Test accepting, declining, and ignoring with separate accounts, inspecting background jobs, disclosures, and model queues; any new processing after refusal fails acceptance.