Deep Dive: CRA Requirement (g) – Data Minimisation

Requirement (g) of the Cyber Resilience Act introduces a duty to limit data processing to what is really necessary:

“(g) process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (data minimisation);”

In recent years, some connected products have been designed with a “collect everything” approach. While this can seem useful for analytics or future features, it often creates unnecessary risks, larger attack surfaces, and higher costs for storing, transmitting, and securing data that provides no real value. The CRA now makes minimisation a mandatory design principle. Products must be built to gather only what is truly needed to fulfil their intended purpose.

This is not just about privacy, although protecting personal data remains a central goal. In IoT and OT systems, technical and operational data can be just as sensitive. Over-collecting process data, equipment telemetry, or configuration details can create compliance headaches, add infrastructure and processing costs, and open new attack vectors. By aligning collection with purpose, manufacturers can both respect privacy and avoid the security and financial burden of managing data that should never have been collected in the first place.

What This Requirement Means

Imagine a smart energy meter installed in households or office buildings. Its purpose is to measure electricity consumption and report usage to the operator. If the device also includes a microphone that records audio from inside the rooms, it introduces unnecessary risks, privacy concerns, and added costs for storing and securing data that has nothing to do with energy measurement. Data minimisation ensures the meter only processes consumption values relevant for billing and optimisation, leaving everything else out by design.

For product owners, data minimisation starts with defining the purpose of the product and linking data collection directly to that purpose. Every collected data point should have a clear justification in terms of functionality, compliance, or safety. Collecting “just in case” data for future analytics may seem useful but under the CRA it creates both compliance risks and unnecessary costs for storage and protection.

For technical teams, minimisation must be embedded into the architecture from the beginning. Telemetry, logs, and monitoring need to be scoped tightly to functional needs. Default configurations should limit collection to the minimum required, while extended analytics should be optional and clearly documented. Retention policies should reflect the intended purpose, ensuring that non-essential data is deleted rather than stored indefinitely.

Relevant Standards and Guidelines

Although harmonised standards for CRA are still being defined, several existing frameworks provide guidance on data minimisation and purpose limitation. According to the standards mapping, the following are relevant:

• ISO/IEC 27001 and 27002 (general IT): Information security controls for managing data collection, retention, and purpose limitation.

• ISO/IEC 29100 (privacy framework): Defines principles such as data minimisation, relevance, and proportionality for personal data processing.

• ISO/IEC 27701 (privacy extension to ISO/IEC 27001): Expands data minimisation requirements into privacy information management systems.

• ETSI EN 303 645 (consumer IoT): Requires devices to only collect and retain data essential for their functions.

Despite these references, gaps remain. Most existing standards focus narrowly on personal data protection and privacy. They provide little guidance on minimisation of operational or technical data, which is often over-collected in IoT and OT environments to compensate for diagnostic uncertainty. For IoT and OT devices, data minimisation already starts at the edge where the data is generated, but none of the existing standards provide concrete guidelines for how to achieve this in industrial or embedded scenarios. Another gap lies in practical implementation: standards define high-level principles but rarely explain how to enforce minimisation consistently across distributed device fleets or resource-constrained embedded systems. CRA Requirement (g) broadens the scope and makes data minimisation a binding obligation for all types of data, not just personal information.

How to Approach Implementation

To implement data minimisation effectively, manufacturers should not view it as a restriction but as an opportunity to develop their data collection strategy. The key question is not how to reduce data but which data is truly needed and why. If there is a clear purpose, data can be collected. The goal of the CRA is to prevent unreasonable or unjustified collection practices, such as broad user profiling seen in the past from large consumer platforms, rather than to block meaningful data use in industrial or IoT contexts.

In practice, this approach often brings clarity and efficiency. In industrial IoT, many manufacturers struggle with massive data volumes that are gathered without a defined use case. This not only drives unnecessary storage and processing costs but also leads to poorly structured datasets that are difficult to analyse meaningfully. By asking what data is valuable for the product’s functionality and business needs, companies can design more focused, efficient, and effective solutions.

To effectively meet this requirement, the following steps and capabilities should be considered:

• Defining the intended purpose of the product and linking data collection/processing to that purpose

• Establishing purpose-driven rules for data collection and processing during design

• Setting default configurations that collect only the essential data, with extensions explicitly justified

• Aligning telemetry, logging, and monitoring with functional needs rather than collecting “everything”

• Applying retention and deletion policies that reflect actual use cases

• Documenting the justification for each category of data in the technical documentation

In industrial IoT and OT systems, predictive maintenance and anomaly detection solutions may still require broad telemetry, but every stream must have a clear rationale. By focusing on purpose, manufacturers can reduce unnecessary costs while ensuring data is structured in a way that supports actionable analytics. Operators should also be able to configure retention and granularity to suit their environment.

For embedded IoT devices, minimisation is both a compliance requirement and a design advantage. Limiting unnecessary data collection reduces memory, storage, and network load, improving efficiency and battery life. Rather than enforcing rigid limits, firmware should be designed with lean defaults and the ability to extend data collection where justified and documented.

The critical consideration is not simply to "collect less" but to "collect with purpose". Manufacturers should map each data stream to its function and validate that design and operation are consistent with that purpose. This ensures compliance while creating leaner, more valuable products that meet both user needs and business goals.

Compliance and Strategic Considerations

From a compliance perspective, Annex VII requires that the technical documentation clearly explains what data is collected and processed, why it is needed, and how minimisation is achieved in practice. If personal data is involved, alignment with GDPR principles is mandatory, which makes this requirement a bridge between cybersecurity and existing privacy law. Annex II also requires that the user guide includes documentation of configuration options and explains how changes to these options can impact data security. Treat the technical documentation and user guide as traceable records that show regulators that its collection and handling are justified and transparent.

When deciding between in-house implementation and vendor solutions, consider complexity and lifecycle implications. Building controls internally offers flexibility but requires robust governance and long-term maintenance. Vendor platforms may simplify implementation but must be evaluated carefully for CRA alignment, especially around configurability to fulfil your use cases.

Strategically, requirement (g) is not about restricting innovation but about making data strategies more purposeful. The shift is from "collecting as much as possible" to "collecting with a reason". This reduces compliance risks, avoids unnecessary costs, and helps ensure that data is structured in ways that actually deliver business and user value. Companies that embrace this approach early will not only simplify CRA compliance but also stand out in the market by offering products that are more efficient, more trustworthy, and easier to manage.

In our next post, we will explore Requirement (h): Resilience and Availability, which defines how connected products must remain functional under adverse conditions and ensure services are not easily disrupted.

Previous Blog CRA Requirement (f): https://www.tributech.io/blog/cra-requirement-f-protecting-integrity-of-data-and-functionsNext Blog CRA Requirement (h):https://www.tributech.io/blog/cra-requirement-h-resilience-and-availability