Many hardware founders assume privacy law applies to social networks and ad companies, not to a temperature sensor. In practice, the moment your product connects to the internet and serves users in Europe or California, GDPR and US state privacy laws such as the CCPA apply to you — regardless of how small your company is or where it is based. A home sensor, a fitness watch, a doorbell camera, an irrigation controller: all of them collect data tied to an identifiable person, which is exactly what these regimes govern. The budget-relevant point is that most requirements are cheap to design in and very expensive to retrofit.

Projects House is an engineering firm, not a law firm or a regulatory consultancy. This article is educational only and is not legal advice. Retain qualified privacy counsel for your specific product and markets.

What counts as personal data in a connected product

Far more than a signup form. Broadly, anything that can be linked to an individual:

  • Device identifiers, MAC addresses, and IP addresses;
  • Location data, including coarse or inferred location;
  • Usage patterns — when the device was on, when someone was home, when they slept;
  • Body and health measurements from wearables, a sensitive category with stricter handling requirements;
  • Audio and video from microphones and cameras.

Purely technical sensor readings become personal data the moment they are associated with a user account. That is why the data model has to account for it from the first schema, not after launch — see storing sensor data.

Principles to design in from the start

GDPR requires privacy by design: privacy as an architectural decision, not a legal document added at the end. In engineering terms that means:

  • Data minimization. Collect only what a shipped feature needs. If the product does not need precise location, do not request the permission. Data you never collected is a risk that does not exist.
  • A lawful basis for every collection. Explicit, recorded consent, or genuine contractual necessity. Consent must be as easy to withdraw as it was to give, which is a UI requirement as much as a legal one.
  • Encryption throughout. Data encrypted in transit and at rest, with per-device identity provisioned during manufacturing — see secure boot and firmware encryption. Security and privacy travel together; the foundations are in IoT security for connected products.
  • Retention limits. Decide in advance how long each data type is kept, then delete or anonymize automatically when the period ends. An unbounded retention policy is both a compliance problem and a cloud bill.
  • Where the servers are. Moving personal data out of the EU requires a recognized legal mechanism, so cloud provider and region selection is part of the compliance design, not an infrastructure afterthought — and it affects cost, as covered in IoT cloud infrastructure cost.

Rights your system has to actually implement

European users have rights your product must satisfy in software, not just on paper: to know what is collected about them, to receive a copy in a readable format, to correct it, and to be deleted — the right to be forgotten. California and a growing list of US states add related rights, notably the right to know, the right to delete, and the right to opt out of the sale or sharing of personal information.

Deleting a user completely from a distributed system is harder than it sounds: the device itself, your cloud database, analytics tools, logs, backups, and any third-party processor all hold copies. Build a deletion routine as a real feature with a defined completion time, and keep an inventory of every place data lands. Teams that discover this requirement after launch usually end up doing it by hand, per request, forever.

Practical engineering checklist

  • A written data inventory: every field collected, why, where it is stored, how long, and who can see it.
  • Separation of identity from telemetry, so analytics can run on pseudonymized records.
  • Per-purpose consent flags stored with timestamps and version of the notice accepted.
  • Export and delete endpoints, exercised by automated tests.
  • Data processing agreements with every vendor that touches user data.
  • A defined breach detection and notification path — the notification clocks are short.
  • Multi-tenant permission boundaries so one customer cannot see another's devices, which ties directly into fleet management design.

Special cases worth flagging early

Products aimed at or likely to be used by children carry extra obligations in the US and Europe both — see COPPA compliance for kids apps. Cameras and microphones in shared spaces raise questions about people who never agreed to anything. Health and biometric data sit in the most restricted category in nearly every jurisdiction. If your product touches any of these, get counsel involved during architecture, not before launch.

Why this affects commercial outcomes

Maximum fines are dramatic but distant for a small company. The immediate consequence is commercial: European and increasingly US distributors, retail chains, and enterprise buyers will not sign with a supplier who cannot demonstrate compliance. A privacy posture you can document is a sales asset, and one you have to invent during a procurement review is a delayed deal.

Build privacy into the architecture

Projects House designs connected products for US clients with the data model, device identity, and cloud architecture specified together, so privacy requirements are engineering decisions made once rather than expensive rework later. Describe your product through the contact form, or read more in our software development guide.