EN 18031-2, What Counts as Personal, Traffic, and Location Data for Connected Radio equipment
EN 18031-2 is the part of the EN 18031 standards family focused on data protection and privacy for radio equipment. It supports RED Article 3(3)(e), which requires certain products in scope to include safeguards that protect personal data and user privacy.
A common practical question is what data actually brings a product into scope. That is usually where real scoping work starts. This blog looks at what personal, traffic, and location data mean in practice, and what manufacturers should review before launch.
Start your free EN 18031 assessment
What is EN 18031-2?
EN 18031-2:2024 is titled Common security requirements for radio equipment, Part 2: Radio equipment processing data, namely internet-connected radio equipment, childcare radio equipment, toy radio equipment, and wearable radio equipment.
It provides a technical route manufacturers can use to support conformity with RED Article 3(3)(e). Part 1 focuses on protection of networks and network resources for internet-connected radio equipment. Part 2 focuses on radio equipment that processes personal, traffic, or location data, including internet-connected radio equipment, childcare radio equipment, toy radio equipment, and wearable radio equipment. That matters because some of these categories are in scope even where direct internet connectivity is not the main issue.
What Counts as Childcare, Toy, and Wearable Radio Equipment?
EN 18031-2 is not limited to internet-connected products. Under Delegated Regulation (EU) 2022/30, RED Article 3(3)(e) also applies, when the relevant data is processed, to radio equipment designed or intended exclusively for childcare, radio equipment covered by the Toys Directive, and radio equipment designed or intended to be worn on, strapped to, or hung from the body or from clothing worn by a person.
These are scope categories, not just marketing labels. For childcare equipment, the Commission gives child monitors as an example. For toys, the category covers radio equipment that falls under Directive 2009/48/EC, in other words toys with a radio function that also fall within the EU toy safety framework. For wearable radio equipment, the delegated regulation gives concrete examples such as wrist watches, rings, wristbands, headsets, earphones, and glasses.
This matters because these categories can fall under Article 3(3)(e) even where direct internet connectivity is not the main issue. The Commission explains that childcare radio equipment, toys, and wearable radio equipment can create privacy and data protection risks even without an internet connection, because they may emit or receive radio waves, monitor sensitive personal data over time, and retransmit that data through insecure communication channels.
One important boundary is that implants are not treated as wearable radio equipment under this definition, because they are not worn on, strapped to, or hung from the body or clothing. However, implants may still count as internet-connected radio equipment if they are themselves capable of communicating over the internet.
What Data Categories Trigger EN 18031-2?
Article 3(3)(e) refers to three data categories: personal data, traffic data, and location data. EN 18031-2 becomes relevant when a product in scope processes any of these. That is why understanding the categories properly matters for scoping.
Personal Data
Personal data means any information relating to an identified or identifiable natural person. In connected radio equipment, that can cover more than teams first expect.
It includes obvious examples such as names, email addresses, account credentials, and payment details. It can also include:
device identifiers linked to a specific user
usage patterns or behavioral data that can be tied to an individual
health or biometric data collected by wearables
images or audio captured by connected cameras or microphones
data that can identify a person when combined with other information
The key question is whether the data can be linked to an identifiable individual. That link may be direct, or it may come from combining different data points across the device, app, backend, or account layer.
Traffic Data
Traffic data is data processed for the purpose of conveying a communication over an electronic communications network. In practical terms, this often includes:
information about when a communication happened
connection duration
routing information
session metadata
logs showing how the product communicated with external services
This category is often missed because it sits in the background. A product may not look data-heavy at first glance, but once it connects to a backend, creates connection logs, or routes activity through an app, traffic data may already be in play.
Location Data
Location data is data that indicates the geographic position of a user’s terminal equipment. For connected radio equipment, this can include:
GPS coordinates
Wi-Fi or cell-based positioning
location inferred from IP address or network identifiers
movement or proximity data that reveals where a user is or has been
This is especially relevant for wearables, fitness devices, GPS products, connected vehicles, and products with geofencing or location-aware functions. Location may also be inferred indirectly, even where the product does not present itself as a location device.
Why the Data Category Question Matters for Scoping
These definitions matter because the EN 18031-2 scope depends on what data the product processes, not only on the product’s headline feature.
A product may not be designed as a data-focused product and still process relevant data as part of its normal connected operation.
Examples include:
a smart home device that logs use patterns tied to user accounts
a connected appliance that sends telemetry with IP addresses and timestamps
a fitness product that infers movement through network signals
a toy with a companion app that collects account information and usage data
a wearable that combines health metrics with account-linked information
In each case, the device alone does not show the full picture. Once the product ecosystem is mapped across device, app, backend, account system, and third-party integrations, the real data-processing scope becomes clearer.
This also matters for childcare devices, toys, and wearables. A product should not be treated as out of scope simply because it is not directly internet-connected. If it falls into one of these categories and processes the relevant data, EN 18031-2 may still apply.
What Manufacturers Should be Documenting
Once the product’s data-processing scope is clear, the next step is connecting that to the technical file. Manufacturers usually need to show that safeguards exist and that those safeguards can be supported with documentation. Typical documentation may include:
a data inventory showing what personal, traffic, and location data is processed
data flow documentation across device, app, backend, and third-party services
access-control documentation showing who or what can access data
controls for secure storage and transmission
retention and deletion processes
user rights or user data handling processes where relevant
third-party processor documentation where relevant
requirement mapping linked to EN 18031-2
technical file materials tied to Article 3(3)(e)
For a deeper look at how to structure this evidence, see EN 18031 requirements and evidence checklist.
Where Teams Usually Get Stuck
A common issue is not lack of privacy work. It is that privacy work sits in the wrong place.
Privacy documentation often sits with legal or data protection roles, while compliance and engineering own the technical file inputs. That split creates gaps that show up later.
Typical problems include:
reviewing data flows at device level only
defining personal data too narrowly
missing traffic data altogether
overlooking location data inferred from network signals
leaving third-party SDKs or analytics tools out of scope
having privacy documentation that does not support technical file needs
These are all signs that the internal review needs to go deeper before launch.
How Cyberexpert Helps
Cyberexpert helps teams identify what data the product processes, map that across the connected ecosystem, and build the structured evidence needed for the technical file.
For the broader context on how Part 2 fits within the EN 18031 family, see the EN 18031 overview.
Start your free EN 18031 assessment.
Related Articles
