PENTESTY · EDITORIAL ANALYSIS · · 4 min read
Trezor and ShipMonk: deletion assurances need to cover the copies
The supplier confirmed deletion. Consider which evidence can establish its scope across operational systems, exports and recovery procedures.
By Pentesty
The statement has a date and an attribution
In its September 4, 2026 update, Trezor reported exposure of data concerning approximately another 67,000 U.S. customers at ShipMonk, covering orders from November 2019 through August 2021. According to the manufacturer, the provider had confirmed deletion in writing. Trezor stated that its own systems and devices were not compromised. This is the contracting company’s account of the logistics incident, rather than an independent technical reconstruction.
The receipt should identify what was deleted
A contract may specify a deadline, but operations teams need to know when it starts and which records enter the procedure. Delivery, returns and termination of the commercial relationship may trigger different processes. Define the rule for each dataset, with an accountable owner and handling for exceptions needed to deliver the service.
Trezor’s policy describes deletion of order data after 90 days, with stated exceptions. That period belongs to the company’s policy and should not be presented as a universal requirement. When assessing another supplier, ask for the rationale behind its applicable period and a description of how the rule is carried out.
Map the copies before requesting evidence
A delivery operation may send data to support tools, labels, reports and analytics systems. For each path actually used, record who receives the information, how long they need it and how they participate in deletion. Do not assume that removing a row from the main system eliminates an earlier export.
Request an inventory proportionate to the contract, without seeking information about the provider’s other customers. Connect operational systems, working copies and recovery procedures to their owners. This complements our analysis of third-party access in the Danish case: permitted access and necessary retention are separate decisions.
Rehearse the lifecycle with a fictional order
Agree on an authorized environment with the supplier and create a recognizable synthetic identifier. Route the record only through components included in the exercise. If a production system cannot participate, record the limitation and request corresponding documentation; do not fill the gap with a conclusion that deletion was complete.
Trigger the agreed procedure and check the points where the record should stop appearing. Compare a normal query with an authorized export. Also record what happens to a legitimate request after deletion, so dependencies requiring further handling become visible.
- Before: fictional dataset, expected destinations, applicable period and execution owner.
- During: procedure identifier, timing, covered systems and documented exceptions.
- After: authorized queries, observed outcome and a decision on copies requiring different treatment.
Recovery also needs to respect deletion
Ask how the provider handles records that could reappear when an earlier copy is restored. A useful response identifies the copy’s retention period, who may access it and the procedure for reapplying deletions when required. Do not replace that explanation with a blanket demand to erase every backup immediately.
Rehearse restoration with synthetic content where it is in scope and operationally feasible. Check the outcome before reopening the application for normal use. If the exercise does not reach this stage, document that dependency at acceptance and assign the next check to an accountable owner.
A discrepancy should change the decision’s status
If the sample reappears where it should have been deleted, preserve minimized evidence and pause the deletion conclusion for that dataset. Request investigation of its scope, with communication and containment criteria defined by the responsible teams. Resolve the discrepancy without treating one sample as the count for an entire incident.
Receiving reports also calls for origin and authorization criteria, as discussed in corporate investigations and data provenance. At closure, state which copies were checked, which depend on a declaration and which remain unresolved.
Frequently asked questions
Does this case establish a compromise of Trezor wallets?
The statement attributes exposure to logistics and says Trezor systems and devices were not compromised. Do not equate order information with access to hardware.
Does a written assurance lose its value?
It documents an important statement. Ask for the dataset, procedure and limitations so the assurance can be connected to available evidence.
Must every supplier delete data after 90 days?
The period cited is Trezor’s stated choice. Each organization needs to define its applicable rule with responsible teams and document exceptions.
How can we test without real personal information?
Use fictional orders and synthetic identifiers in expressly authorized components. Record the exercise’s coverage and avoid querying other customers’ information.
Sources and references
Original Pentesty analysis, published October 16, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.