Wearables, Smart Home Devices and Smart City IoT

Wearables, Smart Home Devices and Smart City IoT: A CIPT Guide to Privacy Risk Management

Introduction
The Internet of Things (IoT) has moved computing off the desk and into bodies, homes and streets. Fitness trackers, smartwatches, voice assistants, smart thermostats, connected doorbells, smart meters, connected cars, traffic sensors and city-wide camera networks all collect data continuously, often without a screen or any obvious moment of interaction. For the IAPP Certified Information Privacy Technologist (CIPT) exam, this topic sits within Privacy Risk Management and the wider study of privacy in emerging technologies. You are expected to recognise the unique privacy risks of IoT and to recommend technical and organisational controls that address them.

Why It Is Important
1. Scale and ubiquity: Billions of connected devices create huge volumes of personal data. Every one of them is a possible point of collection, leakage or attack.
2. Sensitivity of data: Wearables capture heart rate, sleep patterns, location, menstrual cycles and stress levels, which is health and biometric data that is often a special category under laws such as the GDPR. Smart home devices reveal daily routines, occupancy, conversations and household composition. Smart city systems track movement patterns across whole populations.
3. Passive and invisible collection: IoT devices collect data ambiently. Users, and especially bystanders such as guests, neighbours and pedestrians, may not know that data is being collected at all.
4. Limited user interfaces: Many devices have no screen, which makes traditional notice and consent mechanisms hard to deliver.
5. Security weaknesses: Default passwords, unpatched firmware, weak encryption and long device lifespans make IoT a frequent target. The Mirai botnet is the classic example.
6. Regulatory exposure: Relevant rules include the GDPR (including Article 25 data protection by design and default), the ePrivacy Directive (storage of and access to information on terminal equipment), CCPA/CPRA, US state biometric laws such as Illinois BIPA, COPPA for children's devices, the FTC Act Section 5 (unfair and deceptive practices), and IoT security laws such as California SB-327, the UK PSTI Act, the EU Cyber Resilience Act and the US Cyber Trust Mark. NIST IR 8259 provides IoT device cybersecurity baselines, and ETSI EN 303 645 is a consumer IoT security standard.
7. Trust and reputation: Incidents such as staff or contractors reviewing voice assistant recordings, fitness app heatmaps exposing military bases (the Strava incident), smart TVs collecting viewing data (the FTC case against Vizio), and hacked baby monitors and cameras have damaged consumer trust.

What It Is
Wearables
These are body-worn devices such as smartwatches, fitness bands, smart rings, smart glasses, medical monitors, hearing devices and VR/AR headsets. They typically pair with a smartphone app and a cloud backend.
Data collected includes:

• Biometric and health data
• Geolocation
• Activity data
• Audio and video (for smart glasses)
• Behavioural patterns

Key privacy concerns include:

• Health inferences
• Sharing with insurers or employers, for example through workplace wellness programmes
• Re-identification of supposedly anonymised data
• Bystander recording by smart glasses
• Data that falls outside HIPAA protection when collected by consumer companies rather than covered entities

Smart Home Devices
These include voice assistants and smart speakers, smart TVs, thermostats, smart locks, video doorbells, security cameras, robot vacuums (which map the home), smart appliances, baby monitors and connected toys.
Key privacy concerns include:

• Always-listening microphones and false wake-word activations
• Recordings of household members, children and guests
• Inference of occupancy and routines, which creates burglary risk
• Sharing of doorbell footage with law enforcement
• Automated content recognition on TVs
• Multi-user households where the account holder is not the only data subject
• Abuse by intimate partners

Smart City IoT
These are public-sector and public-private deployments, including:

• Traffic sensors and automatic number plate recognition (ANPR/ALPR)
• CCTV with facial recognition
• Smart streetlights with cameras and microphones
• Public Wi-Fi and Bluetooth tracking
• Smart meters and smart grids
• Smart parking
• Connected public transport and fare cards
• Environmental sensors
• Gunshot detection

Key privacy concerns include:

• Mass surveillance
• Function creep, where data collected for traffic management is later used for policing
• Lack of a meaningful opt-out in public spaces
• Unclear accountability between city authorities and vendors
• Chilling effects on free movement and assembly
• Disproportionate impact on certain communities

The Sidewalk Toronto (Quayside) project is a commonly cited example of public backlash over data governance.

How It Works: The IoT Data Lifecycle and Risk Points
1. Sensing and collection: Sensors such as accelerometers, microphones, cameras, GPS units, optical heart sensors, infrared detectors and RF scanners capture raw signals. The main risk is over-collection, along with capturing data about non-users.
2. Local processing (edge): Some devices process data on the device itself, for example on-device wake-word detection. Edge processing is a strong privacy-enhancing pattern because it reduces how much data is transmitted.
3. Transmission: Data moves over Bluetooth Low Energy, Wi-Fi, Zigbee, Z-Wave, cellular or LPWAN networks such as LoRaWAN. The risks are interception, unencrypted traffic and identifiers that can be used for tracking, such as static MAC addresses. Controls include TLS, MAC address randomisation and secure pairing.
4. Cloud storage and analytics: Aggregation enables profiling and inference. The risks are breaches, excessive retention, secondary use and sharing with third parties or data brokers.
5. Sharing and integration: Data flows through APIs, third-party skills or apps, advertisers, insurers, researchers and government. Each flow needs a lawful basis, contracts and transparency.
6. End of life: Devices are resold or discarded, and vendors may stop providing updates. The risks are residual data on second-hand devices and abandoned, unpatched devices. Controls include factory reset that truly wipes data, published support periods and secure decommissioning.

Privacy Risk Frameworks Applied to IoT
Solove's Taxonomy: IoT illustrates surveillance (cameras and ALPR), aggregation (combining sensor streams), identification (gait or voice recognition), insecurity (weak devices), secondary use (function creep), exclusion (no access or control) and intrusion (devices in the home).
Calo's harms: Subjective harms include the feeling of being watched in your own home. Objective harms include data being used against you, such as insurance pricing.
Nissenbaum's Contextual Integrity: Heart-rate data shared with your doctor fits its context. The same data flowing to an employer or advertiser breaks the norms of that context.
FIPPs and OECD principles: Collection limitation, purpose specification, use limitation, security safeguards, openness, individual participation and accountability.
NIST Privacy Framework: Its functions are Identify-P, Govern-P, Control-P, Communicate-P and Protect-P. NIST IR 8228 specifically addresses IoT cybersecurity and privacy risks, and NIST IR 8259A sets out core device capabilities such as device identification, configuration, data protection, logical access, software update and cybersecurity state awareness.
Privacy by Design (Cavoukian's 7 principles): Be proactive, make privacy the default, embed it into design, aim for full functionality (positive-sum), provide end-to-end security, maintain visibility and transparency, and respect the user.
DPIA/PIA: A data protection impact assessment is usually mandatory under GDPR Article 35 for systematic monitoring of public areas, large-scale processing of special category data, and innovative technology. Smart city and health wearable projects almost always trigger one.

Key Technical and Organisational Controls
Data minimisation: Collect only the sensors and data needed. Process at the edge. Aggregate or summarise before upload, for example sending daily step counts rather than raw accelerometer streams.
De-identification and aggregation: Use pseudonymisation, k-anonymity, differential privacy for city-wide analytics, and spatial and temporal coarsening of location. Remember that location and biometric data are notoriously hard to anonymise.
Privacy-protective defaults: Location sharing, public activity feeds and third-party sharing should be off by default. Use physical mic and camera shutters or kill switches and visible recording indicators such as LEDs.
Notice in low-interface environments: Use companion app dashboards, just-in-time notices, layered notices, QR codes on devices, packaging disclosures, signage and icons in public spaces, voice-based notices, and privacy labels or nutrition labels.
Consent and control: Use granular consent, easy withdrawal, multi-user profiles, guest modes, voice commands to delete recordings, and auto-delete settings.
Security by design:

• No universal default passwords
• Unique credentials per device
• Encryption in transit and at rest
• Secure boot
• Signed over-the-air firmware updates
• Vulnerability disclosure programmes
• Network segmentation, such as an IoT VLAN
• Least-privilege APIs
• Mutual authentication
• Hardware security modules or secure elements

Retention limits: Automatically delete raw sensor and voice data. Define retention schedules for smart city footage.
Vendor and third-party management: Use due diligence, data processing agreements, audit rights, and restrictions on vendor secondary use. This is especially important in public-private smart city partnerships.
Governance for smart cities: Use surveillance technology ordinances requiring public approval, public registers of sensors, data trusts or independent oversight boards, purpose limitation policies that prevent function creep, transparency reports, and community engagement.
Data subject rights: Provide mechanisms for access, deletion and portability through the app or web portal, including for data tied to device identifiers.

Worked Example Scenarios
Scenario 1: A fitness band company wants to sell aggregated user data to health insurers.
Issues:

• Special category health data
• Secondary use
• Contextual integrity violation
• Re-identification risk
• Consent requirements

Best response: Conduct a DPIA, obtain explicit and separate opt-in consent, apply strong de-identification such as differential privacy, contractually prohibit re-identification, and provide clear transparency.
Scenario 2: A smart speaker accidentally records conversations, and human reviewers listen to clips to improve accuracy.
Issues:

• Lack of transparency
• Recording of bystanders
• Sensitive content in the recordings

Best response: Disclose human review, offer an opt-out (ideally opt-in), de-link recordings from accounts, minimise the clips reviewed, process wake words on the device, and provide auto-delete.
Scenario 3: A city installs smart streetlights with cameras for traffic management, and police request the footage.
Issues:

• Function creep
• Mass surveillance
• Absence of a lawful basis for the new purpose

Best response: Define the purpose in advance, require public consultation, carry out a DPIA, use edge processing that outputs only counts rather than video, establish retention limits, set a legal process for access requests, and publish a transparency report.
Scenario 4: A smart home camera ships with the default password admin/admin.
Issue: A security failure that enables a breach.
Best response: Use unique per-device credentials, force a password change at setup, provide secure updates, and comply with laws such as California SB-327 and the UK PSTI Act.

Exam Tips: Answering Questions on Wearables, Smart Home Devices and Smart City IoT
Tip 1: Identify the data type first. Ask whether it is health or biometric, location, audio or video, or behavioural data. Sensitive data raises the bar: explicit consent, a DPIA and stronger safeguards. Answers that treat health or biometric data casually are usually wrong.
Tip 2: Look for the bystander or non-user. IoT questions often hinge on people who never agreed to anything, such as guests, children, pedestrians and other household members. Good answers address them through signage, recording indicators, guest modes, blurring or on-device redaction.
Tip 3: Favour edge processing and minimisation. When asked for the best privacy-enhancing design choice, options that process data on the device or send only aggregated or derived results usually beat options that merely encrypt full raw data sent to the cloud.
Tip 4: Distinguish privacy from security. Encryption and patching are security controls. They are necessary but not sufficient. If the question is about secondary use, transparency or consent, a pure security answer is probably a distractor.
Tip 5: Remember the notice challenge. For screenless devices, the correct answer often involves companion apps, layered or just-in-time notices, voice notices, packaging, QR codes or public signage. A long privacy policy alone is rarely the best answer.
Tip 6: Watch for function creep in smart city questions. When data collected for one civic purpose is requested for another, especially by law enforcement, look for purpose limitation, governance oversight, legal process and transparency in the answer.
Tip 7: Choose the earliest and most proactive control. CIPT rewards privacy by design. Between fixing an issue after launch and building it into requirements with a PIA or DPIA, choose the design-stage approach.
Tip 8: Know the key frameworks by name. Expect references to NIST IR 8228 and 8259, the NIST Privacy Framework, ETSI EN 303 645, GDPR Articles 25 and 35, ePrivacy, COPPA (connected toys), BIPA (biometrics), FTC Section 5 enforcement, California SB-327 and the UK PSTI Act.
Tip 9: Apply privacy taxonomies. If asked to name the harm, map it carefully:

• Continuous monitoring is surveillance.
• Combining sensor data is aggregation.
• Using data for a new purpose is secondary use.
• Weak protection is insecurity.
• A device in the bedroom is intrusion.

Tip 10: Be sceptical of anonymisation claims. Location traces, gait, voice and heart-rate patterns can be re-identified. If an option claims anonymised data is risk-free, it is likely wrong. Prefer layered de-identification plus contractual and technical controls.
Tip 11: Consider the full lifecycle. Questions may test end-of-life issues such as resale, data wiping, end of software support or vendor shutdown. Secure deletion and published support periods are strong answers.
Tip 12: Defaults matter. Privacy by default means opt-in for sharing, private profiles, minimal retention and features off until enabled. Choose answers that make the privacy-protective setting the default rather than relying on users to find settings.
Tip 13: Multi-stakeholder accountability. In smart cities and ecosystems involving device makers, app developers, cloud providers and third-party skills, the right answer usually clarifies roles (controller or processor), contracts and oversight.
Tip 14: Read for the best answer, not just a correct one. Several options may be valid. Pick the one that most directly mitigates the specific risk described, at the root cause, with the least data.

Quick Revision Summary

• Wearables: health and biometric data, location, insurer and employer sharing, re-identification, gaps in HIPAA coverage.
• Smart home: always-on microphones and cameras, household members and guests, occupancy inference, human review of recordings, weak default security.
• Smart city: mass surveillance, no opt-out, function creep, public-private accountability, need for public governance and DPIAs.
• Top controls: data minimisation, edge processing, privacy by default, layered and just-in-time notice, granular consent, strong device security, retention limits, de-identification, vendor contracts, DPIAs and transparent governance.

Master these patterns and you will be able to analyse almost any IoT scenario on the CIPT exam. Identify the data and the people affected, map the risk to a framework, then choose the most proactive, privacy-preserving design control.