Chapter 4 — Data models | Technologist Security architecture and engineering

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

Chapter 4 — Data models

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 The parcel record"]
  N2["4.2 Personal data"]
  N3["4.3 Minimising fields"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 The parcel record"]
  N2["4.2 Personal data"]
  N3["4.3 Minimising fields"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 The parcel record]
    |
    v
[4.2 Personal data]
    |
    v
[4.3 Minimising fields]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) describe Brightwater's parcel data model; (2) identify personal data within it; (3) apply minimisation to data fields.

4.1 The parcel record

Tomás studies the tracking service's data model with the developer who supports it. A parcel record holds an identifier, sender, recipient name, address, phone number, weight, service level, scan events and a delivery photo. Scan events link to depots, drivers and times. Understanding the model shows how data flows and where it accumulates. Ruth asks the class to sketch entities and relationships on paper first, because a clear diagram helps everyone discuss which fields are needed, by whom and for how long.

4.2 Personal data

Tomás marks fields that identify people: recipient name, address and phone, driver identity on scan events, and delivery photos that may show a person or a house. Some fields are personal in combination, such as a delivery time and an address revealing when someone is at home. He notes which teams access each field. Customer service needs recipient contact details; depot sorters need only the postcode and service level. Mapping personal data by role shows where access is broader than any job requires.

4.3 Minimising fields

Tomás proposes changes. Sorter screens show only postcode, service level and weight. Phone numbers are hidden after delivery. Delivery photos are deleted after ninety days unless a claim is open. The developer estimates the work at two weeks. Sam supports it because fewer people seeing personal data means fewer chances of misuse and a smaller impact if a handheld is lost. Data minimisation, required by data protection law in many countries, is also one of the cheapest security controls available to a small company.

Worked example

Tomás maps the parcel data model, marks personal fields by role and proposes three minimisation changes to screens and retention.

Synthetic case. The data model is synthetic.

Errors and limits

Hidden fields may still exist in exports. Retention deletion must include backups over time.

Exercises

EX010 — Combined fields. How can delivery time and address together be personal? Rubric: 3 = they reveal when someone is home;; 2 = inference;; 1 = vague;; 0 = none.
EX011 — Sorter needs. Which fields do sorters need? Rubric: 3 = postcode, service level and weight;; 2 = postcode;; 1 = full address;; 0 = none.
EX012 — Photo retention. How long are delivery photos kept under the proposal? Rubric: 3 = ninety days unless a claim is open;; 2 = ninety days;; 1 = forever;; 0 = none.

Synthesis

Mapping personal data in the data model by role shows how to minimise exposure cheaply.

Continue studying — chapter 04 of 30

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →