What the product collects, what it records, and what it can be made to forget

Practical guidance, not legal advice. Annex and article references are drawn from Regulation (EU) 2024/2847. Check them against the official text before you rely on them.

Three points in Annex I Part I describe one lifecycle: what the product takes in, what it writes down, and what it can be made to let go of. Assessing them together is worth doing because they pull against one another. Point (2)(l) tells you to record access to data. Point (2)(g) tells you to process only what is necessary. A log is data. Somebody has to reconcile that, and it is easier to do once than three times.

Point (2)(g): familiar words, a different question

The requirement is to 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, and the text names it data minimisation.

Anyone who has worked on data protection will recognise the phrasing. Two differences matter. First, the CRA says personal or other, so this covers telemetry, machine data, crash dumps, network captures and diagnostic bundles that contain no personal data at all. Second, the yardstick is the intended purpose of the product, which is a term you already defined in the Article 13 risk assessment, so there is a written answer to compare against rather than a general standard of reasonableness.

It is a design point, not a policy point. You satisfy it by not collecting, not by promising to delete later.

The overlap with the GDPR is real and it is not identity. A data protection impact assessment is not an answer to point (2)(g), and satisfying point (2)(g) does not discharge anything under the GDPR. The evidence overlaps heavily; the obligations do not merge.

Point (2)(l): the recording is required, the opt-out is qualified

The requirement is to provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user.

Read the structure carefully, because the two halves are not equally conditional. The recording of security-relevant internal activity is what the point requires. The opt-out attaches to the monitoring the point describes. Where a product records no user-identifiable activity, there is nothing for a user to opt out of, and the right answer in the file is to say that and explain why, not to leave the point blank or mark the whole thing not applicable.

What counts as relevant internal activity, at minimum:

• Authentication outcomes, both successful and failed, with enough identity to answer who.
• Privilege and role changes.
• Configuration changes, including which setting, from what, to what.
• Software and firmware update events, including verification failures and rollbacks.
• Access to or modification of the data the risk assessment identified as worth protecting.
• Service start, stop and crash, and security-relevant errors such as certificate validation failures.

Log design that survives being read by someone else

Three properties decide whether a log is evidence or noise. Time you can trust, which on a device with no real-time clock means recording monotonic time alongside wall clock and being explicit about which is which. Identity, because an event with no actor answers nothing. And integrity, which at minimum means the component being logged cannot silently truncate the record, and at best means append-only storage or shipping events off the device as they happen.

There is a fourth, less obvious one: a log nobody can reach is not security-related information provided to anyone. Give the customer a way to get at it, whether that is a syslog target, an export endpoint, a downloadable diagnostic bundle, or a documented file path. On a consumer device this is usually an activity view in the app rather than a log file, and that is a legitimate answer.

What the opt-out does and does not switch off

If a user opts out, say precisely what stops. Behavioural monitoring, usage analytics and activity histories that identify a person are one category. Records the product needs for its own integrity, such as a secure boot verification failure, are arguably a different one. Document the split rather than making it implicitly, because an opt-out that silently keeps recording is worse than no opt-out, and an opt-out that disables integrity checks is a control an attacker will use.

Note also that recording is not reporting. Point (2)(d) separately requires the product to report on possible unauthorised access, and a line in a file that nobody reads is not a report. Most products need both, and the same event usually feeds both.

Point (2)(m): erasure is a hardware question before it is a software one

The requirement is to provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, to ensure that this is done in a secure manner.

Every word in the first half is load-bearing. Securely, easily, permanently, all data and settings. And this is where the gap between a factory reset feature and the requirement opens up.

Flash does not overwrite

On managed NAND and on eMMC, a delete marks blocks unused. Wear levelling has already scattered copies of the data across physical pages the filesystem cannot address, and a filesystem-level format does not reach them. Overwriting a file with zeros overwrites a different physical page than the one that holds the old contents. This is not a corner case; it is how the storage works.

The accepted answer is cryptographic erasure: encrypt user data with a key held somewhere you can genuinely destroy, such as a secure element, a replay-protected memory block, or a one-time-programmable region, and destroy the key. Erasure then takes milliseconds and is complete regardless of where the ciphertext ended up.

If your device writes user data to raw flash with no encryption, factory reset is a label on a button rather than an erasure. That is a finding, and the right place for it is the risk assessment with a plan, not a checkbox marked yes.

All data and settings, for software

For installed software the question is what all means when the product is a tenant on someone else's machine. The configuration directory, the cache, the local database, temporary files, credentials placed in the operating system keychain or credential manager, and anything the uninstaller leaves behind. An uninstaller that removes the binary and leaves a configuration directory containing a long-lived API token has not met this point.

Write the list, then test it: install, use the product properly, run the removal path, and search the machine for values you know were stored. Most teams doing this the first time find at least two places.

The copies that are not on the device

If the product has a remote data processing solution in scope, the erase has to reach it, or the documentation has to say what it does not reach. A device wipe that leaves a year of recordings in the manufacturer's bucket is a partial answer, and the customer deserves to know which part.

The transfer limb

The second half of the point is conditional: where such data can be transferred to other products or systems, that transfer has to be secure. If you offer an export, a migration path, a backup file, or a handover to a replacement unit, that is the limb speaking. The recurring failure is an export bundle that is a plain archive, containing credentials, emailed to the user.

If your product offers no transfer path at all, record that against this limb rather than marking the whole point not applicable, because the erasure half still applies.

Reset and erase are two different requirements

This trips up nearly everyone, so it is worth stating plainly. Point (2)(b) asks for the possibility to reset the product to its original state. Point (2)(m) asks for the possibility to remove all data and settings permanently. In most products the same button is expected to do both, and in many products it does one.

A unit that restores default settings while keeping the paired account, the network credentials and the stored media has answered (2)(b) and not (2)(m). Test them as two things.

What an assessor will expect

• A data inventory: every field or category the product processes, why the intended purpose needs it, where it goes, and how long it stays.
• A log catalogue: the event types, the fields in each, where they are stored, how long they are kept, and how the customer gets them.
• The opt-out, what it covers, and the reasoning for anything that keeps recording after it is used.
• The erasure procedure, what it covers, and evidence it worked. For crypto-erase, the key destruction design. For anything else, a post-erase examination of the storage.
• The export or transfer format and how it is protected, or a record that no transfer path exists.
• The Annex II information that tells the user how to do all of this, since a capability the user cannot find is not a possibility provided to them.

Vandorisk splits the points with limbs in the Regulation into their own questions, so the logging opt-out and the transfer path are answered and evidenced separately rather than collapsed into one yes, and the reasoning prints into the technical file.