1447  Compliance and GDPR for IoT

1447.1 Learning Objectives

By the end of this chapter, you will be able to:

• Handle Erasure Requests: Process GDPR Article 17 “Right to be Forgotten” requests across multi-vendor IoT ecosystems
• Implement Privacy by Design: Apply GDPR Article 25 requirements at the firmware level
• Manage Consent: Design consent management systems that meet GDPR Article 7 requirements
• Navigate Multi-Vendor Compliance: Coordinate erasure and privacy across independent data controllers

TipFor Beginners: GDPR and IoT

What is GDPR? The General Data Protection Regulation (GDPR) is EU law governing how organizations collect, process, and store personal data. It gives individuals rights over their data including the right to access, correct, and delete it.

Why does it matter for IoT? IoT devices collect vast amounts of personal data - from smart home behavior patterns to health metrics. Each device may have its own data controller, making compliance complex across multi-vendor ecosystems.

Key terms: | Term | Definition | |——|————| | Data Controller | Organization that determines purposes and means of processing personal data | | Data Processor | Organization that processes data on behalf of a controller | | Article 17 | Right to Erasure (“Right to be Forgotten”) | | Article 25 | Data Protection by Design and by Default | | Article 7 | Conditions for Consent | | Special Category Data | Sensitive data including health, biometric, and location data |

NoteKey Takeaway

In one sentence: Multi-vendor IoT ecosystems require coordinated GDPR compliance where each controller processes erasure requests and cascades notifications to all processors within the 30-day deadline.

Remember this rule: Privacy must be “baked in” at the firmware level - technical defaults that cannot be overridden by cloud configuration provide the strongest protection.

1447.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• NIST Framework: Understanding of the Identify and Protect functions provides context for compliance
• Introduction to Privacy: Privacy fundamentals and data protection principles
• Security Controls: Technical implementation of protection measures

1447.3 GDPR Article 17: Right to Erasure

NoteWorked Example: GDPR Erasure Request for Multi-Vendor IoT Ecosystem

Scenario: A smart home customer in France exercises their GDPR Article 17 “Right to Erasure” (Right to be Forgotten). Their smart home ecosystem includes devices from 5 different vendors: smart thermostat (Nest), security cameras (Ring), voice assistant (Alexa), smart lights (Philips Hue), and a central hub (SmartThings). The customer wants ALL their data deleted across ALL vendors within the GDPR-mandated 30-day timeline.

Given: - Customer: Marie Dupont, French resident, GDPR data subject - Request date: January 15, 2026 - Deadline: February 14, 2026 (30 days per GDPR Article 12(3)) - Data controllers: 5 vendors (each is an independent controller) - Data processors: 12 third-party services (cloud providers, analytics, voice processing) - Complications: Shared household data (spouse also uses devices), legal retention requirements (energy data for French utility billing)

1447.3.1 Step 1: Receive and Validate the Erasure Request (Day 1-3)

Validation Step	Action	GDPR Reference
Identity verification	Request government ID or account verification	Art. 12(6) - verify identity
Scope clarification	“Do you want all data or specific categories?”	Art. 17(1) - specific or broad
Third-party cascade	“Should we notify all processors?”	Art. 17(2) - notification duty
Exceptions check	Review for legal retention requirements	Art. 17(3) - exemptions

Response to customer (Day 3): > “We have received your erasure request dated January 15, 2026. We will process your request within 30 days. We have identified the following data categories and will delete or anonymize as appropriate…”

1447.3.2 Step 2: Map Data Across All Vendors and Processors

Vendor	Data Types	Retention Requirement	Erasure Action
Nest	Temperature preferences, occupancy patterns, energy usage	French energy law: 3-year billing records	DELETE preferences; ANONYMIZE energy data
Ring	Video recordings (90 days), motion events, device IDs	None (no legal obligation)	DELETE all (full erasure)
Alexa	Voice recordings, purchase history, routines	None	DELETE all (incl. voice training data)
Hue	Lighting schedules, usage patterns	None	DELETE all
SmartThings	Device connections, automation rules, location	None	DELETE all

1447.3.3 Step 3: Handle Shared Household Data

The spouse (Pierre) also uses these devices. His data must be preserved.

Data Type	Marie’s Data	Pierre’s Data	Action
Voice profiles	“Alexa, it’s Marie”	“Alexa, it’s Pierre”	Delete Marie’s voice model only
Camera footage	Marie appears in videos	Pierre appears in videos	DELETE Marie-tagged clips; RETAIN Pierre-tagged
Thermostat preferences	Marie’s preferred 22C	Pierre’s preferred 20C	DELETE Marie’s profile; retain Pierre’s
Shared routines	“Good morning” routine	Same routine	Convert to Pierre-only ownership

1447.3.4 Step 4: Technical Implementation

def cascade_erasure_multi_vendor(customer_id, vendors, deadline_days=30):
    """Execute GDPR Article 17 across multi-vendor ecosystem."""
    erasure_log = []

    for vendor in vendors:
        # Step 1: Identify all data for this customer
        data_inventory = vendor.get_data_inventory(customer_id)

        # Step 2: Check for retention exemptions
        exempt_data = check_legal_exemptions(data_inventory,
                                              jurisdiction="FR")

        # Step 3: Execute erasure (with exemptions preserved)
        for data_item in data_inventory:
            if data_item in exempt_data:
                # Anonymize instead of delete (Art. 17(3))
                vendor.anonymize(data_item, remove_fields=[
                    "customer_id", "name", "email", "address"
                ])
                erasure_log.append({
                    "vendor": vendor.name,
                    "data": data_item.type,
                    "action": "anonymized",
                    "reason": "legal_retention_requirement"
                })
            else:
                # Full deletion
                vendor.hard_delete(data_item)
                erasure_log.append({
                    "vendor": vendor.name,
                    "data": data_item.type,
                    "action": "deleted",
                    "timestamp": datetime.now()
                })

        # Step 4: Notify processors (Art. 17(2))
        for processor in vendor.get_processors():
            processor.cascade_erasure(customer_id)
            erasure_log.append({
                "processor": processor.name,
                "action": "notified",
                "deadline": deadline_days
            })

    return erasure_log

1447.3.5 Step 5: Generate Compliance Documentation (Day 28-30)

Vendor	Data Deleted	Data Anonymized	Processors Notified	Completion Date
Nest	Preferences, schedules	3-year energy usage	Google Cloud, utility API	Feb 10, 2026
Ring	All video, events, metadata	None	AWS, video analytics	Feb 8, 2026
Alexa	Voice recordings, history, routines	None	AWS, ML training	Feb 12, 2026
Hue	Schedules, patterns	None	Philips Cloud	Feb 7, 2026
SmartThings	All hub data, automations	None	Samsung Cloud	Feb 9, 2026

1447.3.6 Step 6: Notify Customer of Completion

“Dear Marie Dupont,

Your GDPR Article 17 erasure request (ref: ER-2026-00147) has been completed as of February 12, 2026.

Deleted: Voice recordings, video footage, device preferences, automation rules, usage history across all 5 vendors.

Anonymized (legal retention per French energy law): Historical energy consumption data (identifiers removed).

Processors notified: 12 third-party services have been instructed to delete your data per Article 17(2).

You may verify erasure by logging into each vendor’s privacy dashboard. If you have questions, contact our DPO at dpo@smarthome.example.com.”

Result: All 5 vendors completed erasure within the 30-day deadline. 12 processors were cascade-notified per Article 17(2). French energy retention law was respected by anonymizing (not deleting) 3 years of energy data. The spouse’s data was preserved. Audit trail demonstrates GDPR compliance.

Key Insight: Multi-vendor IoT ecosystems make erasure complex because each vendor is an independent data controller with their own processors. GDPR Article 17(2) requires controllers to “take reasonable steps” to inform processors - this means cascade notification across your entire data supply chain. The 30-day deadline applies to the controller receiving the request; processors have their own deadlines. Always document exceptions (Article 17(3)) thoroughly, as anonymization is often acceptable when full deletion would violate other legal obligations.

1447.4 GDPR Article 25: Privacy by Design

NoteWorked Example: Implementing Privacy by Design for IoT Firmware

Scenario: A medical device manufacturer is developing firmware for a new continuous glucose monitor (CGM) that transmits blood glucose readings to a smartphone app and cloud platform. Under GDPR Article 25 (“Data protection by design and by default”), the firmware must embed privacy controls at the technical level.

Given: - Device: Continuous glucose monitor, worn 14 days, samples every 5 minutes - Data volume: 288 readings/day x 14 days = 4,032 readings per sensor - Data classification: Special category data (health data, GDPR Article 9) - Users: EU patients with diabetes (Type 1 and Type 2) - Regulatory: GDPR Article 25 (privacy by design), Article 9 (health data), MDR (Medical Device Regulation) - Connectivity: Bluetooth Low Energy to smartphone, HTTPS to cloud

1447.4.1 Step 1: Apply GDPR Article 25(1) - “Appropriate Technical Measures”

Privacy Requirement	Technical Implementation in Firmware	GDPR Justification
Data minimization	Transmit only aggregates unless clinically necessary	Art. 5(1)(c)
Purpose limitation	Hard-coded purpose flags in data packets	Art. 5(1)(b)
Storage limitation	On-device buffer: 24 hours max, auto-overwrite	Art. 5(1)(e)
Integrity	HMAC-SHA256 on all readings, tamper detection	Art. 5(1)(f)
Confidentiality	AES-256-GCM encryption, per-session keys	Art. 5(1)(f)

1447.4.2 Step 2: Implement Privacy-Preserving Data Transmission

/* CGM Firmware: Privacy-by-Design Data Transmission */

typedef enum {
    PRIVACY_LEVEL_RAW = 0,      // Full 5-min readings (emergency only)
    PRIVACY_LEVEL_HOURLY = 1,   // Hourly averages (clinical review)
    PRIVACY_LEVEL_DAILY = 2,    // Daily summary (trend analysis)
    PRIVACY_LEVEL_ALERT = 3     // Hypo/hyper alerts only (minimum)
} privacy_level_t;

// Default: Most restrictive level
static privacy_level_t current_privacy = PRIVACY_LEVEL_ALERT;

void transmit_glucose_data(glucose_reading_t* readings, uint16_t count) {
    switch (current_privacy) {
        case PRIVACY_LEVEL_RAW:
            // Requires explicit consent + clinical justification
            if (!verify_explicit_consent() || !verify_clinical_need()) {
                log_privacy_block("RAW_DENIED");
                return;
            }
            transmit_encrypted(readings, count, PURPOSE_CLINICAL);
            break;

        case PRIVACY_LEVEL_HOURLY:
            // Aggregate to hourly before transmission
            glucose_aggregate_t hourly = aggregate_hourly(readings, count);
            transmit_encrypted(&hourly, 1, PURPOSE_MONITORING);
            break;

        case PRIVACY_LEVEL_DAILY:
            // Only daily min/max/average
            glucose_summary_t daily = summarize_daily(readings, count);
            transmit_encrypted(&daily, 1, PURPOSE_TRENDS);
            break;

        case PRIVACY_LEVEL_ALERT:
            // Only transmit if hypo (<70) or hyper (>180)
            if (has_alert_condition(readings, count)) {
                alert_t alert = create_alert(readings, count);
                transmit_encrypted(&alert, 1, PURPOSE_SAFETY);
            }
            // Else: NO transmission (maximum privacy)
            break;
    }
}

bool verify_explicit_consent(void) {
    // Check consent flag stored in secure element
    return secure_element_read(CONSENT_RAW_DATA_FLAG) == CONSENT_GRANTED;
}

1447.4.3 Step 3: Apply GDPR Article 25(2) - “Privacy by Default”

Default Setting	Value	User Can Change?	Rationale
Transmission privacy level	ALERT (minimum)	Yes (to hourly/daily)	Most protective default
Cloud backup	OFF	Yes (opt-in)	Art. 25(2) - minimal processing
Data sharing with care team	OFF	Yes (opt-in)	Explicit consent required
Historical data retention	30 days	Yes (up to 90)	Storage limitation
Third-party research	OFF	Yes (opt-in)	Art. 9 - special category consent

1447.4.4 Step 4: Implement Consent Management in Firmware

/* Consent management for GDPR Article 7 compliance */

typedef struct {
    uint8_t raw_data_sharing : 1;      // Art. 9 explicit consent
    uint8_t care_team_access : 1;      // Art. 6(1)(a) consent
    uint8_t research_participation : 1; // Art. 9 research consent
    uint8_t cloud_backup : 1;          // Art. 6(1)(a) consent
    uint8_t reserved : 4;
    uint32_t consent_timestamp;        // When consent was given
    uint8_t consent_version;           // Privacy policy version
} consent_flags_t;

// Store consent in tamper-resistant secure element
void update_consent(consent_flags_t new_consent) {
    // Verify consent came from authenticated user
    if (!verify_user_authentication()) {
        log_security_event("CONSENT_UPDATE_REJECTED");
        return;
    }

    // Log the consent change (audit trail for Art. 7(1))
    log_consent_change(get_current_consent(), new_consent);

    // Store in secure element
    secure_element_write(CONSENT_FLAGS_ADDR, &new_consent, sizeof(new_consent));

    // Update transmission behavior immediately
    if (new_consent.raw_data_sharing) {
        current_privacy = PRIVACY_LEVEL_RAW;
    } else if (new_consent.care_team_access) {
        current_privacy = PRIVACY_LEVEL_HOURLY;
    } else {
        current_privacy = PRIVACY_LEVEL_ALERT;  // Back to default
    }
}

// Consent withdrawal (Art. 7(3) - right to withdraw)
void withdraw_consent(uint8_t consent_type) {
    consent_flags_t current = get_current_consent();

    switch (consent_type) {
        case CONSENT_RAW_DATA:
            current.raw_data_sharing = 0;
            // Immediately stop raw data transmission
            current_privacy = PRIVACY_LEVEL_ALERT;
            break;
        case CONSENT_RESEARCH:
            current.research_participation = 0;
            // Flag data for exclusion from research exports
            break;
    }

    update_consent(current);

    // Notify cloud to stop processing (Art. 7(3))
    send_consent_withdrawal_notification(consent_type);
}

1447.4.5 Step 5: Privacy Impact Assessment Metrics

Privacy Measure	Implementation Status	Risk Reduction
Encryption at rest (device)	AES-256-GCM	99% breach impact reduction
Encryption in transit (BLE)	BLE Secure Connections	95% interception prevention
Data minimization (default)	Alert-only transmission	97% data volume reduction
Purpose limitation	Hard-coded purpose flags	100% scope creep prevention
Consent enforcement	Secure element storage	Tamper-resistant consent record
Audit logging	Immutable log in flash	GDPR Art. 30 compliance

Result: The CGM firmware implements GDPR Article 25 privacy by design through multiple technical measures: default alert-only transmission (minimizing data exposure), secure element consent storage (tamper-proof), hierarchical privacy levels (user control), and hard-coded purpose limitation (preventing scope creep). The DPIA demonstrates 97% reduction in transmitted data volume compared to naive “send everything” designs while maintaining full clinical functionality.

Key Insight: GDPR Article 25 requires privacy to be “baked in” at the technical level, not added as configuration. For medical IoT, this means firmware must enforce privacy defaults that cannot be overridden by cloud configuration. The secure element storage of consent prevents tampering, and the hierarchical transmission levels demonstrate proportionality - more data is only transmitted when clinically justified AND user-consented. This approach satisfies both GDPR and Medical Device Regulation (MDR) requirements.

1447.5 Knowledge Check: GDPR Compliance

NoteQuiz: GDPR for IoT

Question 1: Your IoT deployment uses WPA2-PSK Wi-Fi security. A new employee needs access, so you share the Wi-Fi password. Two years later, that employee leaves. What security vulnerability exists?

Explanation: WPA2-PSK lacks forward secrecy and access revocation! The problem: PSK = same password for everyone, no individual credentials, cannot revoke access for one person. Solutions: WPA2-Enterprise (802.1X/EAP) with individual credentials, WPA3-SAE with forward secrecy, or network segmentation. The fundamental flaw: shared secrets can’t be unshared!

Question 2: An attacker captures encrypted WPA2 handshakes from your IoT network, then runs a dictionary attack offline. Which WPA3 feature prevents this attack?

Explanation: SAE (Dragonfly handshake) is the key defense! WPA2 vulnerability: 4-way handshake can be captured passively, then attacker tries millions of passwords OFFLINE. WPA3’s SAE protection: Uses Dragonfly protocol requiring interaction with access point, can’t capture and crack offline, AP can throttle attempts, and forward secrecy protects past sessions. With WPA3 SAE, attackers can’t take handshakes home for leisurely cracking!

Question 3: Your IoT firmware update system uses HTTPS to download firmware, verifying the server certificate. However, firmware is not cryptographically signed. What attack remains possible?

Explanation: HTTPS only protects the CHANNEL, not the CONTENT! HTTPS protects connection encryption and server authentication, but doesn’t protect content authenticity if server is compromised. Code signing fills the gap: vendor signs firmware with private key, device verifies signature with public key embedded in OTP/ROM. Real attack: 2017 NotPetya malware distributed via compromised update server using HTTPS!

Question 4: Which McCumber Cube dimension is violated when an IoT company has perfect encryption and comprehensive policies, but employees click phishing links installing malware?

Explanation: This is a People (human) dimension failure! The McCumber Cube has three countermeasure dimensions: Technology (strong encryption), Policy & Practice (comprehensive policies), and People (training, awareness, culture). People are the weakest link - best encryption can’t protect against users giving away credentials. The 90/10 rule: 90% of breaches involve human error, only 10% purely technical.

Question 5: True or False: The distinction between security and safety in IoT systems is that security protects against intentional malicious attacks while safety protects against unintentional accidents and failures.

Explanation: TRUE - this is the fundamental security vs safety distinction. Security addresses intentional threats (hackers, malware, sabotage) with adversarial model. Safety addresses unintentional hazards (hardware failures, software bugs, human error) with non-adversarial model. Critical overlap: Security breach can cause safety incident (Stuxnet sabotaged centrifuges). IoT requires both - medical devices need security (prevent hacking) AND safety (prevent harmful dosage errors).

1447.6 Visual Reference Gallery

NoteVisual: NIST Cybersecurity Framework

NIST Framework five core functions

The NIST Framework provides a comprehensive approach to cybersecurity through five interconnected functions.

NoteVisual: Network Segmentation Architecture

Network zones and traffic isolation

Network segmentation limits breach impact by isolating IoT devices into security zones.

1447.7 Summary

Comprehensive GDPR compliance for IoT requires:

Erasure (Article 17): - 30-day deadline from request receipt - Cascade notifications to all processors - Handle shared household data carefully - Document exemptions (legal retention) - Anonymize when deletion violates other laws

Privacy by Design (Article 25): - Privacy defaults at firmware level - Data minimization as default transmission mode - Consent stored in tamper-resistant secure elements - Purpose limitation through hard-coded flags - Hierarchical privacy levels based on consent

Key Compliance Principles: - Each vendor is an independent data controller - Technical controls must enforce privacy defaults - Audit trails demonstrate compliance - Anonymization acceptable when full deletion impossible

1447.8 What’s Next

With compliance and GDPR frameworks understood, continue your security journey by exploring IoT Devices and Network Security where you’ll learn to secure device architectures, implement secure boot, and establish device lifecycle management.

Continue to IoT Devices and Network Security

NoteRelated Chapters

Security Foundations: - NIST Framework - Framework for organizing security - Security Controls - Technical implementation

Privacy: - Introduction to Privacy - Privacy fundamentals - Privacy by Design - Building privacy in

Device Security: - Device Security - Securing IoT devices - Secure Data - Data protection strategies

1447.9 Further Reading

• GDPR Official Text (EUR-Lex)
• EDPB Guidelines on Right to Erasure
• NIST SP 800-53: Security Controls
• ISO/IEC 27701: Privacy Information Management
• CNIL Guidelines for IoT Privacy