OpenCyber Academy
Bachelor's · Chapter 14 · English
Course code: OCA-108Chapter 14: OCA-108-C014

Chapter 14 — Privacy foundations

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

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

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.

Worked answers

EX040. Use message-trace metadata (sender, recipient, subject, time) for finance mailboxes in a window around the fraudulent invoice; search for the known sender domain, subject and attachment hash; open only the matching messages, under the incident lead's approval; document why each opened message was needed. This answers who received or replied to the fraud email without reading a year of unrelated mail.

EX041. Generate pseudonyms with a keyed hash (for example HMAC-SHA-256 with a secret key held by the case lead) or a random mapping table; apply the same mapping to every dataset so joins still work; store the key or table in a separate, access-controlled location; record who can re-identify and why. Pseudonymized data remains personal data under GDPR, so access controls still apply.

EX042. (1) Whether the event requires notification to regulators or individuals: give data types possibly exposed, number of people, evidence of access versus exfiltration, and confidence. (2) Retention and legal hold: the bundle's contents and whether litigation or regulatory inquiry is foreseeable. (3) Cross-border transfer or jurisdiction issues: where the affected people are and where data is stored. The responder supplies facts and uncertainties; specialists decide.