Chapter 19 — Privacy and data protection: monitoring
Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 What to monitor"]
N2["19.2 Alerts"]
N3["19.3 Trends"]
N4["19.4 Review"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["19.1 What to monitor"]
N2["19.2 Alerts"]
N3["19.3 Trends"]
N4["19.4 Review"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 What to monitor]
|
v
[19.2 Alerts]
|
v
[19.3 Trends]
|
v
[19.4 Review]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) monitor privacy controls; (2) set alerts; (3) review trends.
19.1 What to monitor
Aisha monitors CCTV retention at all clubs, SDK changes in each app release, access request deadlines and former-staff accounts. She chooses these because each has already failed once or is likely to drift. CCTV deletion failed after a firmware update, SDKs arrive with releases, request deadlines are legal obligations and staff turnover is high. She avoids monitoring everything, because a small set of meaningful signals is easier to act on than a large dashboard nobody reads. Four signals fit on one page.
19.2 Alerts
She sets alerts: footage older than thirty-five days, any new SDK, requests within five days of deadline and accounts not removed within two days of leaving. The thresholds include a small margin so that normal timing variations do not trigger alerts. CCTV alerts go to the club manager and IT; SDK alerts go to the app lead and the data protection officer; deadline alerts go to the response team; account alerts go to HR and IT. Each alert message says what to do, not only what happened.
19.3 Trends
After three months, former-staff accounts fall from forty to two, and all clubs meet CCTV retention. Access requests are all answered on time, though vendor searches remain the slowest step. One club's CCTV alert fires once after another firmware update, and the fix takes a day instead of six weeks. Aisha notes that the trend data now show the controls working, which is stronger evidence than a statement that a policy exists. Members' complaints about marketing emails also fall to zero over the same period.
19.4 Review
She reviews alerts monthly to remove noise. Mr. Reilly notes that monitoring keeps fixes from silently failing, as the CCTV firmware issue showed. In the first month, the SDK alert fires for every minor library update, so she changes it to fire only when a library sends data to a new domain. She records every change to alert rules with a reason, so that reviewers can see whether monitoring was weakened for convenience or improved for accuracy. The SDK alert drops from forty a month to two.
Worked example
Aisha monitors four controls with alerts, sees stale accounts fall from forty to two and all clubs meet CCTV retention.
Synthetic case. Results are synthetic.
Errors and limits
Too many alerts cause people to ignore them.
Exercises
- EX055 — CCTV alert. What triggers the CCTV alert? Rubric: 3 = footage older than thirty-five days;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX056 — Account trend. How did former-staff accounts change? Rubric: 3 = from forty to two;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX057 — Monitoring purpose. Why monitor fixed controls? Rubric: 3 = fixes can silently fail;; 2 = mentions failure;; 1 = vague;; 0 = none.
Continue studying — lesson 19 (chapter 19 of 30)
← Chapter 18 · Course chapter index · Chapter 20 →
Continue to the next authored lesson.