Why Your GDPR Personal Data Isn't Always an EN 18031-2 Privacy Asset (And Why That Matters)

If you’re encrypting every piece of GDPR-defined personal data in your IoT device because EN 18031-2 requires privacy asset protection, you’re likely overengineering your solution—and still might fail compliance.

Most engineers approaching EN 18031-2 for the first time make a logical but incorrect assumption: since the standard deals with cybersecurity and the GDPR defines personal data broadly, all personal data must be protected as privacy assets. This interpretation leads to impossible implementation requirements and unnecessary complexity that can actually prevent compliance.

The reality is more nuanced. EN 18031-2 creates three distinct categories for handling personal information, each with different security requirements. Understanding these distinctions isn’t just academic—it determines whether your product can meet EU market requirements while remaining technically feasible and cost-effective.

This article breaks down the actual relationship between personal data and EN 18031-2 assets, provides clear classification criteria, and shows you how to avoid the common pitfalls that lead to either non-compliance or overengineered solutions that can’t ship.

Note: This article presents Easynorm’s practical framework for understanding EN 18031-2’s requirements. We’ve distilled complex standards language into actionable engineering guidance. For implementation in your specific products, always reference the official standard text and consider professional compliance support.

The GDPR Personal Data Trap

The EU GDPR defines personal data exceptionally broadly: any information relating to an identified or identifiable natural person. Under this definition, even a device’s MAC address, an IP address, or a randomly generated session ID could be personal data if it can be linked back to a user.

If you apply EN 18031-2’s privacy asset requirements to all GDPR personal data, you’d need to:

• Encrypt and authenticate every piece of this data in transit
• Apply strict access controls to all storage locations
• Implement deletion mechanisms for all stored data
• Document security measures for potentially hundreds of data elements

In practice, this requires implementing bank-grade security for data that may have minimal privacy impact. Worse, it’s often technically impossible—protocol handshakes require unencrypted identifiers before secure channels can be established, and IP addresses remain visible even when using TLS/HTTPS since routers need them to deliver packets.

Here’s the key insight: EN 18031-2 starts with “personal information” (which encompasses GDPR personal data, traffic data, and location data) but only elevates it to a “privacy asset” when disclosure or manipulation would actually compromise privacy. Not all personal information needs privacy asset protection—only the subset where unauthorized access or tampering creates real privacy harm.

The Three Categories You Actually Need

The following framework simplifies EN 18031-2’s asset classification approach into three practical categories for engineering teams. While the standard itself uses different structural terminology, this organization helps you understand what needs protection and why.

EN 18031-2 splits personal information into three operational categories, each with different protection requirements:

1. Privacy Assets

These are personal information elements whose disclosure or manipulation would compromise user or subscriber privacy. Note the emphasis on actual privacy impact, not theoretical linkability.

Privacy assets may include:

• User credentials and authentication tokens
• Biometric data and health information
• Location tracking data with user identification
• Communications content and metadata
• Privacy functions (applications that process personal information)
• Confidential or sensitive privacy function configuration

Protection requirements: Full encryption in transit, authentication of endpoints, access controls, secure storage.

2. Security Assets (Containing Personal Information)

Some personal information serves a security function and gets classified as a “sensitive security parameter” within security assets. The classic example: a user identifier transmitted to initiate a key exchange.

This data is personal (identifies a user) but its primary function is security, not privacy. Protecting it as a privacy asset would be circular—you can’t encrypt the identifier needed to establish encryption.

Protection requirements: Secure storage, access controls, but not necessarily encryption during protocol negotiation phases.

3. Unclassified Personal Information

Personal information that doesn’t meet the criteria for privacy or security assets still has requirements under EN 18031-2, particularly around Deletion Mechanisms [DLM]. However, it doesn’t require the comprehensive protection of privacy assets.

Examples might include:

• Device serial numbers linked to user
• Configuration of services not impacting privacy or security

Protection requirements: Secure deletion capabilities, but not necessarily encryption.

Real-World Classification Examples

Let’s examine how the same data element might be classified differently based on context:

Device MAC Address

• As privacy asset: Logged across locations revealing user movement patterns
• As security asset: Authentication parameter used in network access control
• As unclassified: Standard network identifier visible to local routers

Session Identifiers

• As privacy asset: Long-lived tokens that could reveal usage patterns
• As security asset: Temporary IDs for establishing secure connections
• As unclassified: Anonymous crash report IDs with no user linkage

The classification depends on the actual privacy impact and security function, not on whether GDPR might consider it personal data.

The Risks of Getting It Wrong

Overclassification Problems

Treating all personal data as privacy assets creates:

• Technical impossibilities: You can’t encrypt data needed to establish encryption
• Performance degradation: Excessive cryptographic operations on non-sensitive data
• Increased attack surface: Complex security systems have more vulnerabilities
• Cost escalation: Unnecessary hardware security modules and key management
• Compliance failure: Ironically, overprotection can result to impossibilities that prevent you from meeting EN 18031-2

Underclassification Problems

Failing to properly identify privacy assets leads to:

• Regulatory non-compliance: Missing required protections for sensitive data
• Market access denial: Products can’t receive CE marking
• Privacy breaches: Actual user privacy compromise
• Reputation damage: Public disclosure of inadequate protection
• Legal liability: GDPR and RED penalties still apply to the underlying personal data

Practical Classification Process

The following process reflects our experience implementing EN 18031-2 across hundreds of IoT products. Your specific classification decisions should account for your product’s architecture, use cases, and risk profile—work with compliance professionals familiar with your industry.

To correctly classify personal information in your device:

Step 1: Inventory All Personal Information

List every data element that could identify or relate to a person, regardless of how indirect the connection might be.

Step 2: Apply the Privacy Asset Test

For each element, ask: “Would unauthorized disclosure or manipulation directly compromise user privacy?”

• If yes → Privacy asset
• If no → Continue to Step 3

Step 3: Apply the Security Asset Test

Does this personal information serve a security function where protection would be circular or impossible?

• If yes → Security asset (sensitive security parameter)
• If no → Continue to Step 4

Step 4: Apply Deletion Mechanism Requirements

Even unclassified personal information needs appropriate deletion mechanisms, e.g., when transferring to another user or performing a factory reset.

• Implement secure deletion capabilities
• Document handling procedures

Moving from Theory to Implementation

Understanding these distinctions is critical, but implementing them correctly while meeting all EN 18031-2 requirements demands significant expertise. You need to:

• Map every data flow in your device
• Assess privacy impact for each element
• Design proportionate security measures
• Generate compliant technical documentation
• Validate your classifications against the standard

This is where systematic approaches prove their value. Rather than interpreting these requirements from scratch for each product, working with predefined device profiles and validated classification templates ensures consistency and compliance.

Next Steps for Your EN 18031-2 Compliance

The relationship between personal data and privacy assets in EN 18031-2 is complex but manageable once you understand the framework. The key is recognizing that not all personal data requires the same level of protection—the standard is designed to be proportionate to actual privacy risks.

Important: This article has simplified EN 18031-2’s requirements to help engineers grasp the core concepts. The actual standard contains additional nuances, exceptions, and requirements specific to different device types and use cases. Your compliance journey should include:

1. Reviewing the official EN 18031-2 standard text for your specific requirements
2. Consulting with compliance professionals who understand both the standard and your product domain
3. Documenting your classification rationale based on actual privacy impact assessments
4. Validating your approach against the complete standard requirements

To implement this correctly:

1. Start with a complete inventory of personal information in your device
2. Apply the three-category classification systematically
3. Document your rationale for each classification decision
4. Implement appropriate protections for each category
5. Generate the technical documentation proving your compliance

The Easynorm platform streamlines this entire process with pre-validated device profiles for common IoT products. Our assessments are built on deep EN 18031-2 expertise and hundreds of successful implementations, but we always recommend reviewing your specific compliance needs with qualified professionals who understand your unique product requirements.

Ready to simplify your EN 18031-2 compliance? Our platform guides you through personal data classification with clear, engineering-focused assessments that generate the technical documentation EU authorities require. While this blog simplifies complex concepts for clarity, our platform handles the full standard requirements. Schedule a demo to see how we turn these complex requirements into actionable implementation steps—most customers complete their assessment in just 3 weeks, working at their own pace.

---

This article is part of Easynorm’s educational series on EN 18031 compliance. It presents our interpretation and practical framework based on extensive implementation experience. For authoritative guidance, consult the official EN 18031-2:2024 standard.

Header image: Aerial photography of city by Unsplash