Chapter 25 — Privacy and data protection | Technologist Identity and access management

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 25 — Privacy and data protection

Lesson map

Lesson 25 published. Map, example, EX073.

flowchart TD
  N0["Learning outcomes"]
  N1["25.1 Personal data"]
  N2["25.2 Minimisation"]
  N3["25.3 Access requests"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 Personal data"]
  N2["25.2 Minimisation"]
  N3["25.3 Access requests"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 Personal data]
    |
    v
[25.2 Minimisation]
    |
    v
[25.3 Access requests]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) explain personal data in identity systems; (2) apply data minimisation; (3) respond to access requests.

25.1 Personal data

Identity systems hold staff names, contact details, job roles, sign-in times and locations. These are personal data protected by data protection law. Kai lists what each identity system holds and why. He finds the directory stores staff home addresses copied from HR, which no identity process uses. He explains to the practice manager that collecting data without a need increases privacy risk and the harm of any breach, without adding protection. He also lists who can see each type of data. The list is reviewed yearly.

25.2 Minimisation

Kai removes home addresses from the directory, keeping them in HR only, and reduces the attributes copied by provisioning to those used for access: name, role, clinic, start and end dates and employment type. He documents why each attribute is needed. Minimisation reduces what could be exposed, and makes it easier to explain to staff what is kept about them and for what purpose, supporting trust in the monitoring described earlier. Kai checks that no process breaks after the change. Reports and scripts still work.

25.3 Access requests

Staff can ask what data Fernhill holds about them. Kai prepares a simple process for identity data: export the person's directory record, group memberships and recent sign-in records, checked by the practice manager before release so other people's data is not included. A first test with a volunteer takes two hours. A prepared process means requests are answered accurately and on time rather than in a rush. He also adds requests to the privacy runbook. The response deadline is noted. The practice manager approves each release.

Worked example

Home addresses are removed from the directory; provisioning copies six attributes; a test access request is answered in two hours.

Synthetic case. Data and processes are synthetic.

Errors and limits

Copying all HR fields into the directory exposes data no access process uses.

Exercises

EX073 — Unneeded data. What unneeded data did the directory hold? Rubric: 3 = staff home addresses;; 2 = addresses;; 1 = roles;; 0 = none.
EX074 — Attribute count. How many attributes does provisioning now copy? Rubric: 3 = six;; 2 = 6;; 1 = twenty;; 0 = none.
EX075 — Request check. Why check the export before release? Rubric: 3 = exclude other people's data;; 2 = others;; 1 = speed;; 0 = none.

Synthesis

Minimising identity data and preparing access requests protects staff privacy.

Continue studying — chapter 25 of 30

← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →