What Annex I Part I (2)(g) data minimization asks a product to do
Point (2)(g) of Annex I Part I requires a manufacturer to place a product with digital elements on the EU market only if it processes data, personal or other, that is adequate, relevant and limited to what the product's intended purpose needs. The property covers every category of data the product handles, including configuration values, telemetry, diagnostic files, logs, identifiers, usage events and content the user never sees. It is not limited to personal data, so a team cannot clear the requirement by checking only its privacy notice. The manufacturer defines the intended purpose in the risk assessment and in the user information described in Annex II, and that purpose sets the outer boundary of what the product may collect, store and transmit.
The risk is easy to state. Every data element a product collects is a data element that can leak, be copied from a backup, be exposed through an API or be pulled in an attack, so over-collection widens both breach impact and the attack surface the other Annex I requirements must protect. The difficulty is organizational. Engineering teams add telemetry, verbose logging and crash reporting by default because they help debugging, and those additions rarely get linked back to a stated purpose or a retention period. Product, support and analytics teams then request fields that nobody removes once the feature ships, so the data set grows quietly across releases.
Before release, a manufacturer should inventory every data flow the product creates, record the purpose and the component that needs each element, and remove or disable anything without a documented reason. The result belongs in the risk assessment and the technical documentation, with the same decision visible to a market surveillance authority. Confirm with your privacy and legal advisers how this interacts with the GDPR for personal data, because Article 52(7) of the regulation requires cooperation between market surveillance authorities and the data protection authorities.
Which data, functions and third parties fall in scope for data minimization
Point (2)(g) is tested against everything the product processes, not only personal data. The scoping work is to list each data flow, then test it against the intended purpose recorded in the risk assessment and the user information required by Annex II point 4. Each card below is one place where data quietly leaves the scope of that purpose.
Data collected directly from users
Start with the forms, fields, account details, uploads and settings the user actively enters. For each field, record which function needs it and whether the function still works without it. Optional profile fields, free-text notes and permissions requested at install time are the usual places where collection exceeds the stated purpose. Confirm that every field maps to a documented function in the technical documentation.
Telemetry and diagnostics
Usage analytics, crash reports, feature flags and performance counters are often enabled by default and collected for the vendor's benefit rather than the user's function. Check the payload of each event, not only its name. Identifiers, IP addresses, device fingerprints and free-text error messages can carry more than the diagnostic needs. Confirm which events are necessary for security and support and which can be removed or reduced.
Logs kept on the device or in vendor backends
Security logs are required for point (2)(l), but they can also hold full request bodies, usernames, session tokens and file names. Decide the log fields by purpose, set retention for each store and confirm who can read logs held in vendor backends. Logs on the device and copies shipped to a backend should be assessed separately, because each copy is a separate processing activity with its own necessity test.
Data sent to cloud services built into the product
Maps, translation, email delivery, payment processors, AI inference endpoints and update servers all receive data when the product calls them. Record each third-party endpoint, the fields sent, and whether the call is needed for an essential function. Calls that fire on every launch or send full content to a service used for a minor feature are typical findings. Ask each provider what it retains and for how long.
Data from integrated components
Open-source libraries, SDKs and embedded modules can collect data on their own, through default network calls, crash reporters or analytics hooks. The product owner remains responsible for data that its components process. Inventory each component's network behavior and default configuration, disable what the intended purpose does not need, and keep the result in the technical documentation alongside the component list.
Data processed in development and release pipelines
Build systems, issue trackers and code review tools can hold production data in test fixtures, crash dumps or sample databases. Protected branches and access rules limit who can change code, but they do not limit what data enters the repository. Scan repositories for embedded credentials and sample personal data before release, and record the pipeline's data handling in the risk assessment so that the scope matches what actually ships.
How an assessor tests data minimization and what they ask to see
This table sets out how an assessor is likely to test Annex I Part I (2)(g) on a product, what evidence they will request, and the gaps they most often find. Read each row as one test line: the approach comes first, then the evidence to have ready, then the finding that signals a weak point. Treat the table as a preparation checklist, since the assessor's own procedure and the conformity route determine the final scope.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Intended purpose to data inventory | User information stating intended purpose, mapped inventory of each data category the product processes | Inventory covers personal data only, or lists fields no stated purpose requires |
| Sampling fields in code and configuration | Data model, API schemas, configuration files and the code paths that collect each field | Fields collected at startup or in logs that no feature uses |
| Default telemetry and logging settings | Shipped default configuration, telemetry settings and documented opt-in or opt-out behavior | Telemetry enabled by default with no documented necessity or user control |
| Recorded necessity decisions | Risk assessment entries explaining why each data category is needed and how it was limited | Justifications are generic, undated or not linked to a feature |
| Retention and deletion of collected data | Retention settings, deletion routines and test records showing removal after the stated period | Data kept beyond the period needed for the intended purpose |
| Cooperation with data protection authorities | Records of contact points with the relevant data protection authority under Article 52(7) and any joint handling procedure | No named contact or no process for referring data protection questions |
Implementing data minimization step by step, with the output of each step
This sequence turns the point (2)(g) principle into a documented design decision for each feature. Each step produces an artifact that a market surveillance authority or notified body can read, from the stated purpose through to the retention rules and the retest after every release.
Confirm the intended purpose and essential functions
Product management and the security lead write down what the product is for, who uses it, and which functions are essential to that purpose. The user information required under Annex II point 4 already asks for the intended purpose and essential functionalities, so the same wording should feed this step. Output: a one-page purpose statement with a numbered list of essential functions. The step is complete when every later data decision can be traced back to one of those functions.
Build a data inventory for each feature
Engineering lists every feature and records each data element it collects, creates, derives, receives from a third party or sends out. The inventory covers all data the product processes, not only personal data, including telemetry, logs, crash reports and configuration. Output: a feature-by-data matrix with the source, storage location and recipient of each element. The step is done when a reviewer can pick any data element and find the feature that uses it.
Run a necessity test on each data element
For every element in the inventory, the product owner and the security lead answer whether the element is adequate, relevant and limited to what the essential functions require. Elements that serve only a convenience, analytics or a future feature are marked for removal or justification. Output: a signed necessity register with a keep, remove or redesign decision and a reason for each element. Ask the vendor or open-source project for any default data flows you do not control before you sign off.
Remove or default off unneeded collection
Engineering removes the elements marked for removal and switches any optional collection to off by default, with an explicit user choice to enable it. Where a feature needs a data element only for part of its operation, the design limits the collection to that scope. Output: merged code changes, configuration defaults and a list of settings that changed from the upstream defaults. The step is complete when a test build collects only the elements left in the necessity register.
Set retention and deletion rules
The team defines how long each kept data element is stored, where it is held, and how it is deleted or anonymized when that period ends. Retention settings should be configurable so the operator can align them with its own obligations, and the product should support the secure removal of user data under point (2)(m). Output: a retention schedule with a deletion method for each data category, plus the test cases that verify deletion. Confirm with the operator's data protection function where personal data is involved.
Record decisions in the risk assessment and technical documentation
The security lead carries the purpose statement, the necessity register and the retention schedule into the Article 13(2) cybersecurity risk assessment and the technical documentation. Each recorded choice states the requirement, the decision taken and the reason. Output: updated risk assessment entries and a data minimization section in the technical documentation that an assessor can check line by line. The step is complete when the documents and the code describe the same product.
Retest data collection on each release
Before every release, the team reruns the data inventory against the build, compares it with the necessity register, and checks that new features have been added to the register. Automated checks, such as a CI job that flags new network calls or new fields in logs, can support this review. Output: a release checklist entry and a short delta report listing any new or changed data elements with their approval. The step continues through the support period, since new features and dependency updates can add collection without anyone deciding to.
Evidence that shows data minimization is working, and how to keep it current
Data minimization under Annex I Part I (2)(g) is shown by a set of linked records, not by a single policy statement. The cards below cover the artifacts an assessor or market surveillance authority is likely to ask for, and how each one connects to the risk assessment and technical documentation.
Data inventory of processed data
A data inventory lists every category of data the product collects, stores, transmits or derives, personal or not, along with the component that handles it, the purpose it serves and the interface through which it enters or leaves the product. It is the starting point for every other artifact on this page. Check that the inventory covers telemetry, logs, crash reports and data sent to cloud backends, since these are the categories most often missed. Keep it under version control next to the code so changes are visible.
Necessity test records
For each data category, the manufacturer should record a necessity test: why the intended purpose needs this data, what happens if it is absent, and whether a less revealing alternative such as aggregation, pseudonymization or on-device processing would serve the same purpose. Signed, dated records make the decision traceable. Annex II point 4 ties the intended purpose to the user information, so the purpose written in the test should match the purpose published to users.
Configuration baseline with minimal defaults
The configuration baseline documents which data collection features are enabled by default and which require an explicit user action. Telemetry, analytics, diagnostic uploads and verbose logging should default to off unless the necessity test justifies otherwise. Export the baseline from the deployed configuration files, not from memory, and compare it with each release. Confirm how the product behaves on a fresh install and after an upgrade, because upgrades often re-enable settings.
Code scan results for collection changes
Static analysis results show where the code actually collects, forwards or persists data, which the inventory and baseline cannot prove on their own. Semgrep Community Edition (LGPL-2.1-only) can run custom rules for patterns such as new network calls, new logging statements or new fields written to storage, and can run in CI/CD on repositories in supported languages. Confirm that your stack's languages and frameworks are covered by its supported-language list and that rules are tuned to your codebase.
Access control over collection code
Data collection logic changes only when reviewed changes reach the protected branch. GitLab Community Edition protected branches let you restrict which roles can push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled. Together with required review, this creates a record of who approved each change to what is collected. Confirm that these controls apply to every repository that contains collection code, including SDKs and build scripts.
Retention, deletion and risk assessment links
Retention and deletion specifications state how long each data category is kept, where it is deleted and how deletion is verified. These specifications, together with the necessity test records, should be cross-referenced from the Article 13(2) cybersecurity risk assessment and the technical documentation, so an assessor can follow a data category from its purpose to its retention limit. Review the links at each release, because a change to a collection feature that is not reflected in the risk assessment is a common finding.
What meeting data minimization costs in money and effort
This table compares the main cost components of meeting point (2)(g), who usually carries each one, and whether it is one-time or recurring. Read the drivers column to see what pushes each cost up, and the quote column for what to request in writing. No figures are given because effort depends on the written scope of each engagement.
| Cost component | One-time or recurring | What drives it up or down | What to ask for in a quote |
|---|---|---|---|
| Internal engineering time for the data inventory and code changes | One-time, then recurring with each new feature | Number of data flows, age of the codebase, and how many services hold copies of the same fields | Named inventory deliverable, list of code areas in scope, and whether the partner or your team owns each change |
| Privacy and legal review of necessity decisions | Recurring with each new data field or purpose | Whether the product processes personal data, the number of intended purposes, and how often the purpose statement changes | Who signs off on necessity decisions, whether counsel is included, and how review is triggered for new fields |
| Tooling and licenses | Recurring where commercial tools are used | Choice between commercial scanners or data discovery products and self-hosted open-source options, plus the number of repositories and users | Itemized license terms, hosting costs in your own environment, and which tools the quote assumes you already own |
| Evidence upkeep on each release | Recurring with every release and support period update | Release frequency, how much evidence is generated automatically in CI/CD, and how many product variants ship | Which evidence is produced by pipeline jobs, where it is stored, and who reviews it before release |
| External review or testing of data handling | Recurring, often at a fixed scope per review | Architecture complexity, number of external interfaces, and whether data leaves the product or the customer environment | Written test scope covering data collection and retention, retest terms, and the report format delivered |
| Auditor or assessor sampling time | Recurring at each assessment cycle | Number of samples the assessor selects, quality of traceability from purpose to data field, and how many versions are in scope | That the assessor, not the implementation partner, decides sample size, and what records the assessor will request |
| Rework after an unplanned data finding | One-time per finding, often unbudgeted | Late discovery of unnecessary fields, telemetry added without review, or logs that retain identifiers | Change control process, a defined retest step, and how findings are logged in the technical documentation |
Who does what: your team, an implementation partner and the auditor
Your organization owns the outcome. The obligation in Annex I attaches to the product you place on the market, so the intended purpose, the necessity decisions and the final sign-off stay with the manufacturer. No implementation partner or auditor can decide that a data field is necessary for your product. Those decisions belong in your risk assessment and technical documentation, under the name of an accountable person.
- Intended purpose. Define what the product is for, the functions it must perform and the user groups it serves. The user information must state this purpose, so the statement has to match what the product actually does.
- Necessity decisions. For each data category, record why it is adequate, relevant and limited to what the intended purpose needs, and what the product loses if that data is removed.
- Data protection input. Involve privacy staff early. Personal data decisions also engage GDPR duties, and Article 52(7) requires cooperation between market surveillance authorities and data protection supervisors.
- Sign-off and ownership. Name an owner for each decision and keep dated approvals, so later changes can be traced to the person who accepted them.
- Change control. Reopen the decisions when features, integrations or telemetry change, including changes made by product teams that never touch the risk assessment directly.
Check that every necessity decision has a named owner, a date and a reason you could defend to a market surveillance authority without any partner in the room.
An implementation partner such as DeployOpen prepares the systems and evidence that show your decisions are applied in the product. DeployOpen works on self-hosted open-source platforms inside your own infrastructure, under a written scope agreed before work starts. The partner does not decide the intended purpose or accept residual risk, and it does not issue any report or certificate.
- Data inventory. Map the data the product collects, stores, transmits and derives, including logs, telemetry and data sent to third-party cloud services, so the necessity decisions rest on an accurate picture.
- Configuration baselines. Set defaults that collect only the fields the purpose needs, and document how optional collection is switched off. Confirm for each platform which settings exist, because capabilities vary by product and version.
- Pipeline checks. Configure repository controls such as GitLab protected branches, which restrict who can push or merge. Add code scanning in CI/CD, for example with Semgrep in its supported languages, so changes that add data collection are reviewed before release. Confirm that the rules you need exist for your language.
- Evidence packs. Assemble the inventory, baselines, configuration exports, review records and change history into a pack indexed to the requirement, ready for the assessor.
- Written scope. Agree deliverables, exclusions and handover dates in writing, and state who keeps the evidence current after delivery.
Ask any partner to show which decisions it prepared, which it only recorded and which it did not touch, and to name the independent party that will test the result.
The independent auditor or assessor tests the evidence and reaches a conclusion. Independence is the point of this role. The party that designed or configured the controls should not be the party that tests them. Most CRA products follow self-assessment under module A, while a notified body is needed for some class I important products and for class II and critical products. Only these independent bodies issue reports or certificates, and notified bodies are listed in the Commission's NANDO system.
- Testing the evidence. Sample data inventories, configuration exports and review records, compare them with the running product, and interview engineers about what the product actually collects.
- Testing the decisions. Check that the intended purpose in the user information matches the risk assessment, and that each necessity reason is specific to the product and its features.
- Conformity route. Confirm which route applies to your product class before you engage anyone. Self-assessment covers most products, and a notified body is needed in the cases set out in Article 32.
- Reports and certificates. Only the auditor or certification body issues a report, attestation or certificate. The EU declaration of conformity and CE marking remain the manufacturer's responsibility, so confirm what the assessor will and will not sign.
- Independence in writing. Ask the assessor to confirm in writing that it did not design the controls it tests and does not have a conflict in the engagement.
Check whether your conformity route requires a notified body listed in NANDO before you contract any assessor.
Where data minimization usually fails and how to close each gap
Data minimization under Annex I Part I (2)(g) usually breaks at a few predictable points: how the intended purpose is written, what the product collects by default, and what happens to data after collection. Each card below names one gap, why it matters for the assessment, and the single change that closes it.
Intended purpose written too broadly
An intended purpose such as "improve the user experience and business insights" justifies almost any collection, so it limits nothing. Because necessity is judged against the intended purpose, a vague statement makes every data point look necessary. Fix: write the intended purpose as specific functions, then list only the data each function needs. Check that the same wording appears in the user information required by Annex II point 4.
Telemetry enabled by default
Diagnostic, usage and crash reporting that is switched on at install collects data before the user has made any choice about it. An assessor will ask whether each telemetry stream is needed for the product to function or for a purpose the user has accepted. Fix: ship with non-essential telemetry off and document every stream that remains on by default with its purpose. Test a fresh installation and record the outbound data it sends.
Logs retaining full identifiers
Application and audit logs often store full IP addresses, email addresses, device identifiers or session tokens, even when a pseudonymous reference would support troubleshooting and security monitoring. Full identifiers in logs widen the data set well beyond what the stated purpose needs. Fix: log the minimum identifier that supports investigation, such as a salted hash or truncated address, and keep the mapping under separate access control. Review log schemas during each release.
Third-party SDKs collecting unneeded data
Analytics, crash-reporting and advertising libraries bundled into a product can collect device data, location or usage events on their own behalf. The manufacturer remains responsible for what the product processes, including data gathered by components it ships. Fix: inventory every bundled SDK, disable data collection the product does not need, and record each remaining data flow in the technical documentation. Confirm the vendor's default settings against the version you ship.
No retention rule
Data kept indefinitely after its purpose ends stays exposed to breach and misuse, and it is hard to justify as limited to what is necessary. Many products have no documented retention period for logs, caches, backups or user-generated content. Fix: set a retention period for each data category, enforce it with automated deletion, and test that deletion runs. Ask the vendor or your own engineering team to show how the configuration is applied.
Necessity decisions missing from technical documentation
Teams often make sound minimization choices in code reviews or tickets, but the technical documentation never records which data was collected, why, and what was rejected. Without that record, an assessor cannot confirm the decision was made or maintained. Fix: record each data element, its purpose, its retention period and the alternatives considered in the risk assessment and technical documentation, and update the record with every release. Link each entry to the product version it describes.
Keeping the minimization record current through the support period
A data minimization decision under Annex I Part I point (2)(g) is only as good as the last time someone checked it against the product as it actually ships. Each new feature, telemetry field, third-party integration, analytics SDK or change to the intended purpose can add data the product processes, and that data has to be justified again against the purpose stated in the user information. Treat the minimization section of the risk assessment as a living record that is reopened whenever the product's data flows change, not as a document written once before launch.
The practical way to keep it accurate is to tie the release process to the data inventory. Add a required checkbox to the release checklist that asks whether the release adds, removes or changes any category of data collected, stored, transmitted or sent to a third party, and whether the intended purpose or essential functionality described to users has changed. Where the answer is yes, the release cannot proceed until the data inventory entry, its stated purpose and its retention period are updated and the reviewer has recorded why each element remains necessary. Substantial modifications under the regulation also call for a new assessment, so the checklist should flag those releases for the conformity route the product uses. Ask your engineering leads to confirm which repositories, configuration files and pipeline stages will carry this check before the first in-scope release.
Keep the linkage auditable. Store each inventory change with the release identifier, the ticket that introduced it and the approver, so an assessor can trace a data element from its first appearance to its current justification. Retest the minimization behavior as part of regression testing, for example by checking that new logging fields and API responses carry only the data the documented purpose needs. Confirm with your conformity assessment body or market surveillance contacts how they expect this evidence to be presented, because the regulation does not prescribe a format for it.
Questions buyers ask about data minimization under the CRA
How much effort does data minimization take for a small product?
For a small product with a narrow purpose and little data, the work is usually modest, but it is not zero. The effort comes from three things: how many data flows the product has, how many of them carry data the product does not strictly need, and how well the team already documents why each field is collected. A single-function device that sends one telemetry record per day has a short list to review. A small app that collects accounts, analytics, crash reports and location data has a longer one. Ask any partner to size the work from a written list of data flows, and treat any figure given before that list exists as a guess.
Is a data inventory alone enough to meet point (2)(g)?
No. A data inventory tells you what the product processes, but point (2)(g) asks whether each item is limited to what the intended purpose needs. You also need a recorded decision for each category: why it is necessary, how long it is kept, and what happens if it is switched off. The inventory is the starting input. The necessity reasoning and the link to the cybersecurity risk assessment and technical documentation are what an assessor will read. Confirm with your assessor how much rationale they expect for each data category.
What must our team provide to an implementation partner before work starts?
Before any technical work, the partner needs the product's intended purpose, its essential functions and its security properties, since these frame what processing is necessary. Provide the current data flow diagrams, the list of data fields and telemetry events, the retention settings, third-party services that receive data, and the existing risk assessment if one exists. Also provide the names of the people who own product decisions, so necessity calls can be signed off. Ask the partner to confirm this list in the written scope before fixing the deliverables.
Can an implementation partner make the necessity decisions for us?
A partner can analyze the data, propose which fields are adequate and relevant, configure the product to match, and document the reasoning. The decision itself remains with the manufacturer, because the manufacturer owns the intended purpose and carries the regulatory duty. A partner has no authority to issue a conformity statement either. Independent assessors and notified bodies, where they apply, review the outcome. Agree in writing which decisions the partner drafts and which your product owner approves.
How does CRA data minimization differ from GDPR data minimization work?
The GDPR principle limits personal data to what is necessary for the processing purpose, and it is assessed mainly from the data subject's rights. Point (2)(g) of the CRA is broader in one respect and narrower in another. It covers all data the product processes, personal or other, such as device logs, configuration and telemetry. It is judged against the product's intended purpose and security function, not the controller's lawful basis. Article 52(7) also requires cooperation between market surveillance authorities and data protection supervisors. Teams that already run GDPR minimization reviews can reuse much of the inventory, but they should extend it to non-personal data and link it to the risk assessment.
Can open-source tools produce the evidence for data minimization?
Open-source tools can produce supporting evidence, but they do not decide necessity. Version control with protected branches, such as GitLab Community Edition, can record who approved changes to data collection code, and blocking direct pushes keeps those approvals traceable. Semgrep Community Edition can scan code in many languages, including Go, Java, Python, JavaScript and TypeScript, for patterns that log or transmit fields, and it can run in CI/CD pipelines so new collection points are flagged. Confirm with each tool's maintainers which rules cover your language and whether custom rules fit your data categories.
How long does the data minimization work take?
Duration depends mainly on how many data flows exist, how many decisions need stakeholder sign-off, and how much code must change to remove or reduce fields. The work usually runs in three stages: mapping, decision and change, and documentation. Mapping is quick when the architecture is well documented and slow when it is not. Changes to firmware or released software take longer because they go through release and support planning. No duration in this answer is a commitment. Ask any partner for a fixed-scope timeline built from your written data flow inventory before you rely on one.
How DeployOpen scopes and prepares data minimization evidence
DeployOpen works on Annex I Part I (2)(g) data minimization by helping the manufacturer define what the product actually needs to process, then configuring and documenting the self-hosted open-source platform to match. The manufacturer keeps ownership of its risk assessment and technical documentation, and an independent assessor or notified body issues any conformity outcome.
How we scope
- Agree in writing which product, versions and data flows fall inside the (2)(g) review
- Record the intended purpose and essential functionalities the team must confirm before scoping
- List every data category the product collects, stores, logs or transmits, personal or other
- Confirm with the client which decisions in the risk assessment the engagement will support
How we build
- Map each data field to a stated purpose and remove or disable fields that serve none
- Configure logging, telemetry and analytics defaults to the smallest set the purpose requires
- Set retention limits per data category in the platform and document the chosen values
- Add repository and pipeline checks, such as Semgrep rules in CI, that flag new data collection
How we hand over
- Deliver a data inventory mapped to purposes, with the rationale for each retained category
- Provide configuration records and test results showing the minimized defaults in effect
- Supply documentation text for the risk assessment and technical documentation, for the manufacturer to review
- Walk the client's engineering and compliance leads through the evidence before handover
How we support
- Offer ongoing support and upgrades as a retainer when the product or its data flows change
- Re-check data inventories after each release so the evidence stays aligned with the product
- Ask the client to confirm with its assessor which evidence format and depth their review expects
- Coordinate with the client's data protection function on processing that also falls under GDPR
