A phone-storage change can be as small as clearing cache or as consequential as deleting downloads, offloading apps, changing a backup account, or preparing a factory reset. A short evidence record protects against two common problems: not knowing what was removed and not knowing whether the backup can actually restore it.
Capture the starting state
Record the device model, operating-system version, date, account used for backup, total capacity, available space, and the largest storage categories. Take a screenshot of the storage summary, but redact personal file names, messages, and account identifiers before sharing it. On iPhone, the storage view is under Settings > General > iPhone Storage, and Apple documents that offloading an app retains its documents and data (Apple iPhone Storage guide). Record whether the planned action is offload, delete, cache clearing, file movement, or account migration because those terms are not interchangeable.
On Android, record the app or system screen used and the exact button selected. Google's storage guidance distinguishes clearing cache, which deletes temporary data, from clearing storage, which permanently deletes app data (Google Android storage guide). A note that says only “cleaned app” is too vague to support recovery.
Verify backup evidence before deletion
For high-value data, record the most recent backup time, destination account, categories included, and one successful spot check from another device or restore environment. Google's Android backup guidance says the backup is uploaded to a Google Account and also warns that not every app backs up or restores all settings and data (Android backup guide). Therefore, a device-level “backup complete” indicator should not be treated as proof that every app's content is recoverable.
Create a small inventory of irreplaceable items: recent photos and videos, recordings, downloads, notes, messages, and app-specific records. File counts and total sizes can help when practical, but opening a representative sample on the destination is stronger evidence than matching a single total. Never record passwords, recovery codes, or unredacted private content in the change log.
Record the action and its recovery route
Write down who made the change, when, why, which categories were affected, the exact path and control used, and any warning shown. Recovery depends on the route. Files by Google states that Trash keeps files for 30 days, while items removed through its junk-files card bypass Trash and are permanently deleted (Files by Google Trash). Capture whether the deletion went through Trash, an app's own recently-deleted area, or a permanent cleanup path.
Measure the result
Afterward, record available storage, change in each affected category, errors, and whether key apps still open and retain their expected data. If files were moved, open samples at the destination and verify that sharing or export still works. If an account changed, confirm that a second authorized person can access the intended business or household data without the former owner's personal credentials.
For repeatable operations, give the change an ID and retain the request, justification, test, approval, result, and rollback or restoration steps. That structure aligns with the change-record elements in NIST SP 800-53 CM-3 (NIST SP 800-53 Revision 5).
A useful storage-change record can fit on one page: starting state, backup proof, item scope, exact action, deletion or recovery route, ending state, validation samples, owner, and follow-up date. Keep it long enough to outlast the device handoff or recovery window, then dispose of it according to the organization's privacy policy.
Sources
- Check iPhone storage — Apple
- Free up space — Google
- Back up or restore data on your Android device — Google
- Move files to Trash and restore files from Trash — Google
- Security and Privacy Controls for Information Systems and Organizations — National Institute of Standards and Technology, Sept. 23, 2020