Learn the vocabulary of privacy by design: data minimisation, purpose limitation, privacy defaults, and DPIA language.
0 / 18 completed
1 / 18
Privacy by Design means:
Privacy by Design (PbD) treats privacy as a foundational requirement — it is built into the system architecture from the start, not retrofitted after launch.
2 / 18
The GDPR 'purpose limitation' principle means:
Purpose limitation (Article 5(1)(b)) requires that data be used only for the specific purpose it was collected for. Using it for a new purpose requires a separate legal basis.
3 / 18
A Data Protection Impact Assessment (DPIA) is required when:
DPIAs are mandatory for processing likely to cause high risk to individuals — such as profiling, large-scale health data processing, or systematic public monitoring.
4 / 18
In a DPIA, 'residual risk' refers to:
After applying all feasible risk mitigation measures, residual risk is what remains. If residual risk is high and cannot be reduced, the supervisory authority must be consulted before proceeding.
5 / 18
Pseudonymisation differs from anonymisation in that:
Pseudonymous data replaces direct identifiers with pseudonyms but retains a mapping table — it remains personal data under GDPR. Truly anonymous data has no way to re-identify individuals.
6 / 18
Reviewer: 'I noticed you're logging every user interaction with the new API endpoint. While functional, this seems excessive. Shouldn't we be focusing on *only* recording actions related to core transaction processing?
Developer (responding in a PR comment): I considered that during design but wanted to capture broader usage patterns for analytics and debugging.
Which of the following best describes the Developer's response in relation to Privacy by Design?
The correct answer highlights the core principle of 'purpose limitation' within Privacy by Design. The developer isn't simply *removing* data; they are consciously defining a specific purpose (analytics and debugging) for the logging and only collecting data relevant to that purpose. Options A is too rigid – anticipating future needs is a crucial aspect, and option C correctly identifies this proactive consideration. Option D misinterprets GDPR, which focuses on limiting *current* purposes, not guaranteeing privacy through excessive logging.
7 / 18
PR Description:
"Implemented API endpoint for user profile updates. Logging all events for monitoring and debugging purposes."
During a code review, Senior Developer Sarah asks the Junior Developer Mark: "Are you sure we need to log *every* update event? It feels like we're collecting a lot of potentially sensitive data here. How does this align with our Privacy by Design principles?"
Mark replies: "Yeah, I know it's verbose, but it'll be really helpful for troubleshooting and identifying any unexpected behaviour."
The correct answer highlights that Mark's response demonstrates an awareness of the core principle of *proportionate data collection* within Privacy by Design. The key misconception is that simply 'considering' something during design automatically fulfills a privacy requirement; it needs to be actively addressed with a focus on minimizing unnecessary data collection and its associated risks. Options A and D misrepresent Mark's response, while option C acknowledges the issue but doesn't capture the nuanced understanding required of Privacy by Design.
8 / 18
Reviewer: 'I noticed you're logging every user interaction with the new API endpoint. While functional, this seems excessive. Shouldn't we be focusing on *only* recording actions related to core transaction processing?
Developer (responding in a PR comment): I considered that during design but wanted to capture broader usage patterns for analytics and debugging.
Which of the following best describes the Developer's response in relation to Privacy by Design?
The correct answer highlights the core principle of 'purpose limitation' within Privacy by Design. The developer isn't simply *removing* data; they are consciously defining a specific purpose (analytics and debugging) for the logging and only collecting data relevant to that purpose. Options A is too rigid – anticipating future needs is a crucial aspect, and option C correctly identifies this proactive consideration. Option D misinterprets GDPR, which focuses on limiting *current* purposes, not guaranteeing privacy through excessive logging.
9 / 18
PR Description:
"Implemented API endpoint for user profile updates. Logging all events for monitoring and debugging purposes."
During a code review, Senior Developer Sarah asks the Junior Developer Mark: "Are you sure we need to log *every* update event? It feels like we're collecting a lot of potentially sensitive data here. How does this align with our Privacy by Design principles?"
Mark replies: "Yeah, I know it's verbose, but it'll be really helpful for troubleshooting and identifying any unexpected behaviour."
The correct answer highlights that Mark's response demonstrates an awareness of the core principle of *proportionate data collection* within Privacy by Design. The key misconception is that simply 'considering' something during design automatically fulfills a privacy requirement; it needs to be actively addressed with a focus on minimizing unnecessary data collection and its associated risks. Options A and D misrepresent Mark's response, while option C acknowledges the issue but doesn't capture the nuanced understanding required of Privacy by Design.
10 / 18
Reviewer: 'I noticed you're logging every user interaction with the new API endpoint. While functional, this seems excessive. Shouldn't we be focusing on *only* recording actions related to core transaction processing?
Developer (responding in a PR comment): I considered that during design but wanted to capture broader usage patterns for analytics and debugging.
Which of the following best describes the Developer's response in relation to Privacy by Design?
The correct answer highlights the core principle of 'purpose limitation' within Privacy by Design. The developer isn't simply *removing* data; they are consciously defining a specific purpose (analytics and debugging) for the logging and only collecting data relevant to that purpose. Options A is too rigid – anticipating future needs is a crucial aspect, and option C correctly identifies this proactive consideration. Option D misinterprets GDPR, which focuses on limiting *current* purposes, not guaranteeing privacy through excessive logging.
11 / 18
PR Description:
"Implemented API endpoint for user profile updates. Logging all events for monitoring and debugging purposes."
During a code review, Senior Developer Sarah asks the Junior Developer Mark: "Are you sure we need to log *every* update event? It feels like we're collecting a lot of potentially sensitive data here. How does this align with our Privacy by Design principles?"
Mark replies: "Yeah, I know it's verbose, but it'll be really helpful for troubleshooting and identifying any unexpected behaviour."
The correct answer highlights that Mark's response demonstrates an awareness of the core principle of *proportionate data collection* within Privacy by Design. The key misconception is that simply 'considering' something during design automatically fulfills a privacy requirement; it needs to be actively addressed with a focus on minimizing unnecessary data collection and its associated risks. Options A and D misrepresent Mark's response, while option C acknowledges the issue but doesn't capture the nuanced understanding required of Privacy by Design.
12 / 18
Reviewer: 'I noticed you're logging every user interaction with the new API endpoint. While functional, this seems excessive. Shouldn't we be focusing on *only* recording actions related to core transaction processing?
Developer (responding in a PR comment): I considered that during design but wanted to capture broader usage patterns for analytics and debugging.
Which of the following best describes the Developer's response in relation to Privacy by Design?
The correct answer highlights the core principle of 'purpose limitation' within Privacy by Design. The developer isn't simply *removing* data; they are consciously defining a specific purpose (analytics and debugging) for the logging and only collecting data relevant to that purpose. Options A is too rigid – anticipating future needs is a crucial aspect, and option C correctly identifies this proactive consideration. Option D misinterprets GDPR, which focuses on limiting *current* purposes, not guaranteeing privacy through excessive logging.
13 / 18
PR Description:
"Implemented API endpoint for user profile updates. Logging all events for monitoring and debugging purposes."
During a code review, Senior Developer Sarah asks the Junior Developer Mark: "Are you sure we need to log *every* update event? It feels like we're collecting a lot of potentially sensitive data here. How does this align with our Privacy by Design principles?"
Mark replies: "Yeah, I know it's verbose, but it'll be really helpful for troubleshooting and identifying any unexpected behaviour."
The correct answer highlights that Mark's response demonstrates an awareness of the core principle of *proportionate data collection* within Privacy by Design. The key misconception is that simply 'considering' something during design automatically fulfills a privacy requirement; it needs to be actively addressed with a focus on minimizing unnecessary data collection and its associated risks. Options A and D misrepresent Mark's response, while option C acknowledges the issue but doesn't capture the nuanced understanding required of Privacy by Design.
14 / 18
Reviewer: 'I'm seeing a lot of detailed logging in this service. While it provides valuable debugging information, are we explicitly defining what constitutes *necessary* data for auditing purposes? Could we reduce the volume to only capture events directly related to core user authentication and authorization flows?' Mark replies: 'I added this logging as a precautionary measure to catch any unexpected behavior.' What is the primary concern raised by the reviewer regarding Mark's approach?
logging.level = 'debug';
The reviewer is highlighting the potential issue of 'scope creep' – logging more data than strictly necessary. GDPR's purpose limitation principle dictates that data should only be collected for specific, defined purposes. Excessive logging can lead to increased risk and complexity without a clear benefit, violating this core concept. Option A accurately identifies this concern.
15 / 18
Senior Developer Anya sends the following message in a team channel: 'Just noticed we're storing full user IP addresses in our analytics database. This is going beyond what's needed for basic usage statistics – it's potentially sensitive information. We should explore options to mask or anonymize this data.' What does Anya mean by 'anonymize' in this context?
#anonymization
Anya is referring to anonymization, which involves transforming data so that individuals can no longer be identified. This differs from pseudonymisation (which uses identifiers) and full deletion. The key goal is to reduce the risk of re-identification while still retaining some analytical utility – crucial for privacy by design.
16 / 18
PR Description:
"Implemented a new feature allowing users to track their order status in real-time. Logging all API calls and database queries for performance monitoring."
During the code review, Lead Developer David asks: 'We're logging every API call – that's quite verbose. How does this align with our Privacy by Design strategy regarding data minimization?' What is David's core concern?
#data_minimization
David's question directly addresses the principle of data minimization. Logging *every* API call generates significantly more data than might be needed for performance monitoring – increasing the risk associated with storing and processing that information. It's a classic example of collecting unnecessary data when only core metrics are required.
17 / 18
Junior Developer Ben reports to the stand-up: 'I've been implementing a new user consent management system. I'm logging every change made to user preferences, including timestamps and IP addresses, for audit trails.' Senior Security Engineer Chloe responds: 'That's great, Ben, but are we considering the *residual risk* associated with storing that level of detail? What's our plan to mitigate potential breaches?' What does Chloe mean by 'residual risk'?
#residual_risk
'Residual risk' refers to the remaining risk that remains *after* you've implemented your security controls. It acknowledges that no system is perfectly secure and there will always be a degree of vulnerability left over – this needs to be actively managed and monitored.
18 / 18
Which statement best describes the key difference between pseudonymisation and anonymisation?
#pseudonymisation vs anonymisation
The core distinction lies in the ability to re-identify individuals. Pseudonymised data uses a key or algorithm to link identifiers to personal details – if that key is compromised, re-identification becomes possible. Anonymised data, on the other hand, has been irreversibly transformed so it *cannot* be linked back to an individual.
What does the "Privacy by Design Language" exercise practise?
Learn the vocabulary of privacy by design: data minimisation, purpose limitation, privacy defaults, and DPIA language.
How many questions are in this exercise?
This exercise has 18 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Data Privacy category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Privacy by Design Language" part of a larger series?
Yes — it's one exercise in the Data Privacy category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Data Privacy category page for related exercises, or browse the main Exercises hub for other IT English topics.