Turn a retention statement into a timeline for each data object
A companion app does not have one universal retention period. A visible chat, saved memory, uploaded file, usage log, derived preference, shared link, and backup may each have a different purpose, starting event, storage state, and removal path. Read every period as a clock with a named object: what starts it, what keeps the item active, what triggers deletion, whether it enters a queue or archive, what happens to backups, and whether another recipient controls a separate copy. ‘Deleted from your history’ is a user-interface state, not automatically the final timestamp for every system. The useful answer is a set of dated timelines, not one attractive number taken from a general policy.
Start with the data object, not the company name
List the objects separately: account profile, conversation text, voice or image attachment, saved memory, activity event, inferred interest, feedback package, shared link, export, support ticket, billing record, and security log. Then name the current purpose for each. A chat kept so you can reopen it is not the same object as a short operational log, an account-recovery record, or a preference derived from several sessions. ICO guidance ties retention to purpose and review rather than a universal duration. When a policy gives one period without saying which objects it covers, mark scope unknown. Do not borrow the duration for visible chats and apply it to files, memories, or technical records.
Find the event that starts and resets the clock
A period such as thirty days or two years has little meaning without a starting event. It might begin at collection, last use, account inactivity, subscription end, deletion request, closure of a support case, or resolution of a technical issue. Ask whether opening an old conversation, restoring an account, sending feedback, or reconnecting a service resets the clock. Record the time zone and whether calendar days or elapsed hours are used when the distinction matters. If the product says ‘after deletion,’ note when the request was accepted and when the item disappeared from the interface. A reliable card keeps request time, visible-removal time, stated processing window, and final verification as four different timestamps.
Separate active data, archive, backup, and deletion queue
Active storage supports the current feature. An intermediate archive may be restricted and kept for a different, stated reason. A backup is a recovery copy governed by rotation and restore procedures. A deletion queue is a process state, not a new promise that the item vanished instantly. CNIL materials distinguish active use from intermediate archiving and later destruction or anonymisation. For an app, ask whether archived material is searchable, used for personalization, accessible to ordinary staff, or restored during disaster recovery. If a backup is restored, learn whether deletion markers are reapplied. Do not call an item fully gone merely because it left the main screen; record the state named by the service and the next transition.
Track derived data and shared-party copies separately
Deleting a source conversation may not explain what happens to a saved memory, transcript, thumbnail, moderation flag, aggregate statistic, or inferred preference created from it. Ask which derived objects remain linked to the source, which are updated, and which have their own clock. Third-party processors, connected services, public-link viewers, and people who downloaded an export can also hold separate copies. A provider may describe when it instructs a processor to delete, but it cannot remove a file another person saved to their own device. Add a recipient row with role, data received, purpose, retention clue, deletion responsibility, and confirmation route. This prevents a first-party period from being misread as a deadline binding every outward copy.
Read exceptions narrowly and without inventing a rule
Policies sometimes describe limited retention for security, dispute handling, fraud prevention, recordkeeping, or technical recovery. Record the stated category, access restriction, end condition, and whether the data remains available to product features. Do not turn a broad phrase such as ‘as required’ into a guessed number, and do not offer a legal conclusion for the reader’s location. The FTC has emphasized reducing data that lacks a current need because unnecessary retention adds exposure. For an ordinary decision, the practical questions are whether the exception is explained, whether the data is isolated from routine use, whether the endpoint is defined, and which official contact can clarify an unknown. Unknown stays unknown until the current service answers it.
Run a dated deletion and recheck test
Create a harmless test conversation with a unique phrase and no personal detail. Record the account, device, object types, and current documentation. Delete it through the published route, then check the history, search, memory, files, shared links, export, and another signed-in device. Wait only the service’s stated period, not a number copied from another provider, and check again. Keep a receipt with request time, visible removal, queue or archive statement, verification date, and remaining unknowns. Repeat after account closure, a major policy change, or a new connected service. The test shows only the route and version you observed; it does not prove the contents of inaccessible backups, so describe that boundary honestly.
Common questions
Does one retention period cover every type of app data?
Usually not. Chats, memories, files, activity, derived records, backups, and support data can have different purposes and clocks.
Does disappearing from history mean final deletion?
Not necessarily. It proves a visible state; check the stated queue, archive, backup, and derived-data path.
When should I recheck a retention card?
After a policy or product change, account closure, new integration, or when the documented review date arrives.