Engineering, production, governance, cost, communication · insight-1288
Keep consent as a time-stamped event table and apply it when snapshots are built
- Evidence type
- documented fact
- Difficulty
- medium
- Roles
- ML engineer, Data scientist
- Industries
- retail, e-commerce, telecom
Summary: situation, action, reason, boundary
Situation
A marketing-preference model is retrained monthly, and some customers withdrew consent after the previous snapshot (hypothetical).
Action
Store consent as an append-only table of purpose, status and effective timestamp. Join it point-in-time when building training sets and again at scoring time, and exclude rows whose consent for that purpose is not valid at that moment.
Reason
Consent can be withdrawn at any time without making earlier processing unlawful, so validity is a function of purpose and time, which a point-in-time join expresses and a latest-status flag cannot.
Boundary
Consent-based personalisation, marketing and analytics models.
Symptom or risk
Withdrawn records stay in new training sets and scoring batches, or a merge overwrites an old withdrawal, and nobody can show who was valid when.
Exceptions
Processing under another lawful basis, such as contract, is not governed by consent flags; confirm with the privacy owner.
Trade-offs
Training sets shrink and may no longer represent all customers; compare the consenting group with the rest.
Pitfalls
A single boolean updated in place that loses history.
Lessons and concepts
Claims and their sources
GDPR Article 7(3) lets the data subject withdraw consent at any time, without affecting the lawfulness of processing before withdrawal, and withdrawing must be as easy as giving consent.