21 GDPR Compliance for IoT
Roles, Rights, Design Defaults, Security Measures, DPIAs, and Evidence Records
GDPR for IoT, data subject rights, data protection by design, DPIA, controller processor, Article 32
21.1 Start Simple
Start with a wearable that measures sleep, movement, and location. The person wearing it may only see a friendly dashboard, but the product team sees data paths: device, app, cloud, analytics vendor, support console, export button, and delete request. GDPR work begins by asking who controls each path and what rights the person has over it.
The point is not to memorize a regulation. It is to make every personal-data use visible, lawful, protected, and reviewable.
21.2 Overview: Privacy Principles as Law
The General Data Protection Regulation, usually shortened to GDPR, is a European data protection law that turns privacy principles into binding obligations for anyone who handles the personal data of people it covers. It is worth learning even outside Europe, because it reaches organizations far beyond the region: an IoT maker anywhere that offers a product to people in the European Union, or monitors their behavior, can fall within its scope.
The central idea is that personal data is handled on behalf of the person it describes, called the data subject, and may be processed only with a lawful basis and within the data protection principles. Personal data is any information relating to an identifiable person, which for IoT includes far more than names: device identifiers, location, and sensor readings that can single someone out all count.
If you only need the intuition, this layer is enough: know whether you decide how data is used, have a lawful reason to process it, build protection in by design and by default, honor people’s rights over their data, secure it, and be able to show all of this.
Think of building codes. You are free to build, but to a published standard, with safe defaults, and you must be able to show your work to an inspector. GDPR is a building code for personal data: it does not forbid using data, but it requires a lawful reason, protective defaults, real rights for the people affected, and records that demonstrate you met the standard.
For a connected wearable, that means mapping the device sensor stream, companion app, cloud analytics, support console, and export/delete workflow as one processing system. The team records who decides each purpose, which fields are needed for the core feature, which optional analytics are off by default, how access and erasure reach the device and cloud, whether health-related inference triggers stronger assessment, and what evidence proves those decisions. The review is not just “do we have a privacy notice?” It asks whether each data path has a role decision, a lawful basis, protective defaults, a rights workflow, safeguards, a DPIA screen where risk warrants it, and records an auditor can inspect.
21.2.1 The Two Roles
Controller
The party that decides why and how personal data is processed. The controller carries the main accountability for meeting the obligations.
Processor
A party that processes personal data on the controller’s behalf and under its instructions, such as a cloud service, and still has duties of its own.
Why it matters
Your role decides your obligations. Many IoT makers are controllers for the data their devices collect, even when a third party stores it.
21.2.2 Beginner Examples
- A smart-home company that decides what its sensors collect and why is acting as a controller, even if the data sits in someone else’s cloud.
- Letting a user export and delete their device history is part of honoring data subject rights, not an optional extra.
- Adding a longer consent pop-up while still over-collecting does not create compliance; the obligations are about the data handling itself.
21.2.3 Overview Knowledge Check
If you can identify your role and why scope reaches beyond Europe, you have the core idea. Continue to Practitioner for the compliance workflow.
21.3 Practitioner: The Compliance Workflow
Compliance becomes manageable when you run a consistent workflow for each feature that handles personal data, recording the decision at each step so the result can be demonstrated later. The steps map directly onto the obligations.
21.3.1 Obligations as Working Steps
21.3.2 Choosing a Lawful Basis
Every processing of personal data needs a lawful basis. The recognized bases include consent, performance of a contract, a legal obligation, protection of someone’s vital interests, a task in the public interest, and the legitimate interests of the controller balanced against the person’s rights. A common practitioner mistake is to reach for consent automatically. Consent must be freely given, specific, informed, and as easy to withdraw as to give, which is hard to achieve honestly on a small device. Often a more honest basis exists, such as contract for the core feature the customer bought, with consent reserved for genuinely optional extras.
21.3.3 Data Subject Rights in IoT
People have rights over their personal data, including the right to be informed, to access a copy, to have inaccurate data corrected, to have data erased in defined circumstances, to restrict or object to processing, and to receive their data in a portable form. The IoT challenge is that these rights must work even when the data is spread across a device, a hub, and a cloud. A right to erasure that clears the cloud but leaves copies on the device or in backups has not really been honored.
21.3.4 Worked Reasoning: Three Decisions
Core feature basis
A thermostat needs occupancy to function. Basis: contract for the core feature, not a consent pop-up the user cannot meaningfully refuse.
Optional analytics
Usage analytics are not essential. Basis: genuine, withdrawable consent, off by default, so the choice is real.
Sensitive sensing
A health wearable handles sensitive data. Action: run a DPIA first, apply stronger safeguards, and record the decision.
21.3.5 Practitioner Knowledge Check
If you can run the workflow and choose an honest lawful basis, you can stop here. Continue to Under the Hood for roles, special data, breaches, and where compliance quietly fails.
21.4 Under the Hood: Roles, Special Data, Breaches, and Failure Modes
The deeper layer explains the responsibilities that follow from your role, the extra care some data demands, and what happens when something goes wrong. The recurring theme is accountability: an obligation you cannot demonstrate is, in practice, an obligation you have not met.
21.4.1 Controller and Processor Responsibilities
The controller decides why and how data is processed and carries the main accountability, including choosing lawful bases, honoring rights, and demonstrating compliance. A processor acts on the controller’s documented instructions and must not use the data for its own purposes, must protect it, and must help the controller meet its duties. The relationship is governed by a contract that sets out these responsibilities. A frequent IoT error is assuming a cloud provider, as a processor, removes the maker’s duties; it does not, because the maker remains the controller for the data its devices collect.
21.4.2 Special Category Data Needs More Care
Some personal data is treated as more sensitive, such as data about health, and it carries stronger conditions for processing. IoT makes this common: a wearable that infers heart rate or sleep is handling health-related data, and a home sensor may reveal religious or lifestyle patterns. When a feature touches such data, the bar for justification, safeguards, and assessment rises, and a DPIA is usually warranted.
21.4.3 Data Protection by Design and by Default
The regulation requires protection to be built into processing from the outset and to be the default state, rather than something a user must seek out. This is the legal expression of the same idea covered in the foundations chapter: minimization and protective defaults enforced in the system, not promised in a notice. Treating this as a design obligation, checked with evidence, is what turns it from a slogan into compliance.
21.4.4 When Something Goes Wrong
If personal data is breached, the controller generally must assess the risk to people, notify the supervisory authority promptly when notification is required, and inform the affected individuals when the risk to them is high. The practitioner point is preparation: know in advance who assesses a breach, who notifies, and what record is kept, because a breach is the worst time to design the response. The exact timing and thresholds are set by the regulation and the supervisory authority, so confirm them rather than guessing.
21.4.5 Obligations, Mechanisms, and Failure Modes
21.4.6 Common Pitfalls
- Consent as a crutch. Using consent for things people cannot refuse, so the consent is not freely given.
- Assuming the processor carries your duties. Believing a cloud provider’s role removes the maker’s controller obligations.
- Rights that stop at the cloud. Honoring access or erasure for the server while device and backup copies persist.
- Skipping the DPIA. Launching sensitive or large-scale sensing without studying the risk first.
- Accountability without evidence. Claiming compliance with nothing recorded to demonstrate it.
21.4.7 Under-the-Hood Knowledge Check
At this depth, GDPR compliance for IoT is accountability made concrete: know your role, have a lawful basis, build protection in by design and by default, make rights work across every store, secure data to its risk, assess high-risk sensing, and keep records that demonstrate it. A trustworthy review does not ask whether a policy exists; it asks what evidence shows each obligation is met, and confirms the regulation’s specific timings and thresholds rather than guessing them.
21.5 Summary
- GDPR turns privacy principles into binding obligations and can reach IoT makers outside Europe that offer products to, or monitor, people in the European Union.
- Personal data may be processed only with a lawful basis and within the data protection principles; for IoT, personal data includes device identifiers, location, and sensor readings that can single someone out.
- Your role drives your obligations: a controller decides why and how data is processed and carries the main accountability, while a processor acts on the controller’s instructions and still has duties of its own.
- The compliance workflow runs per feature: choose a lawful basis, build protection in by design and by default, make data subject rights work across device, hub, and cloud, secure the data to its risk, run a DPIA for high-risk processing, and keep records.
- Consent should not be a catch-all; it must be freely given and withdrawable, so core functions are usually better grounded in another basis such as contract.
- Accountability means evidence: an obligation you cannot demonstrate is, in practice, one you have not met, and specific timings and thresholds should be confirmed against the regulation rather than guessed.
GDPR is a building code for personal data: it does not forbid using data, it requires a lawful reason, protective defaults, real rights, security matched to risk, and records that demonstrate you met the standard. Know your role, choose an honest lawful basis, make rights work across every store, and keep evidence. Always confirm the regulation’s exact timings and thresholds rather than assuming them.
21.6 See Also
Privacy Regulation Mapping for IoT
See how GDPR fits alongside other data protection regimes and how to map obligations across them.
Privacy Principles and Ethics in IoT
Revisit the principles that GDPR encodes, including purpose limitation and accountability.
See how data protection by design and by default is built into a system rather than promised.