21 GDPR Compliance for IoT
More
Depth: Practitioner
Progress saves as you read. Mark sections complete as you go; your progress appears in the sidebar.
21.1 Start Simple
This section: Start Simple — Picture a sleep band that stores movement and place.
Turn Each Right Into a Path a Person Can Use
Picture a sleep band that stores movement and place. A friendly screen is not enough if the owner cannot learn what is held, correct a wrong fact, obtain a copy, or end an unneeded use.
Draw the device, app, central store, outside service, support view, export, backup, and removal path. For each step, name the purpose, lawful reason, owner, people with access, saved period, and proof.
Test a real request from start to end. Use a wrong account link, an old copy, a missing partner reply, and a record that must be kept for a valid reason. Give the person a clear answer, time, limit, and help route.
Ask someone outside the team to use the route. Fix any step that needs hidden staff knowledge.
The law depends on role, place, data, and current guidance. Practitioner builds the working review. Under the Hood explains special data, organization roles, serious failures, and where expert advice is required.
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
This section: Overview: Privacy Principles as Law — The General Data Protection Regulation, usually shortened to GDPR, is an EU data protection law that applies to processing covered by Articles 2 and 3.
The General Data Protection Regulation, usually shortened to GDPR, is an EU data protection law that applies to processing covered by Articles 2 and 3. 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. Beyond that direct reach, GDPR has also served as a reference point for other jurisdictions drafting their own data protection laws, and California's Consumer Privacy Act, adopted the same year GDPR took effect, shares much of its structure with the European regulation. Learning GDPR's shape therefore transfers: the roles, rights, and evidence habits below recur, with local variation, across many of the regimes an IoT product might need to satisfy.
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
Work from the simplest case toward the broader design consequence. First, 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. Next, letting a user export and delete their device history is part of honoring data subject rights, not an optional extra. Finally, 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
This section: 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.
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 under GDPR Article 6; special-category data also needs an Article 9 condition. The recognized Article 6 bases include consent, processing necessary to perform a contract with the person, a legal obligation, protection of someone's vital interests, a task in the public interest, and legitimate interests 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. Contract may fit processing objectively necessary for a core feature covered by the contract; buying a product alone does not make every associated data use necessary. Optional extras need their own appropriate basis.
21.3.3 Data Subject Rights in IoT
People have rights over their personal data under GDPR Articles 12–22, including information, access, rectification, erasure in defined circumstances, restriction, objection, and portability where Article 20 applies. Article 22 also protects against qualifying decisions based solely on automated processing, subject to its exceptions and safeguards. The IoT challenge is to find the data across a device, hub, cloud, and backups, then apply the right and any applicable exception to each store. An erasure request cannot simply be marked complete after clearing only the cloud. Solely automated insurance-linked adjustments or access denials can make Article 22 relevant when they have legal or similarly significant effects.
21.3.4 Worked Reasoning: Three Decisions
Core feature basis
A thermostat needs occupancy data to provide its core feature. Basis: contract under Article 6(1)(b), not a consent pop-up the user cannot meaningfully refuse. Assess other uses separately.
Optional analytics
Usage analytics are not essential. Basis: genuine, withdrawable consent, off by default, so the choice is real.
Sensitive sensing
A health wearable may process Article 9 health data. Identify an Article 9 condition, assess whether processing is likely high risk and needs a DPIA before it starts, apply 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
This section: 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 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
GDPR Article 9 sets additional conditions for special-category data, including data concerning health. A wearable that infers heart rate or sleep handles health-related data, and a home sensor may reveal religious or lifestyle patterns. Data that indirectly reveals special-category information can fall under Article 9 (CJEU C-184/20, OT, 2022; C-21/23, Lindenapotheke, 2024). Under Article 35, a DPIA is required before processing likely to result in high risk, including large-scale processing of special-category data. Assess the actual purpose, scale, and risk, then record the decision.
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, GDPR Article 33 requires the controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people's rights and freedoms. If notification is later, the reasons for delay must be given. Article 34 requires communication to affected people without undue delay when the breach is likely to result in high risk, subject to its exceptions. Record all personal-data breaches. Prepare the assessment, notification, and record paths before an incident.
21.4.5 Obligations, Mechanisms, and Failure Modes
21.4.6 Common Pitfalls
Review these failure modes in order. First, Consent as a crutch. Using consent for things people cannot refuse, so the consent is not freely given. Next, Assuming the processor carries your duties. Believing a cloud provider's role removes the maker's controller obligations. Then, Rights that stop at the cloud. Honoring access or erasure for the server while device and backup copies persist. Then, Skipping the DPIA. Launching sensitive or large-scale sensing without studying the risk first. Finally, 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. An obligation you cannot demonstrate is, in practice, one you have not met (Articles 5(2) and 24). 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
This section: Summary — Connect GDPR obligations to the data, lawful basis, and role in the IoT product.
Connect GDPR obligations to the data, lawful basis, and role in the IoT product. First, 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. Next, personal data needs an Article 6 lawful basis and must follow the data protection principles; special-category data also needs an Article 9 condition. Device identifiers, location, and sensor readings can be personal data when they identify or single out someone. Then, your role drives your obligations: a controller decides why and how data is processed and carries the main accountability, while a processor acts on documented instructions and has duties of its own. Then, the workflow runs per feature: choose a valid basis, build protection in by design and by default, account for rights across device, hub, and cloud, secure data to its risk, run a DPIA before likely high-risk processing, and keep records. Consent must be freely given and withdrawable; contract applies only to processing objectively necessary to perform the contract. Finally, accountability means evidence, including a breach response that follows Articles 33 and 34.
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
This section: 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.
Find help
3 reviewed answers.
Where should I start in a module?
Open the module page from the sidebar to see its chapters in order. Use the module map to return to a topic you need.
Modules and pathsReviewed
What can I try when a project does not work?
Check the symptom, then work through the diagnostic steps. Keep the error message and the smallest example that reproduces it.
When you are stuckReviewed
How do interactive examples work?
Use the interactive guide to check how examples and simulations work before changing your project.
Interactive examples guideReviewed