Records retention schedules and the systems that hold the records

Reference article · 5 min read

An approved records retention schedule is a legal instrument. It lists the record series an agency creates, states how long each series must be kept, and authorizes destruction afterward. It is approved by the state archives, a state records board, or a similar authority, and local agencies either adopt a general schedule or write their own. It speaks the language of records: minutes, permits, case files, payroll registers, correspondence.

The systems that hold those records are organized differently. A single permit record may live as rows in a database, scanned attachments in a document repository, threads in a mail tenant, and messages in a chat channel, with a copy of all of it in last night's backup. None of those systems reads the schedule. Unless someone has translated series into system-level rules, the schedule governs paper and little else. The gap usually surfaces at a bad moment: a records request turns up email that should have been destroyed years ago, or an audit asks for proof of disposition and no one can produce any.

Map series to systems first

Everything else depends on a crosswalk between the schedule and the technology inventory. For each series, record:

System of record and copy locations. One system holds the official record. Others hold copies that still have to be accounted for.
The retention trigger. Periods rarely start at creation. "Three years after case closure" requires a closure date that exists in the data and is reliably populated.
Custodian. A named person who can approve disposition, not a department in the abstract.
Disposition capability. Whether the system can delete an individual record, delete in bulk by rule, or do nothing at all.

What each class of system can actually do

Line-of-business databases. Retention lives in application logic. Deletes may cascade, may be blocked by referential integrity, or may be soft deletes that hide a row while history tables, audit tables, and reporting replicas keep the content indefinitely.

Email and messaging. Productivity suites support retention policies and holds, but they apply to mailboxes, sites, and labels rather than to series. Many agencies set a uniform period for general correspondence and require substantive records to be filed in a system of record. Text and chat on agency business need the same treatment.

Collaboration tools and file shares. Version history, recycle bins, deleted-item retention, and copies synced to laptops all extend content well past its apparent deletion date.

SaaS applications. Deletion may be a configuration setting, an administrator action, a support request, or unavailable. Vendor backups hold deleted data for a further period, and subprocessors may hold copies.

Backups. A backup exists to restore a system, not to preserve records. A short, uniform, documented rotation is easier to explain than an accumulation of old media no one can search. Immutable and air-gapped copies resist selective deletion by design, so document how the schedule treats them.

Make disposition routine and documented

Disposition should be a scheduled process, not an occasional cleanup. Generate an eligibility report, route it to the custodian and records officer for approval, check it against active holds, execute, and keep a log showing what was destroyed, under which series, when, by whom, and on whose approval. Consistency is the defense: routine destruction under a published schedule is easier to explain than a one-time deletion.

Legal holds outrank the schedule

When litigation is reasonably anticipated, or an investigation, audit, or in some jurisdictions an open records request is pending, the duty to preserve suspends destruction. It has to be enforced in the systems, not only in a memo.

Written notice naming custodians, subject matter, and date range, with acknowledgment.
Technical enforcement that overrides retention automation and preserves content even when a user deletes it.
Coverage of the systems the schedule overlooked, including SaaS applications, chat, and mobile devices.
A hold register so holds are released when the matter ends. Stale holds create their own over-retention problem.

When a system will not delete, or deletes too much

Over-retention is common: a legacy application with no disposition function, a hosted product that exposes no delete, a backup carrying records past their date. Treat it as a documented exception rather than a silent failure. Record the limitation, restrict access so the data is not casually reused, ask the vendor for a written commitment and timeline, and weigh migration or retirement when it persists.

Over-deletion is more damaging and moves faster. A purge job with a wrong filter, a retention label applied at the wrong scope, a license removal that dissolves a mailbox, or a migration that drops attachments can destroy records still within their period. Stop the process, preserve what remains including backup copies, determine the scope and time window, attempt restoration, and notify the records officer and counsel promptly. Then fix the cause: run purge jobs in report-only mode first, test against a copy, and separate the person who configures a rule from the person who authorizes it.

What to ask vendors and require in contracts

Ask whether the system applies different periods to different record types, what date field drives the clock, what remains after a delete, whether a hold can be placed and proven, and how long deleted data persists in vendor backups and with subprocessors.

In the contract, require agency ownership of data, export in a non-proprietary format on demand and at termination, configurable retention with an accessible disposition log, legal hold capability, deletion on agency instruction within a stated period with written certification, and no vendor-initiated deletion or retention change without approval.

Retention law varies by state and by record type, and schedules are amended, so confirm requirements with the state archives, the records officer, and counsel rather than with a system's defaults. HQT works with agencies on records inventories, system-level retention and disposition design, and contract language that makes disposition enforceable.

Frequently asked questions

Do records retention schedules apply to email, chat, and text messages?

Generally yes. Retention obligations follow the content and function of a record, not the format or the tool that created it, so messages about agency business are usually covered. The practical difficulty is that most messaging platforms apply retention by mailbox or channel rather than by record series, so many agencies set a uniform period for general correspondence and require substantive records to be filed in the system of record. Treatment varies by state, so confirm the approach with your records officer and counsel.

What should an agency do when a vendor system cannot delete records on schedule?

Document it as a known exception rather than leaving it unaddressed. Record which series are affected and why the system cannot dispose of them, restrict access so the over-retained data is not casually reused, and ask the vendor in writing for a disposition capability and a timeline. If the limitation persists, weigh it in the decision to renew, migrate, or retire the system, and make disposition an explicit requirement in the next procurement.

How do legal holds interact with automated retention and deletion?

A legal hold suspends destruction for the records it covers, and it must take precedence over any automated retention rule. Place the hold in the platform itself so content is preserved even when a user deletes it, rather than relying only on a written instruction to custodians. Track holds in a register and release them when the matter ends, because holds that are never lifted become their own over-retention problem.

Do backups have to be purged to match the retention schedule?

Backups exist to restore systems, not to serve as an archive. Most agencies address them by keeping a short, uniform, documented rotation rather than attempting to delete individual records from backup media, which is often impossible with the immutable or air-gapped copies used for ransomware recovery. Write down how your records program treats backups so the approach is consistent and explainable, and review it with counsel.

What should we do if records were deleted before their retention period ended?

Stop the process that is deleting, preserve everything that remains including any backup copies, and determine what was destroyed and over what time window. Notify the records officer and counsel promptly, because early destruction can affect a pending request, audit, or legal matter. Attempt restoration from backup where possible, then correct the underlying cause, such as an untested purge job or a retention rule applied at the wrong scope.