The Cyber Resilience Act (CRA) makes data minimisation an explicit product-security requirement. Annex I Part I point 2(g) requires, on the basis of the manufacturer's cybersecurity risk assessment and where applicable, products with digital elements to process only personal or other data that are adequate, relevant and limited to what is necessary in relation to the product's intended purpose.
That is broader than a rule about privacy settings. Product teams need to know what data the product processes, which product function requires each data item, and whether the same function can be delivered with less data, lower precision, narrower scope, or processing that remains local rather than being transferred elsewhere.
The practical objective is not "collect nothing." It is to make every material data flow defensible against a specific product purpose.
What Annex I actually requires
Annex I Part I contains essential cybersecurity requirements for the properties of products with digital elements. Point 2(g) states that, where applicable and based on the cybersecurity risk assessment, a product must process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to its intended purpose.
Three details matter.
First, the requirement covers personal or other data. A manufacturer should therefore not restrict the review to data classified as personal data. Device identifiers, machine telemetry, network metadata, configuration values, system state, industrial process values, crash information and security events may all need to be considered even where they are not personal data.
Second, necessity is tied to the intended purpose of the product. Data may be convenient for analytics or future product ideas without being necessary for a function that forms part of that intended purpose. Product and engineering teams need to distinguish a current functional requirement from optional collection that is merely useful.
Third, the requirement sits inside the CRA's risk-based product-security framework. Article 13 requires manufacturers to assess the cybersecurity risks associated with the product and to take the outcome into account across planning, design, development, production, delivery and maintenance. Data minimisation should therefore be treated as a design and risk decision, not only as a documentation check at release time.
Data minimisation under the CRA is not the same as GDPR compliance
The wording resembles the General Data Protection Regulation (GDPR), which requires personal data to be adequate, relevant and limited to what is necessary for the purposes for which they are processed.
But the legal scopes are not identical.
The GDPR principle concerns personal data and the purposes of personal-data processing. The CRA requirement expressly covers personal or other data and connects necessity to the intended purpose of the product with digital elements.
For a data flow involving personal data, both regimes may be relevant, but satisfying one should not be assumed to prove compliance with the other. A product-security review should therefore ask the CRA question directly: is this data necessary for the intended product function, considering the product's cybersecurity risk assessment?
Start with a product data-flow inventory
A team cannot minimise data it has not identified. The useful starting point is a product-level inventory of material data flows.
For each flow, record at least:
- the data or field being processed;
- the product, variant and release in which the flow exists;
- the source of the data;
- the component or service that processes it;
- whether it stays on the device or crosses a process, device, network or cloud boundary;
- the intended product function that depends on it;
- the security reason for processing it, where relevant;
- the destination or recipient;
- the precision, frequency and volume needed by the function;
- the retention or buffering behaviour, where applicable; and
- the technical control that prevents additional unnecessary data from entering the flow.
Turn "necessary" into an engineering decision
"Necessary" is not a field that can be filled with yes or no without reasoning. Teams need a repeatable decision method.
For each data flow, ask:
- Which intended product function requires the data? Name the concrete function rather than a broad objective such as "improve the product."
- What is the minimum data needed for that function? Consider whether fewer fields, lower precision, aggregation, pseudonymous values or event counters would be sufficient.
- Does the data need to leave the product or local environment? A function may need the data locally without requiring remote transmission.
- Does the function need raw data or only a derived result? Sending a health state, error class or threshold result may be sufficient where the raw input is unnecessary.
- How often must the product process the data? Continuous collection should have a stronger functional justification than an event-triggered or sampled flow where the latter is sufficient.
- How long must the product keep the data to perform the function? The CRA does not prescribe a universal retention period in point 2(g), so the manufacturer should document the functional and security rationale for the chosen behaviour.
- What changes if the relevant feature is disabled? Optional functions should not automatically justify permanent processing when they are not in use.
This produces a reviewable necessity rationale rather than a generic assertion that "telemetry is required."
Apply minimisation to telemetry and diagnostics
Telemetry is a common source of accidental over-collection because it grows incrementally. A new field is often easy to add and difficult to remove once dashboards, support workflows and analytics depend on it.
For each telemetry field, define its operational purpose. If a counter, state code or coarse category answers the engineering question, transmitting the full raw event may be unnecessary. If a device identifier is needed for update status, confirm whether a stable globally unique identifier is required or whether a narrower identifier would work.
Diagnostics deserve the same treatment. Crash reports, debug bundles and support exports can contain configuration values, file paths, memory fragments, account information, network data or other context beyond the issue being investigated. Product teams should define the diagnostic fields deliberately and avoid treating broad debug capture as the production default.
Useful controls include:
- explicit field allowlists rather than collecting entire objects by default;
- redaction before data leaves the device or process;
- event-triggered diagnostics instead of continuous capture where appropriate;
- bounded diagnostic windows;
- lower-resolution or aggregated values where the function permits; and
- separate diagnostic modes for information that is not needed during normal operation.
These are engineering patterns, not CRA-prescribed implementation methods. The manufacturer remains responsible for selecting controls appropriate to the product and its risk assessment.
Security logging still needs enough information to work
Data minimisation does not mean removing the evidence needed to detect or investigate security events.
Annex I Part I point 2(l) separately requires, where applicable and based on the risk assessment, security-related information through recording and monitoring relevant internal activity, including access to or modification of data, services or functions, with an opt-out mechanism for the user.
The two requirements need to be designed together. A useful security log should contain enough context to support the security purpose without becoming an unrestricted copy of application data.
For example, an authentication event may need time, outcome, account or role context and source information, but not the full content of a user record. A configuration-change event may need the identity of the setting, the actor and the result, but not a complete dump of unrelated configuration.
The evidence should show why the selected log fields are necessary for the defined security use case and why additional data was excluded.
Review identifiers, precision and linkability
Minimisation is not only about the number of fields. The form of the data can change its security significance.
A stable identifier can allow events to be linked over a long period. A precise location value can expose more than a region-level value. A full timestamp can reveal more activity detail than a daily or hourly bucket. A raw hardware serial number may provide more identifying information than a scoped application identifier.
When the product does not require the extra precision or linkability, reducing it can reduce the amount of information exposed if telemetry, logs or backend data are compromised.
A practical review should therefore test:
- whether identifiers need to be globally stable;
- whether precision can be reduced;
- whether values can be aggregated;
- whether the same identifier is reused across unrelated services;
- whether free-text fields can contain uncontrolled sensitive content; and
- whether raw payloads are retained where derived values would be sufficient.
Include remote processing in the product review
The CRA definition of a product with digital elements includes remote data processing solutions where the relevant software is designed and developed by the manufacturer, or under its responsibility, and the product would lose one of its functions without that remote processing.
That means a data-minimisation review should not stop at the device or local application boundary. If product functionality depends on a manufacturer-controlled backend, API or remote processing component that falls within the CRA product scope, the data sent to and processed by that remote part should be included in the same functional analysis.
For each remote flow, ask separately whether the transfer itself is necessary and whether the remote component needs every field that is transmitted.
Design optional features so their data flows are optional too
Products often contain features that are not used by every customer or in every deployment. A data flow that is necessary for an optional feature does not automatically need to run when that feature is disabled.
Where architecture permits, couple collection and transmission to the feature state. This creates a clearer relationship between intended function and processing behaviour.
Examples include:
- sending cloud diagnostics only when remote diagnostics are enabled;
- collecting high-frequency sensor data only while an analysis feature is active;
- transmitting location data only for a function that actually uses location; and
- enabling additional support traces for a bounded troubleshooting session rather than continuously.
Put data minimisation into architecture and change review
A one-time review before market placement is not enough if later product changes add new telemetry, interfaces, integrations or remote functions.
Build a minimisation checkpoint into normal engineering change control. Any change that introduces a new data flow, expands the fields in an existing flow, increases precision or frequency, creates a new remote destination, or changes the intended use of existing data should trigger a review.
The reviewer should be able to answer:
- what changed;
- which intended function requires the change;
- whether less data could achieve the same result;
- how the change affects the cybersecurity risk assessment;
- what controls prevent unintended additional processing; and
- which tests or evidence confirm the implemented behaviour.
This turns data minimisation into a maintained product property rather than a release-documentation exercise.
Test the implementation, not only the design document
A written data-flow diagram does not prove that a shipped product behaves as described. Verification should compare the implemented product with the approved data-flow decisions.
Depending on the architecture, useful tests can include:
- inspecting network traffic for unexpected fields or destinations;
- checking telemetry schemas against approved allowlists;
- verifying that disabled features stop the associated collection or transmission;
- testing redaction and filtering;
- checking debug and crash-report payloads;
- confirming that production builds do not expose development-only diagnostics;
- reviewing log records for unnecessary payload content; and
- verifying that backend ingestion rejects fields that are outside the expected schema.
The test evidence should identify the product and release so that later changes do not silently inherit an outdated conclusion.
What evidence should manufacturers retain?
Article 31 requires technical documentation to contain relevant data or details of the means used to ensure that the product and manufacturer processes comply with Annex I. Annex VII further defines the technical-documentation content expected for conformity assessment.
For data minimisation, useful supporting evidence can include:
- the product data-flow inventory;
- mappings between data flows and intended product functions;
- necessity decisions and their rationale;
- relevant cybersecurity risk-assessment entries;
- architecture diagrams showing local and remote processing boundaries;
- telemetry, logging and diagnostic schemas;
- redaction or filtering rules;
- feature-state and consent-independent technical controls where relevant;
- verification results showing the actual data transmitted or stored; and
- change records showing how the review was repeated when the product evolved.
The CRA does not mandate a particular template for this evidence. The goal is to make the manufacturer's design decision and implementation traceable.
Prepare before the main CRA obligations apply
The CRA's main obligations apply from 11 December 2027. Teams preparing now can use the implementation period to identify data flows that have accumulated without a clear product-purpose rationale and bring the review into normal architecture and release processes.
A useful readiness exercise is to select one current product and trace every external telemetry, diagnostic and logging flow back to an intended product function. For each field, ask whether the team can explain why it is necessary, which risk decision supports it, and which test confirms the product behaves accordingly.
If the explanation depends on tribal knowledge or old tickets, the evidence is likely to become harder to reconstruct as the product and support period progress.
Keeping those decisions connected to the correct product and release is also relevant to lifecycle evidence management. AA-sec is designed around traceability between requirements, evidence, decisions and exact product or lifecycle context, which can help teams keep data-minimisation rationale and verification evidence attached to the release they support. AA-sec does not make the manufacturer's legal compliance decision.
Practical data-minimisation checklist
Before treating the requirement as covered, verify that the team can answer:
- Have we identified the product's material local and remote data flows?
- Does every flow map to a concrete intended product function?
- Have we assessed personal and non-personal data rather than only privacy-regulated fields?
- Can any field, precision, frequency or retention behaviour be reduced without preventing the intended function?
- Do optional features stop their associated processing when the function is not active, where technically appropriate?
- Are telemetry, diagnostics and security logs designed from explicit schemas rather than unrestricted capture?
- Are remote processing components within the product scope included in the review?
- Does the cybersecurity risk assessment reflect the relevant data-processing risks?
- Have we verified the implemented product against the approved data flows?
- Can the evidence be tied to the exact product, variant and release?
- Does the engineering change process trigger a new review when data flows change?
Key takeaway
CRA data minimisation is an engineering requirement to make product data processing proportionate to the product's intended purpose. It covers personal and other data and should be evaluated together with the cybersecurity risk assessment, product architecture, telemetry, diagnostics, logging and remote processing.
The strongest implementation is a traceable one: identify each material data flow, connect it to a concrete function, document why the chosen scope is necessary, minimise fields and precision where possible, and verify that the shipped product behaves as designed.
Official sources
- Regulation (EU) 2024/2847 - Cyber Resilience Act
- European Commission - CRA implementation guidance
- Regulation (EU) 2016/679 - General Data Protection Regulation