Lesson map
Lesson 04 published. Map, example, EX010.
flowchart TD
N0["Learning outcomes"]
N1["4.1 Separating sensitive data"]
N2["4.2 Retention fields"]
N3["4.3 Modelling consent"]
N4["4.4 Reviewing the model"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX010"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["4.1 Separating sensitive data"]
N2["4.2 Retention fields"]
N3["4.3 Modelling consent"]
N4["4.4 Reviewing the model"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX010"]
[Learning outcomes]
|
v
[4.1 Separating sensitive data]
|
v
[4.2 Retention fields]
|
v
[4.3 Modelling consent]
|
v
[4.4 Reviewing the model]
|
v
[Worked example] --> [Exercise EX010]
Learning outcomes
You will (1) design data models that separate sensitive data; (2) define retention in the model; (3) model consent.
4.1 Separating sensitive data
Aisha designs a data model for Quayside's app. Member identity (name, email, phone) sits in one table; workout and heart-rate data sit in another linked by an internal identifier; marketing preferences sit in a third. She explains that separation lets each service access only what it needs. Heart-rate data may be data concerning health under GDPR Article 4(15) when used to assess fitness or health, which requires extra care under Article 9. In practice, the class screen service can read heart-rate zones and first names but cannot query emails or payment status.
4.2 Retention fields
Aisha adds a created date and a category to each record, so that retention rules can be applied. Heart-rate readings are kept for twelve months unless the member chooses to keep longer; workout summaries are kept while the account is active. She notes that designing retention into the model from the start is much easier than adding it later, when data have accumulated without dates or categories. Her retention job reads the category, compares the created date with the rule and deletes the expired rows.
4.3 Modelling consent
Quayside uses consent for marketing emails and for sharing heart-rate data with class screens. Aisha models consent as a table with member, purpose, wording version, date and status. Withdrawals change the status and the date. She explains that EDPB Guidelines 05/2020 require consent to be specific and demonstrable, which the model supports by recording what was agreed and when. A wording version matters because Quayside will change its consent text; without it, nobody can prove which text a member saw in 2025 compared with 2027.
4.4 Reviewing the model
Mr. Reilly reviews Aisha's model and asks why date of birth is stored when age bands would do. Aisha replaces it with an age band for classes and keeps the full date only in the membership system, where it is needed for contracts. He notes that each field in a data model should have a reason, and that reviewing models for unnecessary fields is an effective privacy practice. After the review she also removes gender from the app, since no feature uses it.
Worked example
Aisha separates identity, workout and marketing data, adds retention fields, models consent with wording versions and replaces date of birth with age bands in the app.
Synthetic case. The model is synthetic; GDPR Articles 4(15) and 9 and EDPB Guidelines 05/2020 are real.
Errors and limits
Age bands can still identify people in small classes; combine with other protections.
Exercises
- EX010 — Heart-rate status. When may heart-rate data be health data?
Show marking criteria
Rubric: 3 = when used to assess fitness or health, per Article 4(15);; 2 = mentions health;; 1 = never;; 0 = none. - EX011 — Consent fields. What fields does the consent table hold?
Show marking criteria
Rubric: 3 = member, purpose, wording version, date and status;; 2 = most;; 1 = few;; 0 = none. - EX012 — Date of birth. Why replace date of birth with an age band in the app?
Show marking criteria
Rubric: 3 = the app does not need the full date;; 2 = mentions need;; 1 = keep;; 0 = none.