Is pseudonymised telemetry personal data?

Usually yes. Article 4, point (5), GDPR describes pseudonymisation as processing after which the data can no longer be attributed to a specific data subject without additional information, so attribution stays possible in principle. Only genuine anonymisation, where the person is not or no longer identifiable, takes data outside the scope. For data minimisation, pseudonymisation therefore lowers the risk without answering the prior question of whether you need the data for the intended purpose at all.

Who reports what when an incident involves personal data?

Two duties with different addressees run in parallel. Under Article 14 CRA the manufacturer notifies the CSIRT designated as coordinator and ENISA, with the early warning due within 24 hours of becoming aware of an actively exploited vulnerability. Under Article 33 GDPR the controller notifies the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours. These are rarely the same organisation, and neither notification substitutes for the other.

Do we have to encrypt personal data?

The CRA does not mandate encryption outright. Annex I, Part I, point (2)(e) requires confidentiality to be protected and offers encryption of relevant data at rest or in transit by state of the art mechanisms as an example, expressly alongside other technical means. Choose other means without relying on a harmonised standard, a common specification or a European cybersecurity certification scheme and Annex VII, point (5) requires the technical documentation to describe the solution adopted. In practice, writing that description costs more than encrypting would have.

Cyber Resilience Act

Personal data

Legal definition Art. 3(47) CRA

“personal data as defined in Article 4, point (1), of Regulation (EU) 2016/679”

Regulation (EU) 2024/2847, Art. 3(47) CRA

Personal data is not a term the Cyber Resilience Act (CRA) defines for itself. Article 3, point (47) points to Article 4, point (1), of Regulation (EU) 2016/679, the General Data Protection Regulation (GDPR). There it covers any information relating to an identified or identifiable natural person. Identifiability may arise indirectly, through an identification number, location data, an online identifier or factors specific to that person’s identity.

What matters for product work is how far that reaches. Device serial numbers, account identifiers, IP addresses in log files and telemetry qualify as soon as they can be attributed to a person, for instance through a user account.

Where the term actually appears

The defined term is used in exactly three places in the operative part of the CRA: Annex I, Part I, point (2), letters (e), (f) and (g), Article 7(2), point (b), and Article 52(7). Searching the regulation for data protection duties therefore turns up very little, and that is no oversight.

Annex I protects data irrespective of its kind. Each of the three relevant letters speaks of data, “personal or other”. Whether a given field holds personal data almost never decides whether a requirement applies. It decides how heavily the risk weighs in the assessment Article 13(2) requires.

What Annex I asks for

Letter (e): protect the confidentiality of stored, transmitted or otherwise processed data, for instance by encryption using state of the art mechanisms
Letter (f): protect the integrity of data, commands, programs and configuration against manipulation or modification not authorised by the user, and report on corruptions
Letter (g): process only data that are adequate, relevant and limited to what is necessary (data minimisation)
Letter (m): let users securely and easily remove all data and settings on a permanent basis, and make any transfer to other products or systems secure

Letter (g) is the striking one. Data minimisation is a data protection principle, and here it sits inside a product regulation. Its yardstick is not user consent but the Intended purpose of the product.

Everything in Annex I, Part I, point (2) applies on the basis of the cybersecurity risk assessment under Article 13(2) and only “where applicable”. Where one of those requirements does not apply to your product, Article 13(4) wants a clear justification in the Technical documentation.

The CRA and the GDPR run side by side

Recital 32 says the CRA should apply without prejudice to the GDPR. No article says so; the recital is the only place it appears. The two regulations bind different parties: the CRA binds the manufacturer as an economic operator, the GDPR binds the controller and the processor. Whoever supplies a product is, as a rule, not the controller for the data an operator processes with it. The same recital still expects a contribution from the Essential cybersecurity requirements: better protection of personal data and of the privacy of individuals.

Article 52(7) carries the sharper practical consequence. Market surveillance authorities cooperate, as appropriate, with the authorities supervising Union data protection law. Those authorities may request and access any documentation created or maintained under the CRA where they need it for their tasks. Your technical documentation is therefore within reach of the data protection regulator.

Two places where processing data shifts your position

Article 7(2), point (b) names the processing of personal data as an example of a central system function. That is one of the criteria for counting a product category among the Important products with digital elements. The order matters: Annex III governs. A product does not become important merely because it processes personal data, because the criterion binds the Commission when it amends Annex III under Article 7(3).

Recital 15, by contrast, goes to scope. Requiring the processing of personal data as a condition for use, for reasons other than exclusively improving the security, compatibility or interoperability of the software, may characterise a commercial activity. For Free and open-source software that is the decisive lever: a product that costs nothing can still fall inside the CRA because of its data model.

Practical questions

: Usually yes. Article 4, point (5), GDPR describes pseudonymisation as processing after which the data can no longer be attributed to a specific data subject without additional information, so attribution stays possible in principle. Only genuine anonymisation, where the person is not or no longer identifiable, takes data outside the scope. For data minimisation, pseudonymisation therefore lowers the risk without answering the prior question of whether you need the data for the intended purpose at all.
: Two duties with different addressees run in parallel. Under Article 14 CRA the manufacturer notifies the CSIRT designated as coordinator and ENISA, with the early warning due within 24 hours of becoming aware of an actively exploited vulnerability. Under Article 33 GDPR the controller notifies the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours. These are rarely the same organisation, and neither notification substitutes for the other.
: The CRA does not mandate encryption outright. Annex I, Part I, point (2)(e) requires confidentiality to be protected and offers encryption of relevant data at rest or in transit by state of the art mechanisms as an example, expressly alongside other technical means. Choose other means without relying on a harmonised standard, a common specification or a European cybersecurity certification scheme and Annex VII, point (5) requires the technical documentation to describe the solution adopted. In practice, writing that description costs more than encrypting would have.

This glossary is for orientation and does not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.