Annex I Part I (2)(m) secure data removal: CRA evidence

What Annex I (2)(m) secure data removal asks a manufacturer to prove

Product teams need to show that a connected product lets a user erase all of their data and settings permanently and easily, and that any move of that data to another product or system happens securely. The requirement has two limbs. The first is permanent removal of all data and settings through a route the user can actually find and complete. The second applies where data can leave the product: any export, migration or transfer to another device or system must be protected so that the act of moving data does not expose it. Both limbs are judged against the product as a whole, including its companion apps, web portals and any cloud service the device depends on, not only the firmware on the device itself.

The practical risk is residual data. A device that is resold, returned, recycled or handed to a new owner may still hold credentials, personal data, usage histories, certificates or configuration that a simple factory reset does not clear. The harder cases are the ones product teams often do not map: account data in a cloud backend, copies in application logs and telemetry pipelines, backups taken for support or resilience, and data replicated to analytics or third-party services. A user who believes their data is gone while copies persist in those places has not been given a permanent removal option. Engineering teams should trace where each category of user data is stored, how long each copy lives, and whether deletion reaches it.

Before release, confirm three things with your engineering and product owners. First, the reset or erase function must be listed in the user instructions, which Annex II also expects to cover secure decommissioning. Second, the data flow inventory must show every location where user data or settings can persist, with a documented deletion path for each. Third, any export or transfer feature must have its protection mechanism recorded alongside the risk assessment. Evidence usually includes test records of the erase function on a device in a known state, a deletion procedure for backend and backup copies, and the transfer design. Where you need outside help, ask whether the work covers testing the erase result on the physical device and the cloud side, not only a review of the design document.

Which data stores, features and third parties fall inside secure data removal scope

Secure data removal under Annex I Part I (2)(m) is only as complete as the list of places user data lives. Scope follows the product's data flows as recorded in the cybersecurity risk assessment, so every store, copy and recipient that the flows reveal needs a removal decision.

Local storage on the device

Start with everything the product writes to its own storage: databases, caches, configuration files, temporary files and media. Permanent removal has to reach each of these, including data written by background processes that the user never sees. Check whether the product uses encrypted storage with a key that can be destroyed, which can make removal faster and easier to verify, and confirm that a factory reset clears the key material as well as the data.

Cloud copies and sync replicas

If the product syncs user data to a vendor or customer-hosted cloud, every replica falls inside scope, including mirrors, search indexes and regional copies. Removal from the device alone leaves these behind. The question to answer in the risk assessment is which copies exist, who controls each one, and how the user triggers removal from all of them.

Backups and archives

Backups are the copy most often forgotten. Document how long each backup set is retained, whether users can request deletion from backups, and what happens to data in backups taken before the removal request. Where backups cannot be edited, record the retention period and the compensating control, such as encryption with a key that is destroyed on removal.

Logs and telemetry

Security logs required under Annex I Part I (2)(l) and diagnostic telemetry often contain user identifiers, file names or query content. Decide which fields are kept after removal, which are pseudonymized, and which are purged. Confirm that the logging design does not quietly keep a second copy of user content outside the removal path.

Paired devices and export files

Data leaves the product through paired devices, exported files, and migration bundles. A user who removes data from the product still needs to know which exports exist and whether they are protected. Document which export formats carry user data, how each is encrypted or protected, and whether the product can revoke pairings so that paired devices stop receiving data.

Third-party services holding user data

Analytics providers, payment processors, email senders and hosting partners may receive or store user data. Each one is a recipient in the data flow and needs a documented removal path, either through the vendor's deletion process or a contractual commitment. Ask each supplier how and when it deletes data on request, and record the answer in the risk assessment.

How an assessor tests secure data removal

This table sets out what an assessor typically checks for the removal function, the transfer function and the user instructions under Annex I Part I point (2)(m), along with the evidence requested and where products usually fall short. Read each row as a test area: the left column names the area, the middle column describes the test, and the right column shows what a finding looks like. The main takeaway is that removal is judged on whether data is actually gone and whether transfers stay protected, not on whether a menu option exists.

Test area	What the assessor checks	Evidence requested and common findings
Removal function	The user can start a full erase of all data and settings from the product itself, without vendor help or special tools.	Test script and screen recordings of the erase path. Finding: erase is buried in an advanced menu or requires a support ticket.
Permanence of erasure	Deleted data cannot be recovered through normal or forensic-style access to the storage the product uses.	Forensic read-back results or a documented overwrite or cryptographic erase method. Finding: files marked deleted but still recoverable from flash or disk.
Settings and credentials	Configuration, account tokens, certificates and stored keys are removed or reset along with user content.	Inventory of settings stores and a reset test showing each one cleared. Finding: API keys or Wi-Fi credentials survive a factory reset.
Retained cloud and backend copies	Where the product syncs to a vendor or customer backend, the erase request reaches those copies and states how long they persist.	Data flow diagram, deletion propagation logic and retention settings. Finding: cloud copies, backups or logs keep user data with no documented removal path.
Transfer function	Any export or move of data to another product or system uses protected channels and authenticated recipients.	Transfer test cases showing encryption in transit and authentication of the target. Finding: data moves over an unencrypted channel or an unauthenticated pairing.
Export files	Exported or staged files are encrypted, access-controlled or deleted after use, so they do not become a residual copy.	Sample export file inspection and cleanup test. Finding: plaintext export files left in shared folders or temporary directories.
User instructions	The instructions for secure decommissioning cover how to remove user data and what remains after removal.	Published user manual section and version history. Finding: instructions omit the reset path or describe steps the current firmware does not perform.
Scope of notified body involvement	The assessor confirms whether the product class requires a notified body or whether self-assessment applies for this requirement.	Confirm the product classification and conformity route with the competent authority or notified body before testing. Finding: testing scope set without checking the applicable route.

How to build and verify a removal function step by step

This sequence takes the data and settings the product holds, from the risk assessment through to the user instructions, and produces a removal function with evidence that a user can erase everything permanently and move data across only through protected channels. Each step closes with an output that an assessor can inspect.

Inventory every data and settings store
Start from the Article 13(2) risk assessment and list every place the product keeps user data or configuration: databases, file systems, caches, logs, backups, device keystores, cloud buckets and exported files. The product engineering lead owns the list, with the security team reviewing it. The output is an inventory that records, for each store, what it holds, whether it is user data or settings, where it is located, and who can read it. The step is done when the inventory matches the architecture diagrams and no store is marked unknown.
Design the user-initiated erase path
Define the actions a user can take to remove all data and settings, and the scope of each action, such as removing one account, resetting to factory state or wiping a device before resale. The product team documents the user flow, the confirmation prompts and the conditions under which erasure is irreversible. The output is a written erase specification that maps each inventoried store to the action that clears it. Confirm the design with the user interface and support teams before build starts.
Implement and test permanent deletion
Build the erase routines so each store is overwritten, cryptographically erased by destroying its keys, or deleted through the storage platform's documented removal method, depending on the medium. Engineers add automated tests that write known test data, run the erase path and confirm the data cannot be read back through the application or the storage interface. The output is a test report that ties each inventoried store to a passing erase test. Where the product relies on encryption, confirm that key destruction is recorded and cannot be reversed by the product.
Define protected data transfer paths
Where the product can move user data to another product or system, such as an export file, a migration tool or an API, specify how the transfer is authenticated, encrypted in transit and limited to the authorized recipient. The security architect records each transfer path in the erase specification and the risk assessment. The output is a transfer register listing every path, its protection mechanism and the test that confirms the protection works. Confirm with the product owner that no transfer path exists outside this register.
Verify erasure across backups and logs
Test whether deleted data persists in backups, replicas, snapshots, logs, telemetry and caches after the erase path runs. Document the retention behavior of each, then define how the product either purges those copies, excludes personal data from them or tells the user how long they remain. The independent test team or internal assessor reproduces the scenario from a clean state. The output is a verification record that shows the erased data is absent from every store in the inventory, or a documented residual with its justification.
Write secure decommissioning instructions
Draft the user instructions required for secure decommissioning, explaining how to remove all user data and settings, how to confirm the removal and which data may remain if the product connects to third-party services. The technical writer and product manager prepare the text, and the security lead checks each statement against the test results. The output is an instruction set that matches the verified behavior and identifies any residual data the user must handle. Confirm the final wording against the requirements of Annex II before release.

How to show that deleted data is actually gone

The claim that data is gone must match what a tester can recover, so the manufacturer should verify the reset and removal function the way an assessor would: by checking storage after the operation, not by reading the menu label. Start with the user-facing reset path for each product variant and each storage type it uses, including internal flash, eMMC, SD cards and any external storage the product can write to. After a factory reset or a remove-all-data action, run forensic imaging and keyword or file-carving searches against the raw medium using known test artifacts such as configuration values, account identifiers and sample personal records written before the reset. Record the tool, its version, the image hash and the result. Repeat the test on a device that has been through several fill and reset cycles, because wear-leveling and journaling can leave copies in places a single test never reaches.

Where the product encrypts data, the test shifts to the keys. Confirm that the removal action destroys the key material that protects the user data, not just the file-system pointers, and that no escrowed, cached or backed-up copy of that key survives the reset. A useful test is to perform the reset, then attempt to recover the data with the old key material from a captured image taken before the reset. If recovery fails, document the key lifecycle: where the key lives, when it is destroyed, and which hardware or software component performs the destruction. Also check cloud and backup retention. Synchronization, telemetry, remote backup and vendor-managed snapshots can keep copies after the device is wiped, so confirm with the operations team how long those copies persist and whether the user is told. Where a physical medium cannot be fully overwritten, record the limit in the technical documentation and in the user instructions required under Annex II, point 8(d), rather than leaving it implicit.

Keep every test result tied to a specific software version and hardware revision, and rerun the verification after each change to the storage layer, the encryption design or the update process. Ask any test provider or consultant to deliver raw evidence, scripts and a written statement of what was and was not recovered, and make sure the final statements in the user documentation are no broader than those results. Conformity assessment and market surveillance authorities will test behavior, so an assertion that the device is securely wiped without a corresponding test record is a finding waiting to happen.

Evidence that passes a secure data removal review

A secure data removal review tests whether a user can erase everything permanently and whether data leaving the product is protected on the way out. The artifacts below connect the design decisions to proof, and each one needs a named owner and a refresh cycle that runs for the whole support period.

Data inventory and storage map

A register of every category of user data and setting the product stores, where it lives (primary store, caches, logs, backups, telemetry buffers) and who can read it. This is the starting point for (2)(m) because a reset that misses a store fails the requirement regardless of how good the erase routine is. Check that the inventory is reconciled against each release, since new features often add a store nobody recorded. Illustrative: a mobile app that caches session data on the device may not appear in the server-side inventory at all.

Erase and reset test reports

Dated test results showing that the user-facing erase or factory reset removes every item in the inventory, with the method, build version and tester recorded. Reports should include a verification step that looks for residual data after the erase, not only confirmation that the menu action completed. Repeat the tests on each release and after changes to storage, encryption or account handling. Ask the implementation partner to confirm which stores were excluded from testing and why.

Key destruction records

Where data is encrypted, removing the data permanently often means destroying the keys that protect it. Records should show which key material exists, where it is held, when it was destroyed on a reset and how destruction was verified. Crypto-erase only works if no other copy of the key survives in a backup, escrow or key management service, so this record must be cross-checked with the backup design. Confirm with your engineering team whether key destruction is immediate or deferred.

Transfer protection design and test results

Where a user can move data to another product or system, the design document should name each transfer path, the protection applied (authentication, encryption in transit, integrity checks) and the trust decisions behind it. Pair the design with test results that show a transfer fails when the receiving endpoint is unauthenticated or tampered with. Review export files, sync features and migration tools separately, since each one tends to bypass the reset logic built for the main application.

User instruction excerpts for decommissioning

The user instructions must describe secure decommissioning and explain how user data can be removed. Keep the excerpt that covers these steps under version control with the release it describes, so an assessor can match wording to the shipped product. Check that the steps match what the test reports prove, because instructions that promise a removal the product does not perform create a finding of their own. Ask for the instructions to be reviewed whenever a storage or reset feature changes.

Retention settings for backups and logs

Backups, audit logs and telemetry often keep user data after a reset. Document the retention period for each, the default value shipped with the product, whether the user or administrator can change it, and how purge jobs are tested. Where an organization operates the platform itself, the retention policy must be applied in its own infrastructure, not only described. Review these settings at each support cycle so that a default changed in a later release does not quietly extend how long data persists.

What meeting secure data removal costs in money and effort

This table breaks down the cost components of meeting Annex I Part I (2)(m) and shows who is paid for each, whether it is one-time or recurring, and what moves it up or down. No price or duration is stated because none is supplied, so use the drivers to frame a written scope and quote request.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Engineering to design erase and transfer paths	Internal engineers or an implementation partner under a fixed-scope agreement	One-time, with revisits at each major release	Number of data stores, settings categories and export formats; lower when data is kept in few, well-documented locations
Build of user-facing erase function	Internal developers or a partner building the reset and wipe workflow	One-time, then maintained	Whether erasure is one action or multi-step, and how many user roles can trigger it
Secure transfer path for data moved to other products	Internal or partner security engineers, plus integration testing with receiving systems	One-time per integration, recurring when interfaces change	Count of supported destinations and the protocols they require; each new destination adds a test surface
Test effort for erasure and transfer	Internal QA, security testers or a testing provider	Recurring with each release and each change to storage	Coverage of backups, logs, caches and replicas; broader coverage increases effort
Verification tooling and forensic checks	Tool licenses or open-source tooling set up by the organization or partner	Mostly one-time setup, recurring for licenses and maintenance	Need for evidence that data is unrecoverable, which may call for specialized forensic checks
Documentation of user instructions and technical file	Product and compliance staff, with input from engineering	One-time, then updated with each change	Number of products and configurations described; Annex II instructions must cover secure decommissioning
Independent review or penetration testing of erasure	External testing firm or assessor, chosen and paid by the organization	Recurring, usually tied to major releases or conformity routes	Product class, the conformity assessment route and the depth of testing agreed in the written scope
Upkeep as data stores and features change	Internal product teams or a retainer with an implementation partner	Recurring for the whole support period	Frequency of new features that store data, and the rate of changes to backup, logging and sync behavior

Who does what: your team, a partner and the auditor

The manufacturer remains accountable for the product and for every statement made about it. For point (2)(m), that means deciding what counts as user data and settings, how a user removes them permanently, and whether any transfer to another product or system exists. These decisions belong in the cybersecurity risk assessment under Article 13(2) and in the technical documentation, and only the manufacturer can approve them.

Scope of data: decide which data, settings, keys, logs and caches the product holds, and which of them users must be able to erase permanently.
Removal design: approve the removal flow, including whether it is a single action, what confirmation the user must give and what the user sees afterward.
Transfer paths: record every export, migration or synchronization route to other products or systems, and decide how each one is protected.
User instructions: write the secure decommissioning steps that Annex II point 8(d) requires, including how user data is removed.
Decision record: keep a dated record that links each choice to the risk assessment and to the conformity route for the product.

Check that a named person in your organization owns each of these decisions and can explain it to an assessor without a partner in the room.

Where manufacturers usually fall short on data removal

Most failures under Annex I Part I (2)(m) are not missing features. They are gaps between what the reset button claims to do and what the product actually leaves behind, in backups, telemetry, exports and decommissioning guidance. The cards below cover the places where a reviewer is most likely to find data that should have been removed.

Reset that hides data

A factory reset that only clears the user interface, removes pointers to records, or marks storage as free leaves the original data readable on the device. Point (2)(m) asks for permanent removal, so the reset has to make recovered data unusable, for example through cryptographic erasure of a device key or overwriting of the affected storage. Check whether a forensic read of the storage after reset returns user content. Record the method and its limits in the risk assessment.

Forgotten backups and caches

Cloud backups, local caches, crash dumps and sync queues often hold copies of user data that the main reset never touches. Each copy is a separate place where data persists after the user believes it is gone. List every storage location the product writes to, including those created by integrations, and confirm that the removal path reaches all of them or that the copy has a documented expiry.

Telemetry that outlives the account

Analytics events, diagnostic logs and usage records sent to the manufacturer's back end can keep user-linked data long after the user removes data from the device. Removal on the product does not remove what the vendor already holds. Confirm which telemetry is linked to a user or device identifier and whether a removal request reaches the back end. Document retention periods for each category.

Unprotected export files

When a user moves data to another product or system, the transfer file may be unencrypted, carry long-lived credentials or be left on shared storage. Point (2)(m) requires that transfers to other products or systems happen securely, so the export path needs authenticated, protected formats and a clear warning when a file leaves the product. Test whether an exported file contains secrets such as tokens or passwords.

Undocumented decommissioning steps

Annex II point 8(d) requires user instructions that explain secure decommissioning and how user data can be removed. Manuals that say only "reset the device" leave users unable to judge whether removal worked, and they hide dependencies such as paired accounts or cloud bindings. Write the steps in order, state what is removed and what is not, and say how the user can confirm the result.

Evidence that does not match firmware

Test results recorded against one firmware build are weak evidence for a later release that changed storage layout, encryption keys or sync behavior. Each release that touches data handling should reopen the removal test. Ask the team to tie every removal test report to a firmware version and a commit, and to show that the shipped image is the one tested.

Questions buyers ask about secure data removal

How much effort does secure data removal take to meet under the Cyber Resilience Act?

Effort depends mostly on how many data stores, settings and transfer paths the product has, and on whether removal already exists in the codebase. No researched figure for effort is available for this requirement, so treat any number you hear as unverified. The main work is inventory and engineering: listing everywhere user data and settings live (databases, caches, logs, backups, local device storage, exported files), building a removal path that covers them, and writing the user instructions. Ask any partner to break its estimate into those components before agreeing a fixed scope.

How long does it take to add a permanent data removal feature?

No supplied fact gives a duration, so confirm it against your own codebase rather than a generic benchmark. Timing usually follows the size of the data inventory, the number of products or deployment models in scope, and how many separate reviews, test cycles and documentation updates the release needs. Products that already separate user data from configuration tend to move faster. Ask for a written timeline with milestones tied to the inventory, build, test and documentation stages.

What does the team need to provide before secure data removal work starts?

The team needs access to the architecture, data flow diagrams, storage schemas, backup and log configurations, and the list of third-party services that hold user data. Engineers also need a clear product owner who can decide what counts as user data and what must survive removal, such as legal holds or audit records. Without these inputs, the removal scope stays uncertain and the eventual user instructions will be incomplete.

Can our own engineering team implement secure data removal without outside help?

Yes, many product teams can, provided they have engineers who know the data model and someone who can map the requirement to evidence. The requirement is one of several under Annex I Part I, so the in-house team must also keep the risk assessment, technical documentation and user instructions aligned. Organizations often outsource the inventory, the test design and the documentation review, while keeping ownership of product decisions. The manufacturer remains responsible for conformity either way.

What will an assessor sample when checking secure data removal?

An assessor typically asks you to demonstrate the removal function end to end on a test account, then checks whether data and settings are gone from the places your inventory lists. They will also sample the transfer path, confirming that moved data is protected in transit and that the transfer cannot leak data the user did not intend to send. Finally, they read the user instructions for the secure decommissioning content. Keep dated test records, removal logs where appropriate, and a current inventory so each sampled item can be traced.

What evidence should we keep to show secure data removal works?

Keep the data inventory, the design decision that explains which stores are covered and why, the test plans and results from removal runs, and screenshots or logs from the removal flow. Also retain the transfer security design, the user instructions that describe decommissioning, and the version history showing when the feature changed. Evidence should be tied to a specific product version so an assessor can see what was tested.

How should we scope a partner for secure data removal work?

Ask for a written, fixed scope that lists the products and versions covered, the data stores and transfer paths in scope, the deliverables (design, implementation, tests, documentation) and the handover of evidence. DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Remember that DeployOpen prepares systems and evidence but does not issue assessment reports or certificates. Only an independent assessor or certification body can do that, and you should confirm which one your conformity route requires.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so data removal and transfer behavior can be designed, tested and documented against Annex I Part I (2)(m). We prepare the systems and evidence for your manufacturer obligations, while your organization keeps ownership of its controls and any independent assessment is performed by a third party.

How we scope

The written scope lists each product, module and user-facing path where data or settings can be removed or exported.
Scope names every transfer route to other products or systems, such as export files, APIs and backup restores.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure user-initiated permanent deletion of data and settings, then verify that removed records are not recoverable through normal interfaces.
We secure data transfers to other systems with authenticated, encrypted channels and documented format and destination controls.
We test removal and transfer behavior against the risk assessment, including residual data in logs, caches and backups.

How we hand over

We document the removal procedure, transfer controls and known residual exposures in the technical documentation.
We prepare test records, configuration exports and repeatable verification steps that your team can retain as evidence.
We agree with you which decommissioning content will feed the user instructions required by Annex II point 8(d).

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so removal behavior is rechecked after each release.
Retesting is scoped whenever a component, storage layer or export format changes during the support period.
Confirm with your legal and compliance leads how removal evidence will be reviewed and by whom before the engagement starts.