GDPR and Industrial IoT: What Predictive Maintenance Teams Need to Know

The Compliance Blind Spot

Your vibration sensors don't collect personal data — or do they?

Most plant engineers think of GDPR as a marketing and HR problem. But the moment your predictive maintenance system logs operator actions, shift patterns, equipment assignments linked to personnel, or even IP addresses from IoT gateways, you're processing personal data under GDPR Article 4.

A 2025 survey by the European Data Protection Board found that 43% of industrial IoT deployments had at least one GDPR compliance gap they weren't aware of. The fines aren't theoretical: a German manufacturer was fined €1.2M in 2025 for a monitoring system that tracked individual operator performance without proper consent.

Where PdM Meets Personal Data

Here's what actually counts as personal data in a predictive maintenance context:

Clearly Personal

Operator login credentials and session logs
Shift assignment records tied to individuals
Work order assignments ("Operator Schmidt replaced bearing on Asset 41")
Mobile app push notification tokens
Email addresses for alert routing

The Gray Zone

Machine operating parameters during specific shifts (can identify operators indirectly)
Maintenance logs with technician names
Access badge records correlated with equipment events
Video feeds from machine areas (even if intended for equipment monitoring)

Not Personal Data

Raw vibration, temperature, pressure readings from sensors
ML model predictions and anomaly scores
Equipment health indices
Aggregate production metrics

Six Principles for GDPR-Compliant PdM

1. Data Minimization — Collect What You Need

The principle: Only process personal data that's adequate, relevant, and limited to what's necessary (Article 5(1)(c)).

In practice:

Sensor data doesn't need operator attribution. A vibration reading from Pump 7A is about the pump, not the person operating it.
If your CMMS integration pulls operator names into work orders, decide: do you need the name for PdM, or just the fact that maintenance was performed?
Strip IP addresses from MQTT/OPC-UA connection logs unless you need them for security auditing.

Prevly's approach: Sensor readings are stored with asset_id and tenant_id only. No operator identity is attached to time-series data. Work orders reference roles, not individuals, unless the customer explicitly enables personnel tracking.

2. Purpose Limitation — Define Why

Sensor data collected for predictive maintenance cannot be repurposed for operator performance monitoring without a separate legal basis. This sounds obvious, but it happens constantly when:

A plant manager asks "which shift has more equipment failures?"
HR requests maintenance logs to evaluate technician response times
Insurance wants operator-level incident data

Best practice: Document your processing purposes in a Record of Processing Activities (ROPA) before deployment. Prevly's data processing agreement (DPA) explicitly limits processing to equipment health prediction and maintenance optimization.

3. Retention — Don't Hoard Data

The principle: Personal data must be kept no longer than necessary (Article 5(1)(e)).

The challenge with PdM: ML models improve with more historical data. A Weibull-RNN for remaining useful life prediction benefits from 2+ years of failure history. But do you need 2 years of operator logs?

Tiered retention strategy: | Data Type | Hot Storage | Cold Archive | Deletion | |---|---|---|---| | Sensor readings | 90 days | 2 years (S3 Parquet) | After archive expiry | | ML predictions | 1 year | 3 years | After archive expiry | | Audit logs (with user IDs) | 90 days | 1 year | Mandatory deletion | | Operator work orders | 30 days | Per legal requirement | Per policy | | Aggregate statistics | Indefinite | — | Never (anonymized) |

4. Multi-Tenancy Isolation — Your Data Stays Yours

In multi-tenant SaaS, the biggest GDPR risk isn't a hacker — it's a software bug that leaks Tenant A's data to Tenant B.

Requirements for GDPR-grade isolation:

Row-Level Security (RLS): Every database query is automatically scoped to the authenticated tenant. Not application-level filtering — database-enforced.
Encryption at rest: Per-tenant encryption keys (or at minimum, per-tenant logical isolation with AES-256).
Network isolation: Premium tenants may require dedicated infrastructure (GDPR doesn't mandate this, but risk-averse industries demand it).
Audit trail: Who accessed what data, when. SOC 2 Type II gives you this as a side effect.

5. Cross-Border Transfers — Where Does Your Data Live?

Post-Schrems II, transferring personal data outside the EU requires Standard Contractual Clauses (SCCs) or an adequacy decision.

For industrial IoT, this matters when:

Your cloud provider has data centers outside the EU
Your PdM vendor processes data in a non-EU region
Edge devices transmit diagnostics to a vendor's US-based support system

Solution: Choose a platform with EU data residency options. Prevly's infrastructure runs in EU regions by default, with data residency guarantees in the DPA.

6. Data Subject Rights — Yes, Even for Engineers

Your maintenance engineers have the right to:

Access their personal data (Article 15)
Rectification of inaccurate data (Article 16)
Erasure ("right to be forgotten") of their data (Article 17)
Data portability — export their data in a machine-readable format (Article 20)

If an engineer leaves the company and requests deletion, can your PdM system remove their name from historical work orders while preserving the maintenance history?

Design for this from day one. It's much harder to retrofit GDPR compliance than to build it in.

The Checklist

Before deploying predictive maintenance in the EU:

[ ] ROPA entry for PdM data processing. Create a dedicated entry in your Record of Processing Activities that covers all PdM-related data: sensor readings, ML predictions, work orders, and any operator-linked data. Include the legal basis (typically legitimate interest for equipment monitoring, consent for operator tracking), data categories, recipients, and retention periods. This is mandatory under Article 30 for organizations with 250+ employees, and strongly recommended for smaller ones.
[ ] DPA signed with your PdM vendor. Your Data Processing Agreement must specify the vendor's role (processor), the types of data processed, security measures, sub-processor disclosure, and data deletion procedures upon contract termination. Under Article 28, you're required to use only processors with sufficient guarantees. Request the vendor's most recent SOC 2 Type II report or ISO 27001 certificate as evidence.
[ ] Data flow map showing where sensor and personal data moves. Diagram every hop: sensor → edge gateway → cloud ingestion → database → ML pipeline → alert engine → notification channels. For each hop, note whether personal data is present, what encryption is in transit (TLS 1.2+), and whether data crosses any national borders. This map is essential for both DPIA and for answering supervisory authority inquiries.
[ ] Retention policy with automated deletion for personal data. Don't rely on manual cleanup. Configure automated retention rules: sensor readings archived at 90 days, audit logs with user IDs deleted at 12 months, work order operator references anonymized at offboarding. Test the deletion process — run it in staging and verify that personal data is actually removed from backups within a defined window (GDPR doesn't require instant backup deletion, but you need a documented timeline).
[ ] RLS verified — multi-tenant isolation tested, not just documented. Run penetration tests specifically targeting cross-tenant data access. This means: authenticate as Tenant A, attempt to query Tenant B's data through every API endpoint, direct database connection, and export function. Database-level row-level security should make this impossible regardless of application bugs. Document the test results.
[ ] Cookie consent on any web dashboards. Yes, the maintenance dashboard counts. If it runs in a browser and sets cookies or uses analytics (even internal analytics), you need a GDPR-compliant consent banner with granular accept/reject options. "Strictly necessary" cookies (session auth) don't require consent; analytics and tracking cookies do.
[ ] Breach notification plan — 72-hour reporting to supervisory authority. Define the escalation chain: who detects the breach, who assesses severity, who notifies the DPO, who files with the supervisory authority. The 72-hour clock starts when you become "aware" of the breach — not when you finish investigating. Have the notification template pre-drafted with your supervisory authority's required fields.
[ ] DPIA completed if processing at scale or using automated decision-making. A Data Protection Impact Assessment is mandatory under Article 35 when processing creates high risk — which includes large-scale monitoring (thousands of sensors, multiple facilities) and automated decisions that affect individuals (e.g., work order assignments, performance-correlated metrics). The DPIA should identify risks, mitigation measures, and residual risk acceptance.

Common Mistakes to Avoid

Three patterns consistently cause GDPR problems in industrial IoT deployments:

Treating all sensor data as non-personal by default. Raw vibration data is indeed non-personal. But the moment you join it with shift schedules, operator logins, or maintenance assignments, it becomes personal data by association. The safest approach: keep sensor data and personnel data in separate data stores, joined only when explicitly needed and with documented purpose.

Relying on application-level access control. If your multi-tenant isolation is enforced in application code ("WHERE tenant_id = ?"), a single bug exposes all tenants. Database-level row-level security is the GDPR-grade standard — it enforces isolation at the query execution layer, independent of application logic. Every query, every API call, every export is scoped by the database itself.

No data deletion capability for personal data. Many PdM systems are architected for append-only time-series storage, which is excellent for ML training but problematic for GDPR's right to erasure. Design your schema so that operator identifiers in work orders and audit logs can be anonymized (replaced with "deleted_user_") without destroying the maintenance history that your ML models need.

The Bottom Line

GDPR isn't anti-innovation. It's a framework that forces you to think about data architecture — which you should be doing anyway for a production PdM system. The companies that treat compliance as a design constraint (not an afterthought) end up with cleaner architectures, better data governance, and systems their customers actually trust.

Prevly was built GDPR-first: row-level security, tiered retention, EU data residency, consent-gated analytics, and data export APIs. Because in industrial IoT, trust isn't optional — it's the prerequisite for your first pilot.