2 Privacy and Compliance Route Map

2.2 Start With the Story

Imagine a smart building app that says it only uses occupancy data to lower heating costs. A reviewer should be able to follow that claim from the sensor event to the gateway, dashboard, retention rule, support role, deletion behavior, and evidence record. If raw motion events later feed a new analytics model, the old privacy answer is no longer enough.

That is the plain-language goal of this route. Treat privacy compliance as a product story with proof: name the data, state the purpose, reduce what is collected, protect what remains, and write down what would make the team review the decision again. The regulations matter, but they become useful only after the data story is visible.

2.3 Learning Objectives

By the end of this module route, you will be able to:

• Map an IoT data flow from device collection to downstream use.
• Separate data purpose, consent or notice, retention, access, sharing, and deletion questions.
• Recognize privacy risks in mobile sensing, location data, identifiers, telemetry, and inferred behavior.
• Connect safeguards and zero-trust boundaries to privacy outcomes.
• Build a review record that supports audits and change review.
• Route yourself to the right privacy, safeguard, or zero-trust chapter.

2.4 Prerequisites

You should already be comfortable with device data flows, application protocols, authentication basics, and network segmentation. Useful refreshers include IoT Protocols Overview, Authentication and Access Control, and Encryption Principles.

2.5 Module Route

Use Figure 2.1 as a route through privacy and compliance work, not as a list of disconnected controls. Begin with the data map and follow the review as risk and evidence become more specific.

Read Figure 2.1 from data flows into privacy principles, then through mobile risks and Privacy by Design choices. Safeguards and zero-trust boundaries protect the justified path, while the review record preserves purpose, evidence, limits, ownership, and reopening conditions. The route connects the module’s chapter groups to one continuing task: prove that each data use remains necessary, bounded, protected, and reviewable.

2.6 Data Lifecycle

Privacy review starts with data movement. Use Figure 2.2 to inspect every state in which a control can fail or a purpose can quietly expand.

Follow Figure 2.2 from collection through transformation, transmission, storage, use, and sharing. Then inspect retention and deletion as operational states rather than policy words, and finish at review, which reopens the record when data or purpose changes. A safeguard at one stage cannot stand in for the others. The ordered questions below turn each lifecycle transition into evidence a reviewer can request.

Apply the lifecycle as a connected review sequence. First, collect by stating what the device, sensor, gateway, application, or interface captures. Next, transform by recording filtering, aggregation, labelling, inference, pseudonymisation, or feature extraction. Then transmit by tracing device, gateway, cloud, mobile, partner, and operational paths, and store by naming stores, retention needs, backups, and access groups. Connect each use to a stated purpose, identify every internal or external share, and define what delete or retain means across live systems, logs, backups, exports, and derived records. Finally, review the record whenever data, purpose, region, user group, or safeguard changes.

2.7 Review Questions

The quickest way to improve a privacy chapter or design review is to ask consistent questions. Inspect the board in Figure 2.3 so necessity comes before safeguards and evidence.

Read Figure 2.3 from data and purpose into notice, choice, and access. Continue through retention and sharing boundaries before asking which safeguard reduces the identified risk and which artifact proves that behavior. This order prevents a control inventory from replacing the privacy argument. The record fields that follow preserve the answers so later changes can be compared against the original decision.

2.8 Chapter Groups

Choose the chapter group that matches the review question in front of you. Inspect the map in Figure 2.4 to move from foundational vocabulary toward design, safeguards, boundaries, and synthesis without skipping the data question.

In Figure 2.4, begin with introductions when purpose, personal data, or inference is unclear. Move to mobile privacy for phone and radio exposure, Privacy by Design for architectural choices, safeguards for control evidence, and zero trust for repeated boundary checks. Synthesis reconnects those views in one review. The next map focuses on safeguards while keeping that wider route visible.

2.9 Safeguard Map

Controls should connect to a privacy risk, not float as a generic security checklist. Use Figure 2.5 to trace each control family back to the exposure it reduces and the evidence it should leave.

Read Figure 2.5 from reduction to protection, observation, and deletion. Reduction removes unnecessary exposure; protection constrains justified data; observation reveals misuse or drift; deletion ends the approved lifetime. Review triggers reconnect the map when any assumption changes. This makes safeguards a lifecycle argument rather than a shopping list, and it supplies the control and evidence fields in the review record below.

2.10 Privacy Review Record

Use a record when a design, lab, case study, or assessment makes a privacy claim. Figure 2.6 shows the minimum chain needed to make that claim testable and maintainable.

In Figure 2.6, start with the data item, purpose, actor, and flow; together they define the claim’s scope. Then name the safeguard and observed evidence, record the safeguard’s limit, assign an owner, and specify the event that reopens review. Each later chapter can add depth to those fields, but the chain must remain intact so a technical control never loses its privacy rationale.

2.11 Knowledge Check

2.12 What to Read Next

Pseudonymisation: replace identifiers with tokens; REVERSIBLE if you
                  hold the mapping -> still personal data under GDPR
Anonymisation:    irreversible; done properly, no longer personal data
k-anonymity:      each record is indistinguishable from at least k-1
others on the quasi-identifiers (age, ZIP, sex, ...)

A row with { age: 34, ZIP: 90210, sex: F, diagnosis } may be
unique -> re-identifiable, k = 1.

Generalise the quasi-identifiers:
  age 34   -> age range 30-39
  ZIP 90210 -> region 902**
Now many rows share { 30-39, 902**, F }, so any one record
is hidden among, say, 20 others -> k = 20.

The diagnosis is still useful for statistics, but no single
person stands out.

2.13 Summary

This module covers privacy, compliance, safeguards, mobile privacy, privacy by design, and zero-trust security for IoT systems. It connects legal obligations with engineering controls and operational review.