Chapter 14 — Privacy foundations
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Personal data in identity"]
N2["14.2 Minimisation and purpose"]
N3["14.3 Privacy in multi-factor setup"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Personal data in identity"]
N2["14.2 Minimisation and purpose"]
N3["14.3 Privacy in multi-factor setup"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Personal data in identity]
|
v
[14.2 Minimisation and purpose]
|
v
[14.3 Privacy in multi-factor setup]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) identify personal data in identity systems; (2) apply minimisation and purpose limitation; (3) respect staff privacy in monitoring.
14.1 Personal data in identity
Identity systems hold personal data: names, job titles, phone numbers for multi-factor authentication, sign-in times and locations. Logs can reveal when someone works, where they travel and how often they make mistakes. Elena lists the personal data each identity system holds and why. She discovers that the old finance system stores staff home addresses it no longer needs, which becomes a recommendation for removal, since holding data without purpose adds risk without benefit. The list is shared with Greenhill's data protection lead for review and kept up to date.
14.2 Minimisation and purpose
Two privacy principles guide her work. Minimisation means collecting only what a purpose needs; purpose limitation means using data only for the purpose it was collected for. Sign-in logs are collected for security; using them to judge staff productivity would be a different purpose and would breach staff trust. Elena writes a short statement, agreed with HR and staff representatives, saying identity logs are used for security and troubleshooting only, which reassures staff worried about being watched. The statement is published on the staff intranet.
14.3 Privacy in multi-factor setup
Some multi-factor methods require a personal phone. Not all staff want to use their own phone for work, and some do not have a suitable one. Elena recommends offering alternatives, such as a security key provided by Greenhill, so nobody is forced to use personal devices. This respects privacy and also helps adoption: in her data, the repairs team's low multi-factor rate partly reflects operatives without work phones, a problem a provided key solves. Keys are issued and recorded by IT, and lost keys are reported and replaced quickly.
Worked example
Elena lists personal data in six systems, finds unneeded home addresses in finance, and drafts a log-use statement agreed with HR and staff representatives.
Synthetic case. Data fields and agreements are synthetic.
Errors and limits
Using security logs to judge productivity breaks purpose limitation and staff trust.
Exercises
- EX040 — Unneeded data. What unneeded personal data did Elena find? Rubric: 3 = staff home addresses in finance;; 2 = addresses;; 1 = vague;; 0 = none.
- EX041 — Purpose example. Why not use sign-in logs to judge productivity? Rubric: 3 = different purpose, breaks purpose limitation and trust;; 2 = purpose;; 1 = allowed;; 0 = none.
- EX042 — Phone alternative. What alternative to personal phones does Elena recommend? Rubric: 3 = Greenhill-provided security keys;; 2 = keys;; 1 = vague;; 0 = none.
Synthesis
Minimisation, purpose limitation and alternatives to personal phones make identity systems respectful of staff privacy.
Continue studying — chapter 14 of 40
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →