CRA data minimisation asks manufacturers to justify why the product processes particular data in relation to its intended purpose. Teams should inventory data collection and processing, separate necessary product or security information from merely convenient collection, minimise telemetry and diagnostics where possible, review retention and secondary copies, and reassess necessity when features or product purposes change.
Data Minimisation Is an Annex I Cybersecurity Requirement
Annex I Part I point 2(g) requires products with digital elements, on the basis of the cybersecurity risk assessment and where applicable, to process only data that are adequate, relevant and limited to what is necessary in relation to the product's intended purpose. The wording covers personal data and other data. This makes minimisation part of the CRA product-security framework rather than a rule limited to privacy-regulated information. Unnecessary data can increase the consequences of compromise, expand storage and transmission paths, increase access requirements and create additional information that must be protected throughout the product lifecycle.
- Identify what data the product processes.
- Connect each category to an intended product purpose.
- Assess whether the data are necessary.
- Remove unnecessary collection or processing.
- Document the reasoning.
The Intended Purpose Is the Reference Point
The CRA wording ties necessity to the intended purpose of the product with digital elements. Manufacturers should therefore be able to explain the purpose served by each material category of collected or processed information. Data that are genuinely required for a core product function can be easier to justify than information collected only because it may become useful for future analytics. The analysis should also distinguish the product's intended purpose from every technically possible use of the information. Where a new feature creates a new reason to process data, the manufacturer should review whether the intended-purpose documentation, cybersecurity risk assessment and minimisation decision need to change.
- Define the relevant product purpose.
- Map data categories to product functions.
- Challenge speculative collection.
- Review new features before expanding processing.
- Keep intended-purpose assumptions documented.
The Requirement Covers Personal and Non-Personal Data
Annex I point 2(g) expressly refers to personal or other data. Product teams should therefore avoid limiting the inventory to names, identifiers or information normally handled by privacy teams. Operational telemetry, network information, device configuration, industrial measurements, security events, command histories, performance information and other non-personal data can still create cybersecurity exposure. A compromise can reveal sensitive product operation or give an attacker information useful for further attacks even when the data do not identify a natural person. The minimisation exercise should therefore start from the product's complete data flows and then classify why each type of information is necessary.
- Include personal data.
- Include operational data.
- Include telemetry and diagnostics.
- Include configuration and security information.
- Include temporary and derived data.
Telemetry Should Have a Defined Security or Product Purpose
Telemetry can support reliability, security, support and product improvement, but broad collection can create additional cybersecurity risk. Manufacturers should identify which telemetry fields are necessary for the product's intended purpose and whether the same objective can be achieved with less information. Device identifiers, precise timestamps, user activity, network details, command history and configuration can become sensitive when combined. The analysis should also consider how often telemetry is transmitted, where it is stored and who can access it. Default collection should not be justified simply because storage is inexpensive or the data may become useful later.
- Define the purpose of each telemetry category.
- Remove fields without a clear need.
- Reduce precision where full detail is unnecessary.
- Limit transmission frequency where appropriate.
- Review access and retention.
Security Logging Still Needs Minimisation
Annex I also contains a requirement to provide security-related information by recording and monitoring relevant internal activity. That does not mean a product should record every available field without limit. Security logging and data minimisation should be designed together. A useful security event can identify an access attempt or configuration change without storing passwords, access tokens, cryptographic secrets or complete sensitive payloads. The manufacturer should determine which event information is necessary for detection and investigation and avoid collection that creates unnecessary exposure. Log retention and export paths should also be considered because minimised collection can still become excessive if information is retained indefinitely without a product need.
- Record information necessary for security use.
- Avoid secrets in logs.
- Avoid unnecessary payload capture.
- Review retention needs.
- Protect exported or centralised logs.
Diagnostics and Support Bundles Can Create Hidden Collection
Diagnostic tools frequently collect more information than normal product operation. Support bundles can include logs, configuration, database extracts, system information and identifiers. Crash dumps can contain memory that was never intended to be stored as a separate dataset. Manufacturers should inventory these paths and determine whether the collection is necessary for the intended support or security purpose. Where detailed collection is needed only for an exceptional troubleshooting case, an explicit user or administrator action can produce a different risk profile from permanent background collection. The resulting files should still receive appropriate confidentiality and integrity protection.
- Inventory diagnostic collection.
- Review crash-dump content.
- Review support bundles.
- Separate routine from exceptional collection.
- Protect diagnostic exports.
Data Minimisation Is Not Only About Collection
The Annex I wording uses process, so manufacturers should consider more than the moment data enter the product. Unnecessary transformation, copying, transmission, caching and storage can all expand the product's exposure. A value may be required briefly for one operation but not need to remain in long-term storage. Another value may be necessary locally but not need to be sent to a remote service. Mapping the full lifecycle of each important data category can reveal opportunities to reduce risk without removing the underlying product function. Minimisation decisions should therefore consider location, duration, precision, frequency and duplication as well as whether a field is collected at all.
- Limit unnecessary copying.
- Limit unnecessary transmission.
- Limit unnecessary persistence.
- Reduce unnecessary precision or frequency.
- Remove obsolete processing paths.
Product Changes Require a New Necessity Review
A product's data processing can expand gradually as new analytics, integrations and features are added. A data category that was not necessary for the original product can become necessary for a new intended function, while older collection can become unnecessary after a feature is removed. Change control should therefore include a data-minimisation review when product purpose or data flows change materially. The review should connect the new function, data category, cybersecurity risks and protection controls. This prevents a product from accumulating historical collection merely because each individual change appeared small at the time.
- Review new features.
- Review new integrations.
- Review removed features.
- Review new telemetry fields.
- Update the data inventory and risk assessment.
CRA Data Minimisation and GDPR Should Not Be Collapsed Into One Test
Organisations familiar with GDPR will recognise similar data-minimisation language, but CRA compliance should still be mapped to the CRA requirement itself. The CRA point expressly covers personal or other data and connects processing to the intended purpose of the product with digital elements within a cybersecurity framework. A privacy assessment can provide useful evidence where personal data are involved, but it may not capture non-personal operational or security data that also fall within the CRA wording. Product teams should therefore reuse relevant work where appropriate while maintaining a CRA-specific requirement map and cybersecurity rationale.
- Reuse useful privacy inventories where appropriate.
- Include non-personal product data.
- Connect necessity to the product's intended purpose.
- Maintain CRA-specific cybersecurity evidence.
Evidence for CRA Data Minimisation
A useful evidence package can include a product data inventory, data-flow diagrams, intended-purpose documentation, telemetry specifications, logging design, diagnostic-data review and records explaining why material data categories are necessary. Teams can also document rejected or removed collection because those decisions show that minimisation was considered during product design. Evidence should identify the relevant product version because data processing often changes between releases. Where a category is retained for security purposes, the record should explain what security function it supports and why a smaller dataset would not provide the necessary outcome.
- Product data inventory.
- Purpose-to-data mapping.
- Telemetry specification.
- Logging and diagnostic review.
- Necessity decisions.
- Removed or reduced collection.
- Version-specific evidence.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.