OpenCyber Academy
Engineering · Chapter 22 · English
Course code: OCA-119Chapter 22: OCA-119-C022

Chapter 22 — Privacy and data protection: system and data models

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 22 published. Map, example, EX064.

flowchart TD
  N0["Learning outcomes"]
  N1["22.1 The inventory"]
  N2["22.2 Automated checks"]
  N3["22.3 Transfers"]
  N4["22.4 Research basis"]
  N5["Lab — Checking data flows for purpose, basis and tra"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX064"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["22.1 The inventory"]
  N2["22.2 Automated checks"]
  N3["22.3 Transfers"]
  N4["22.4 Research basis"]
  N5["Lab — Checking data flows for purpose, basis and tra"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX064"]

[Learning outcomes]
    |
    v
[22.1 The inventory]
    |
    v
[22.2 Automated checks]
    |
    v
[22.3 Transfers]
    |
    v
[22.4 Research basis]
    |
    v
[Lab — Checking data flows for purpose, basis and tra]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX064]

Learning outcomes

You will (1) build a data-flow inventory; (2) check each flow for purpose, lawful basis and transfers; (3) connect the inventory to the record of processing.

22.1 The inventory

Zara converts her data-flow graph into an inventory with one row per flow: source, destination, purpose, lawful basis, region and transfer mechanism. Article 30 of the GDPR requires controllers to keep a record of processing activities, including purposes, categories of recipients and transfers to third countries. An inventory at flow level is more detailed than the legal minimum, but it is what engineers need to find problems. She checks seven flows from Pellmore's platform, chosen to cover internal systems, vendors and partners. Each flow has an owner.

22.2 Automated checks

The lab applies three rules to each flow: it must have a purpose, it must have a lawful basis, and if data leave the European Economic Area it must name a transfer mechanism. Four flows pass. The analytics SDK has no purpose, no lawful basis and no transfer mechanism for its United States destination. The offshore support team has no transfer mechanism. The research extract has no lawful basis. Three of seven flows need action. Zara notes that the analytics flow, added by the app team without review, fails every rule.

22.3 Transfers

Chapter V of the GDPR restricts transfers of personal data to countries outside the EEA. Transfers need an adequacy decision or appropriate safeguards such as standard contractual clauses. The marketing email platform has clauses recorded and passes. The offshore support team has none. Zara does not decide which mechanism to use, which is a legal question, but she flags the gap with the facts lawyers need: what data, how much, how often and why. She learns that engineers make transfers visible, while counsel decides how to make them lawful.

22.4 Research basis

The research extract sends records to an internal research team without a recorded basis. Health research may rely on specific grounds such as GDPR Article 9(2)(j) together with safeguards under Article 89, or on consent. Zara asks the data protection officer to determine the basis and recommends pseudonymising the extract in the meantime. She adds a rule to the inventory process: new flows cannot be deployed until all three fields are completed and reviewed, which turns the inventory from a document into a deployment gate.

Lab — Checking data flows for purpose, basis and transfers

# Check a synthetic data-flow inventory: every flow needs a purpose, a lawful basis and, if leaving the EEA, a transfer mechanism.
flows = [
 ("app -> booking DB", "appointments", "contract", "EEA", ""),
 ("booking DB -> video vendor", "consultation", "contract", "EEA", ""),
 ("app -> analytics SDK", "", "", "US", ""),
 ("records -> lab partner", "test orders", "health care (Art 9(2)(h))", "EEA", ""),
 ("support desk -> offshore team", "support", "contract", "non-EEA", ""),
 ("records -> research extract", "research", "", "EEA", ""),
 ("marketing list -> email platform", "newsletter", "consent", "US", "SCCs"),
]
bad = 0
for name, purpose, basis, region, mech in flows:
    issues = []
    if not purpose: issues.append("no purpose")
    if not basis: issues.append("no lawful basis")
    if region != "EEA" and not mech: issues.append("no transfer mechanism")
    bad += bool(issues)
    print(f"{name:34s} {'OK' if not issues else '; '.join(issues)}")
print(f"{bad} of {len(flows)} flows need action")

Run with python3 lab_flow.py. Verified output:

app -> booking DB                  OK
booking DB -> video vendor         OK
app -> analytics SDK               no purpose; no lawful basis; no transfer mechanism
records -> lab partner             OK
support desk -> offshore team      no transfer mechanism
records -> research extract        no lawful basis
marketing list -> email platform   OK
3 of 7 flows need action

Worked example

Zara builds a seven-flow inventory and finds three needing action: the analytics SDK (no purpose, basis or transfer mechanism), offshore support (no transfer mechanism) and the research extract (no basis).

Synthetic case. Flows are synthetic; GDPR Articles 9(2)(j), 30 and 89 and Chapter V are real.

Errors and limits

An inventory reflects what people report; network captures and code scans catch unreported flows.

Exercises

Synthesis

Chapter 22 models and checks flows. Chapter 23 analyses threats and failures.

Continue studying — chapter 22 of 50

← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →

Worked answers

EX064. Three of seven; the analytics SDK fails all three rules.

EX065. Lawyers choose the mechanism; engineers supply what data move, how much, how often and why.

EX066. Deployment is blocked until a new flow has a reviewed purpose, basis and transfer mechanism.