Chapter 13 — Privacy and data protection: risk scenarios
Lesson map
Lesson 13 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["13.1 Scenarios"]
N2["13.2 Ratings"]
N3["13.3 Treatments"]
N4["13.4 Owners"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["13.1 Scenarios"]
N2["13.2 Ratings"]
N3["13.3 Treatments"]
N4["13.4 Owners"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]
[Learning outcomes]
|
v
[13.1 Scenarios]
|
v
[13.2 Ratings]
|
v
[13.3 Treatments]
|
v
[13.4 Owners]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) write risk scenarios for member data; (2) rate likelihood and impact; (3) choose treatments.
13.1 Scenarios
Aisha writes scenarios: heart-rate data leaked to advertisers; CCTV footage of changing-room corridors accessed by staff; member lists photographed and shared; app account taken over. Each scenario names who acts, what they do, which data are affected and what harm follows. For example, a reception employee curious about a neighbour views CCTV clips of her arrivals and shares them, causing embarrassment and distress. Writing scenarios this way helps managers recognise risks in their own clubs rather than treating privacy as an abstract legal matter.
13.2 Ratings
She rates each on likelihood and impact from one to three. Heart-rate leakage and account takeover rate highest. Likelihood considers how often similar events happen and how easy they are. Impact considers harm to members, such as distress, discrimination or financial loss, rather than only harm to Quayside. Heart-rate leakage scores high on impact because health data can affect insurance or employment. Account takeover scores high on likelihood because member passwords are often reused from other services. Both therefore rate three by three.
13.3 Treatments
Treatments include SDK review, CCTV access logging, staff guidance and multi-factor login for the app. She chooses treatments that reduce likelihood or impact. SDK review reduces the chance of new leaks. CCTV access logging deters misuse and makes it detectable. Staff guidance reduces photographed lists. Optional multi-factor login protects app accounts. She records the residual risk after each treatment, and accepts that some risk remains, such as members choosing weak passwords despite advice. Residual risk for heart-rate leakage falls from high to medium after SDK review.
13.4 Owners
Each treatment gets an owner and date. Mr. Reilly notes that scenarios help non-specialists understand risks. Owners are people with authority to act, not committees. The app lead owns SDK review and login changes; the operations director owns CCTV logging; the training manager owns staff guidance. Dates are realistic and agreed with owners. Aisha reviews the list each month and reports overdue items to the data protection officer, who can escalate them to the leadership team. Each item shows its target date beside it.
Worked example
Aisha writes four scenarios, rates heart-rate leakage and account takeover highest and assigns treatments with owners.
Synthetic case. Scenarios are synthetic.
Errors and limits
Ratings are subjective; discuss them with colleagues.
Exercises
- EX037 — Highest scenarios. Which scenarios rate highest? Rubric: 3 = heart-rate leakage and account takeover;; 2 = one;; 1 = vague;; 0 = none.
- EX038 — CCTV treatment. What treatment addresses CCTV misuse? Rubric: 3 = access logging;; 2 = mentions logging;; 1 = vague;; 0 = none.
- EX039 — Scenario value. Why use scenarios? Rubric: 3 = they help non-specialists understand risks;; 2 = mentions understanding;; 1 = vague;; 0 = none.
Continue studying — lesson 13 (chapter 13 of 30)
← Chapter 12 · Course chapter index · Chapter 14 →
Continue to the next authored lesson.