Purpose limitation means personal data collected for one purpose should not be used for an incompatible one. Engineers can make this visible by tagging each field and dataset with its purposes, checking those tags when a new feature reads the data, and sending any new use through review before it ships.
What the principle says
Article 5(1)(b) of GDPR says personal data must be collected for specified, explicit and legitimate purposes and not further processed in a manner incompatible with those purposes. Article 5(2) adds accountability: you must be able to demonstrate compliance.
Reuse is where most trouble starts: shipping addresses collected for delivery that end up in a marketing audience, or support transcripts that feed a model without anyone deciding whether that fits.
Define a short purpose list
Agree a vocabulary with your privacy lead. Ten items cover most products, for example:
account_servicebillingsecurity_and_fraudproduct_analyticsmarketingsupportlegal_obligation
Each purpose links to a description, a lawful basis decided by the right owner, and a retention period. Keep the list short, or nobody will use it.
Tag the data
Add purposes to your data map and, where possible, to the schema itself: a column comment, a metadata file or a catalogue tag. A column that holds a phone number might carry account_service and security_and_fraud, but not marketing.
Check at use
Tags only matter if something reads them. Options, from light to strong:
- Review. A pull request that queries a tagged column for a new feature must state its purpose, and the reviewer compares it with the tags.
- Lint and CI. A check flags code that reads columns whose tags do not include the declared purpose of the job or service.
- Runtime enforcement. A data access layer takes a purpose argument and refuses reads that do not match. This suits sensitive data and shared platforms.
Start with review. Add automation where reuse risk is highest, such as the analytics warehouse.
Handle new purposes
When a team wants to use existing data in a new way, ask:
- Is it compatible with the original purpose? Article 6(4) lists factors such as the link between purposes, context, nature of the data and safeguards.
- Does it need a new lawful basis or fresh consent?
- Do people need to be told?
- Is minimisation still met?
Record the answer, whatever it is, in the data map.
Machine learning and analytics
Training a model on support tickets or usage data is a new purpose in most cases. Decide it deliberately, before the pipeline runs, and tag the resulting datasets too.
Quick check
Is internal reuse of data allowed?
Only for purposes compatible with the original one, or with a fresh basis. Assess and record it.
Do I need runtime enforcement?
Not at first. Review and tags give most of the benefit. Add enforcement for the datasets where reuse would be costly.
Sources
Last reviewed: 19 October 2026.
