Learn GDPR engineering vocabulary: right to erasure across all systems including backups, data portability API, DPA breach notification within 72 hours, pseudonymisation vs. anonymisation — for privacy-compliant engineering.
0 / 5 completed
1 / 5
The privacy engineer explains: 'The right to erasure requires deleting PII from all systems, including backups.' Why is 'including backups' significant?
GDPR's right to erasure (also called the 'right to be forgotten') requires organisations to delete a data subject's personal data upon request, where no other legal basis for retention exists. Critically, this applies across all systems where the data is stored — including database backups, data warehouse snapshots, log archives, and analytics pipelines. Engineering erasure that covers backups is technically challenging but legally required.
2 / 5
The backend developer says: 'The data portability API returns all user data in a structured, machine-readable format.' What GDPR right does this implement?
GDPR Article 20 grants the right to data portability: users can request a copy of their personal data in a structured, commonly-used, machine-readable format (such as JSON or CSV). They can also request that this data be transmitted directly to another data controller. Engineering a data portability API that generates a complete, accurate export of a user's data is a common GDPR compliance task.
3 / 5
The incident response plan states: 'The DPA must be notified within 72 hours of a breach.' What does this mean?
GDPR Article 33 requires organisations to notify their supervisory authority (the Data Protection Authority, or DPA, in the relevant EU member state) within 72 hours of becoming aware of a personal data breach — unless the breach is unlikely to result in a risk to individuals. This 72-hour clock starts from awareness, not discovery. If notification cannot be made within 72 hours, a partial notification must be sent with an explanation of the delay.
4 / 5
The data architect asks: 'Are we using pseudonymisation or anonymisation for this analytics dataset?' What is the key difference?
Pseudonymisation replaces direct identifiers (like name or email) with a pseudonym (e.g., a random UUID), but the mapping between pseudonym and real identity is stored separately. If someone has the key, they can re-identify the data — so pseudonymised data is still personal data under GDPR. Anonymisation irreversibly removes the ability to identify individuals; truly anonymised data is outside GDPR's scope. Most 'anonymised' analytics data is actually pseudonymised.
5 / 5
The privacy review comment reads: 'This feature stores user location history — we need a lawful basis for processing.' What is a 'lawful basis for processing' under GDPR?
Under GDPR Article 6, every act of processing personal data must have a lawful basis. The six lawful bases are: (1) consent, (2) contract (processing necessary to fulfil a contract with the user), (3) legal obligation, (4) vital interests, (5) public task, and (6) legitimate interests. Organisations must identify and document the lawful basis before processing personal data. Without a lawful basis, the processing is unlawful under GDPR.