Privacy & Compliance · Study deck

Privacy and Compliance Route Map

Imagine a care service that records when a door opens at night.

Privacy Priya is your guide for this deck.

route

Privacy Priya, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

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.

Privacy and compliance chapter groups showing introductions, mobile privacy, privacy-by-design, safeguards, zero trust, and synthesis.

Major section

Key Concepts

It may also reveal a person's sleep, movement, and daily life.

Privacy work begins before the first record is made.
Include the device, phone, central service, report, support view, outside partner, export, backup, and deletion route.
For each step, record who can see it, why, how long it stays, and who owns a mistake.

Major section

Key Concepts (continued)

The service should block broad access, mark doubt, keep an audit record, and offer a clear help route.

A purpose that sounds helpful can still widen the promise.
Plain language is part of the proof.
This route map cannot decide every law or edge case.
Practitioner turns the flow into controls and review questions.

Major section

Module Route

The gateway aggregates them locally, and only a room occupancy count reaches the dashboard for energy use.

The building operator has role-based access; gateway settings and access reviews are evidence for those limits.
That changes both the data detail and the purpose, so the privacy record must reopen before the new flow begins.
The solid and dashed paths show why approval of a count does not automatically approve raw-event reuse.

Smart-building data-flow example follows motion events to a locally aggregated occupancy count and dashboard; proposed raw-event reuse reopens the privacy review.

Major section

Data Lifecycle

Privacy review starts with data movement.

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.

IoT privacy data lifecycle showing collect, transform, transmit, store, use, share, retain, delete, and review steps.

Major section

Review Questions

The quickest way to improve a privacy chapter or design review is to ask consistent questions.

The record fields that follow preserve the answers so later changes can be compared against the original decision.
This order prevents a control inventory from replacing the privacy argument.

Privacy review question board showing data, purpose, notice, access, retention, sharing, safeguard, and evidence questions.

Major section

Safeguard Map

Reduction removes unnecessary exposure; protection constrains justified data; observation reveals misuse or drift; deletion ends the approved lifetime.

This makes safeguards a lifecycle argument rather than a shopping list, and it supplies the control and evidence fields in the review record below.
Trigger review when collection, purpose, sharing, region, retention, or user population changes.

Privacy safeguard map showing data reduction, protection, observation, deletion, and review triggers.

Major section

Overview: Privacy Is More Than Encryption

Data minimisation says collect and keep the least data that does the job.

De-identification says weaken the link between records and the people they describe.
Regulations like the GDPR encode these as principles, but they are good engineering regardless of jurisdiction.
A useful compliance record is therefore not a legal slogan.

A privacy compliance review turns a data flow into a purpose-bound record with minimisation, safeguards, evidence, and explicit conditions for reopening the decision.

Major section

Overview: Privacy Is More Than Encryption (continued)

If a door sensor only needs hourly occupancy counts for energy control, the record should make raw motion events, permanent identifiers, and unrelated analytics exports look suspicious until someone explains why they are needed.

That record also has to name the people affected by the system, not only the account owner.
The final step is not “done”: it records the change that reopens the decision.
Intuition: the safest data is the data you never collected.

Privacy review record template showing data item, purpose, actor, flow, safeguard, evidence, limit, owner, and review trigger.

Major section

Practitioner: Pseudonymisation, Anonymisation, and k-Anonymity

Good de-identification is also purpose-specific.

A fault-diagnosis export may need timestamp order but not exact home address.
A public benchmark may need region, device class, and month but not full ZIP code or raw event time.
A retention policy can keep short-lived raw logs for support while publishing only aggregated summaries.

Major section

Practitioner: Pseudonymisation, Anonymisation, and k-Anonymity (continued)

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

These decisions should be visible in the review: which fields were generalised, which were suppressed, which remain reversible, who holds the mapping, and which downstream use is not allowed without a fresh privacy review.
Worked example: raising k by generalisingA row with { age: 34, ZIP: 90210, sex: F, diagnosis } may be unique -> re-identifiable, k = 1.
The lesson: removing the name is not anonymisation.

Major section

Under the Hood: Differential Privacy and Its Guarantee

Ad hoc masking keeps failing to re-identification, which is why modern privacy leans on techniques with provable guarantees.

The published mechanism should behave almost the same in both cases.
The privacy budget is the operational control.
A large epsilon gives more accuracy but weaker privacy.

Major section

Under the Hood: Differential Privacy and Its Guarantee (continued)

The promise is not that every answer is exact; the promise is that one person's participation has a bounded effect on what outsiders can learn from the released output.

A small epsilon gives stronger privacy but adds more noise, so the result may be less useful for fine-grained engineering decisions.
Repeated releases spend budget, and overlapping queries can leak information through differencing, so production systems need query limits, aggregation thresholds, audit logs, and a documented reason for each release.
Extensions like l-diversity and t-closeness patch this, but the arms race shows the limits of generalisation alone.

Major section

Under the Hood: Differential Privacy and Its Guarantee (continued)

Differential privacy works best when it is paired with minimisation, retention limits, access control, and a clear decision about which statistics are worth publishing.

k-anonymity's own weaknessesIf all k matching records share the same sensitive value (a homogeneity attack), you learn it anyway.
Differential privacyAdd calibrated random noise so that whether any single individual is in the dataset barely changes any published result.
It gives a provable guarantee rather than hoping no combination re-identifies someone.
Even aggregates can leakReleasing many overlapping statistics allows differencing attacks that isolate one person.

Deck summary

Key takeaways

It may also reveal a person's sleep, movement, and daily life.

The service should block broad access, mark doubt, keep an audit record, and offer a clear help route.
The gateway aggregates them locally, and only a room occupancy count reaches the dashboard for energy use.
Privacy review starts with data movement.
The quickest way to improve a privacy chapter or design review is to ask consistent questions.

Retrieval practice

Recall check 1 of 5

Privacy Priya says: answer from memory, then check your reasoning.

Q1A team asks whether an IoT product is privacy-ready. What is the strongest first review step?

AAssume encryption alone establishes privacy readiness.

BMap data flows and relate each item to a defined purpose.

CReuse an old checklist without inspecting today's data flows.

DDelay review until product launch reveals real data use.

Show answer

Answer: B A privacy review needs a data-flow map before controls or obligations can be evaluated.

Retrieval practice

Recall check 2 of 5

Privacy Priya says: answer from memory, then check your reasoning.

Q2A device originally collected local occupancy counts for energy control. The team now wants to export raw motion events for analytics. What should happen?

AKeep prior approval because both uses involve the same device.

BRename the dashboard field without reviewing exported events.

CDelete the flow diagram because the design team knows the product.

DReopen privacy review for the changed detail, recipient flow, and purpose.

Show answer

Answer: D Privacy records should be reopened when data detail, purpose, sharing, access, or retention changes.

Retrieval practice

Recall check 3 of 5

Privacy Priya says: answer from memory, then check your reasoning.

Q3Why is strong encryption alone insufficient to protect privacy?

AIt stops outsiders, not insider inference or over-collection.

BEncryption keys are too short to resist modern attackers, so privacy needs longer keys.

CPrivacy concerns only data in transit, and encryption protects only data at rest.

DOnce data is encrypted it can never be decrypted, making it useless for analysis.

Show answer

Answer: A Privacy also concerns what authorised viewers can infer about individuals and whether excessive data was collected at all; minimisation and de-identification address those.

Retrieval practice

Recall check 4 of 5

Privacy Priya says: answer from memory, then check your reasoning.

Q4A dataset has names removed but keeps exact birth date, ZIP code, and sex. Why might individuals still be re-identifiable?

ARemoving the name always fully anonymises a dataset, so re-identification becomes impossible.

BOnly a person's full name or national ID can ever identify them in a dataset.

CBirth date and ZIP code are aggregate statistics, not personal data about anyone.

DQuasi-identifiers can re-link records after names are removed.

Show answer

Answer: D The combination of quasi-identifiers (birth date + ZIP + sex) can be unique even after names are removed, so records may link back to individuals; generalisation or k-anonymity is needed.

Retrieval practice

Recall check 5 of 5

Privacy Priya says: answer from memory, then check your reasoning.

Q5What guarantee does differential privacy provide that ad hoc data masking does not?

AEncryption that restricts the published data to approved analysts.

BA quantitative bound on one person's effect, expressed with epsilon.

CPerfect statistical accuracy with no privacy loss after release.

DFreedom to collect unlimited raw data because outputs are masked.

Show answer

Answer: B By adding calibrated noise it provably limits how much one individual's presence or absence can change an output (tuned by epsilon), rather than hoping no attribute combination re-identifies someone.

Print reference

Answers 1 of 2

Answer key.

B · A privacy review needs a data-flow map before controls or obligations can be evaluated.
D · Privacy records should be reopened when data detail, purpose, sharing, access, or retention changes.
A · Privacy also concerns what authorised viewers can infer about individuals and whether excessive data was collected at all; minimisation and de-identification address those.

Print reference

Answers 2 of 2

Answer key.

D · The combination of quasi-identifiers (birth date + ZIP + sex) can be unique even after names are removed, so records may link back to individuals; generalisation or k-anonymity is needed.
B · By adding calibrated noise it provably limits how much one individual's presence or absence can change an output (tuned by epsilon), rather than hoping no attribute combination re-identifies someone.