OpenCyber AcademyLesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Access checks"]
N2["8.2 Pseudonymised analysis"]
N3["8.3 Testing"]
N4["8.4 Code review"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Access checks"]
N2["8.2 Pseudonymised analysis"]
N3["8.3 Testing"]
N4["8.4 Code review"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Access checks]
|
v
[8.2 Pseudonymised analysis]
|
v
[8.3 Testing]
|
v
[8.4 Code review]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) implement access checks; (2) pseudonymise data for analysis; (3) test privacy behaviour.
8.1 Access checks
Elena writes a small application for viewing pupil information. Before showing any record, it checks the user's role and the purpose. A teacher can see learning records for pupils in their classes; the special needs coordinator can see support plans. Requests without a valid role are refused and logged. She learns that writing checks into the code ensures the rules are applied consistently, rather than relying on staff remembering which data they should look at. Each request checks the class list.
8.2 Pseudonymised analysis
The trust wants to analyse reading progress across schools. Elena writes code that replaces pupil identifiers with pseudonyms using a keyed hash before data reach the analyst. The key is held by the data protection lead. She explains that the analyst can study progress without knowing which child is which, but that the data remain personal data under the GDPR because the key could re-identify pupils. Pseudonymisation reduces risk but does not remove legal duties. The key is stored separately from the data.
8.3 Testing
Elena writes tests that check privacy behaviour: a teacher cannot see a pupil from another class, the analysis export contains no names, and logs record each access. One test fails because a teacher who left a class still has access. She adds a rule to remove access when class assignments change. Testing privacy properties automatically finds problems that manual review would miss and keeps working as the code changes. A failing test blocks the change from being deployed. Tests run on every change, using synthetic classes only.
8.4 Code review
Elena's code is reviewed by a classmate who asks why the export includes date of birth. Elena realises it is not needed for reading progress and removes it. Dr. Asante points out that reviewers should ask what data are needed as well as whether the code works. Code review becomes a minimisation check as well as a quality check, and small removals like this add up across many programs. In one review she removes a date-of-birth field from an export. Reviewers ask why each field exists.
Worked example
Elena implements role- and class-based access checks, pseudonymises reading data with a keyed hash, finds stale class access through tests and removes date of birth after review.
Synthetic case. Code and pupils are synthetic.
Errors and limits
Keyed pseudonyms can be reversed by anyone holding the key; protect it.
Exercises
- EX022 — Class-based access. How does Elena's application decide whether a teacher sees a record?
Show marking criteria
Rubric: 3 = role and purpose checks plus class membership;; 2 = mentions role;; 1 = shows all;; 0 = none. - EX023 — Pseudonymised still personal. Why is the pseudonymised reading dataset still personal data?
Show marking criteria
Rubric: 3 = the key can re-identify pupils;; 2 = mentions key;; 1 = anonymous;; 0 = none. - EX024 — Stale access. What failed test did Elena fix?
Show marking criteria
Rubric: 3 = teachers keeping access after leaving a class;; 2 = mentions access;; 1 = vague;; 0 = none.
Synthesis
Chapter 8 implements controls. Chapter 9 studies data and databases.
Continue studying — chapter 08 of 40
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →