Lawful Basis & Purpose Limitation
Why you may hold the data, and why that forbids the second use somebody proposed.
3 to work through
-
beginner Multiple choice
A European travel marketplace of Booking.com's shape holds the same guest email twice: once captured at checkout so the booking confirmation can be sent, once captured at newsletter sign-up. The data team wants a single golden customer record and cannot see the objection. Which data model keeps the merge lawful?
3 min answer -
advanced
A recommendation model was trained on browsing histories collected under consent. Several thousand users withdraw that consent. What happens to the model that has already learned from their data, and what makes your answer defensible?
3 min answer -
advanced
Data was collected to fulfil bookings. A team wants to use it to train a recommendation model. What determines whether that is permitted, and how is it enforced?
2 min answer
4 terms in this topic
Data Minimisation
Collecting and retaining only the personal data actually necessary for the stated purpose, treated as an architectural constraint rather than a polic…
patternObjection Register
The durable default-allow counterpart to a consent store, holding every objection and opt-out and consulted at use time by every job, because switchi…
practicePurpose Binding
Recording with the data the purpose it was collected for, and carrying that constraint through derivation, so a later use can be checked against what…
conceptPurpose Limitation
The requirement that personal data collected for one stated purpose is not used for another, which architecture enforces by binding a purpose to ever…
Neighbouring topics
Regulatory & Data Protection Architecture
General material on designing under legal and regulatory obligation.
Privacy by Design
Data minimisation, default protection and purpose binding as structural decisions.
Data Subject Rights
Access, correction, portability and erasure across systems that never planned for them.
Consent Architecture
Capturing, versioning and propagating consent to every system that acts on the data.
Data Residency
Keeping data within a jurisdiction, including backups, logs and support access.
Digital Sovereignty
Control over data, operations and the operator, beyond where the bytes physically sit.
Cross-Border Transfer
The legal mechanism that permits data to leave, and the architecture that respects it.
PCI-DSS Scoping
Segmentation and tokenisation to shrink what is in scope, because scope is the cost.
Healthcare Data Protection
PHI handling, minimum necessary access, and audit expectations in clinical systems.
Financial Services Regulation
Operational resilience, payment rules and supervisory expectations as design inputs.
Records Retention & Legal Hold
Keeping what must be kept, deleting what must go, and freezing both on demand.
Erasure vs Immutability
Deletion obligations against event logs, backups and ledgers designed never to forget.
Pseudonymisation
Separating identity from record, and the re-identification risk that remains.
Privacy-Enhancing Technologies
Differential privacy, secure enclaves and federated computation, and what each buys.
Regulatory Reporting Pipelines
Submissions with fixed deadlines, fixed formats, and a regulator who audits the lineage.
Sector Cloud Rules
Regulator expectations for cloud use, exit plans and material outsourcing notification.
Exit & Concentration Risk
Being able to leave a provider, and what the regulator asks when you cannot.
Third-Party Risk
Assessing, contracting and monitoring the vendors your architecture now depends on.
Geo-Restriction & Sanctions
Blocking access by jurisdiction, and the accuracy and evasion problems that come with it.