Start with the record’s business process, period, entity, owner, and sensitivity. An original bank statement, a final reconciliation, and a draft spreadsheet should not be treated as interchangeable because each supports a different question. Record how a final output links to its source and who approved it. If the system preserves version history, note that history rather than exporting many near-identical copies without context.
Duplicates deserve a deliberate test. A downloaded invoice may be duplicated in an email attachment and a shared folder. The team can identify the preferred location and link the duplicate to it, but should not remove a copy if a hold, contract, system rule, or client policy prevents that action. If a record is superseded, preserve the replacement relationship and reason where the platform allows it. “Old” is not the same as “disposable.”
Retention also includes access and retrieval. A record that technically exists but cannot be found, opened, or connected to the ledger is weak evidence. Test a sample by asking another reviewer to retrieve the source, understand the period, and follow the link to the transaction or report. For sensitive payroll or customer data, restrict access according to the client’s rule and avoid copying it into informal channels merely to make the handoff easier.
The retrieval test should include an ordinary user, not only the person who created the folder. Ask that reviewer to identify the record owner, reporting period, source system, approval status, and related ledger entry. Note whether the file opens in the approved location and whether its version history explains later changes. If the reviewer cannot answer those questions, the problem may be classification or access rather than storage capacity. That distinction matters before anyone proposes a deletion or migration project.
