Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes and connection"]
N1["14.1 Principles"]
N2["14.2 Incident records contain personal data"]
N3["14.3 Minimization in practice"]
N4["14.4 Retention"]
N5["14.5 Access and rights interfaces"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["14.1 Principles"]
N2["14.2 Incident records contain personal data"]
N3["14.3 Minimization in practice"]
N4["14.4 Retention"]
N5["14.5 Access and rights interfaces"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX040"]
[Learning outcomes and connection]
|
v
[14.1 Principles]
|
v
[14.2 Incident records contain personal data]
|
v
[14.3 Minimization in practice]
|
v
[14.4 Retention]
|
v
[14.5 Access and rights interfaces]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes and connection
You will be able to (1) apply purpose limitation, data minimization and storage limitation to incident records; (2) design a minimized case record; (3) control access to case data; and (4) identify decisions that require privacy or legal specialists. Chapter 10 set the ethical frame; this chapter adds data-protection principles. Chapter 32 covers notification and communications.
14.1 Principles
Data-protection law in many jurisdictions shares core principles. The EU General Data Protection Regulation (GDPR), Article 5, lists lawfulness, fairness and transparency; purpose limitation; data minimization ("adequate, relevant and limited to what is necessary"); accuracy; storage limitation; integrity and confidentiality; and accountability. Brazil's LGPD (Law 13.709/2018) and other laws use similar ideas. Security and incident handling is usually a legitimate purpose, but it does not license unlimited collection.
In the phishing case these principles become concrete questions: does answering which staff entered credentials require home addresses? It does not, so they are not copied.
14.2 Incident records contain personal data
Sign-in logs contain user names and addresses; mail logs contain correspondents; screenshots contain whatever was on screen. Incident records are themselves a privacy risk: they gather sensitive data from many systems into one place, often with weaker access controls.
The phishing case bundle shows how quickly this happens: a directory export with home addresses, a month of sign-ins for 400 staff and inbox screenshots, gathered in one folder for a question about 12 recipients. Treat the case folder as a sensitive system in its own right, with named access, an owner and a deletion date, rather than as a scratch area that anyone on the team can browse.
14.3 Minimization in practice
Collect what the question needs. Prefer metadata over content, samples over full exports, pseudonyms over names in working analyses, and aggregate counts in reports. Keep a mapping table (pseudonym → identity) separately with tighter access. Minimization must not destroy evidence: preserve originals under restricted access when there is a legitimate need, and work on minimized copies.
In the phishing case, the filter to 12 recipients and 48 hours answers the question while excluding almost all of the 400 staff. Screenshots are redacted before analysis, and recipients appear only as pseudonyms in the workbook. The full export, if kept at all, sits under restricted access with a reason recorded.
14.4 Retention
Decide how long case data is kept and why: legal holds may require longer retention for specific records; otherwise delete or anonymize on schedule. Record the decision.
For the phishing case, the decision might read: analysis workbook kept until the case closes plus a stated review period, mapping table deleted at the same time, original sign-in export retained only if the privacy office places a hold. Each item has its own reason and date. Record who made the decision, because a later reviewer will ask why data still exists or why it is gone. A retention rule that nobody owns tends to become keep forever, which quietly turns an old incident into a new privacy risk.
14.5 Access and rights interfaces
Limit case access to roles that need it. People have rights (access, correction, erasure in some cases) that may apply to incident records; requests should be routed to the privacy office, which knows the exemptions and deadlines. The responder's job is to make the data findable and to flag sensitive content, not to answer legal questions.
Keep the case folder's access list short and review it at closure. In the phishing case, only the case lead holds the mapping from P01 to P12 back to names, so analysts work on pseudonyms by default.
14.6 Worked example (synthetic): a minimized case record
Fictional. A case bundle contains: a staff directory export (names, phone numbers, home addresses), 30 days of sign-in logs for 400 staff, and screenshots of a phishing email received by 12 staff.
Question: which staff entered credentials into the phishing page?
Minimized record: sign-in logs filtered to the 12 recipients and the 48 hours after delivery; directory fields reduced to account name, department and work phone (for contacting affected users); screenshots redacted to remove other messages visible in the inbox; recipient names replaced by pseudonyms P01–P12 in the analysis workbook, with the mapping held by the case lead. Home addresses are not needed and are not copied. Items for specialist review: whether any affected account has access to patient records (possible notification analysis); retention period for the bundle; whether any recipient is in a jurisdiction with different rules.
14.7 Common errors and limits
- Copying whole exports "for completeness".
- Sharing unredacted screenshots in chat channels.
- Pseudonymizing but storing the key beside the data.
- Treating privacy as a final review step instead of a design input.
-
This chapter is not legal advice; laws differ and change.
-
Keeping the pseudonym mapping after the case closes, which preserves re-identification long after the need has passed.
- Forgetting that a filtered extract can still identify people, for example when one of the 12 recipients is the only member of a small department.
- Answering a person's access request yourself instead of routing it to the privacy office.
Exercises — chapter 14
Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.
EX040 — Minimize a request. Inputs: "Export all mailbox contents of the finance team for the last year" to investigate a suspected invoice-fraud email. Steps: propose a minimized alternative that still answers the question. Rubric: 3 = message-trace metadata for the period around the fraud, search for the specific sender/subject, content review only of matching messages under approval; 2 = partially minimized; 1 = accepts; 0 = none.
EX041 — Pseudonymization design. Steps: describe how to pseudonymize user names in an analysis spreadsheet so that analysts can still join records, and where the key lives. Rubric: 3 = consistent mapping (keyed hash or table), key held separately with restricted access, note that pseudonymized data is still personal data; 2 = missing key separation; 1 = deletes names, breaking joins; 0 = none.
EX042 — Specialist routing. Inputs: §14.6. Steps: list three decisions you would route to privacy or legal staff and the facts you would give them. Rubric: 3 = notification analysis (data types, number of people, confidence), retention/legal hold, cross-border issues; facts are fact-limited; 2 = two; 1 = none specific; 0 = none.
Chapter synthesis
Incident records are personal data. Collect for the question, minimize the working copy, separate re-identification keys, set retention deliberately and route legal judgements to specialists with fact-limited inputs.