How to Stay Compliant With a Records Retention Schedule

TL;DR: You comply with a records retention schedule by knowing which record series each file belongs to, when its retention period started, and whether a hold is active. Almost every institution leaves all three judgments to individual staff who are not records specialists, which is where compliance breaks.

A records retention schedule is usually a good document. It is researched, legally reviewed, and specific about how long each record series is kept and what happens at disposition.

Then it gets handed to a department coordinator with four hundred folders and no time, and that is the end of it.

The gap between a schedule existing and a schedule being followed is not a gap in policy. It is a gap in labour, and it is almost never staffed.

What does a records retention schedule actually require?

Three judgments per file, each of which is harder than it looks.

Which record series does this belong to? Schedules are organized by series: employment records, financial source documents, student records, contracts. Filing a document means classifying it correctly first. A person who is not a records specialist has to decide whether a signed vendor agreement is a contract record or a financial record, and the retention periods may differ.

When did the retention period start? Retention clocks rarely start at file creation. They start at an event: the end of a fiscal year, the closure of a matter, the separation of an employee. Penn State's schedule, for instance, holds that staff and wage payroll files "must be destroyed (shredded, deleted or purged) six (6) years after the employee leaves the University." (Penn State AD35 FAQs) Nothing in the file's metadata records the leaving date. A person has to know it.

Is anything suspending the clock? An audit, an investigation or a legal hold stops disposition regardless of what the schedule says. This is covered in more depth in legal holds and records destruction, and it is the check most often skipped.

UBC's manual describes the lifecycle this ladders into: "Records are typically understood as existing within a life cycle: records creation, use, and finally, disposition." (UBC Records Management Manual) The schedule governs the last step. Everything that makes the last step possible happens in the first two.

Why does retention compliance stay manual?

Because partial automation covers the easy cases and leaves the hard ones untouched, and the hard ones are most of the drive.

UBC is unusually candid about where the line falls: "UBC automates destruction of some digital information; however, individual units must manually remove other digital records that are no longer required according to the timetables detailed in the RDS." The automated part is the part with a reliable system signal, which turns out to be Teams messages and default Outlook folders like Trash and Junk.

Everything in a shared drive falls on the manual side, because a file system stores a name, a date and a size, and none of those is a record series. The schedule is expressed in a vocabulary the storage layer has never heard of.

So the work falls to people. Ohio State's guidance adds a procedural step on top: "For those records that have met retention, an approved Certificate of Records Destruction (CRD) is needed before they can be deleted." (Ohio State University Libraries) That is correct governance and it is also more work, which means it competes with the actual job of the person who has to do it.

What happens when nobody follows the schedule?

Two failure modes, running at the same time, in opposite directions.

Over-retention. Everything is kept forever because keeping is free and deleting is frightening. This inflates storage, but the sharper problem is discovery exposure: material that should have been disposed of years ago is still available to be produced in litigation. You kept it, so you have to hand it over.

Under-retention. Somebody cleaning up deletes something still inside its retention period, or still under hold. This is the failure with personal consequences.

Penn State does not leave the consequence ambiguous. Its policy FAQ states that "Failure to comply with the policy will be considered a violation of an employee's service agreement and subject to discipline."

Read that from the point of view of the coordinator holding four hundred folders. The organization has attached a disciplinary consequence to a task it has not given them the time or the tooling to do correctly. The rational response is to do nothing, which produces over-retention, which is exactly what most institutions have.

Where does compliance break most often?

At staff turnover, and it is predictable enough to plan for.

Penn State's process expects the departing employee to prepare: "Prior to retirement, a current employee should create a directory for paper records or develop a shared drive for all electronic records (including e-mail) that will be utilized by their administrative unit upon their retirement. Within thirty (30) days of said retirement, the employee's computer can be scrubbed and put back into use, unless subject to a litigation hold."

That works when someone gives notice and does the work. It does not work when someone leaves abruptly, and it does not work when the drive they leave behind is organized around how they personally thought about the job. The institution then has thirty days to reconstruct a filing system from the outside, and it needs to know which of those files are records, which series they belong to, and when their clocks started.

This is the strongest practical argument for function-based folders over person-based ones. Duke makes the reasoning explicit: a functional structure "is not dependent on individual staff folders or larger departmental organization, so if employees change roles, or the department is reorganized, the shared drive can still be used." (Duke University Libraries)

A drive organized by function survives the person leaving. A drive organized by person does not. When you are on the wrong side of that and have thirty days, reorganizing a departing employee's drive is the salvage job, and it should not run at all if a matter is open.

How do you turn a retention schedule into something staff can follow?

Stop asking people to recall the schedule, and start showing them the subset that applies to what is in front of them.

Classify at intake, not at cleanup. The cheapest moment to decide what a document is, is when it arrives, while its context is still obvious. Deciding three years later, from a filename, is guesswork. Filing records into the right series on arrival is the workflow shape for this. This is also why filing conventions matter more than they appear to: see how to create a file naming convention.

Record the trigger event, not just the date. If the clock starts at matter closure or employee separation, that date has to live somewhere the drive can see. A folder named for the closure year does more real compliance work than a policy document nobody opens.

Make the schedule a queue, not a manual. Instead of expecting a coordinator to remember that payroll files go at separation plus six years, generate the list of records that appear eligible this quarter and route it for review. The person stops being a lookup table and becomes an approver. Applying a retention schedule on a clock covers how that sweep is built, with an approval in front of anything clearing.

Keep disposition reversible for a window. Duke's staging tip applies here directly: move candidates to a "To Be Destroyed" folder and wait thirty days before deleting, which "provides other staff an opportunity to review material before deletion."

Can software apply a retention schedule automatically?

It can build the queue. It should not pull the trigger, and a vendor that says it will is worth treating with suspicion.

The reason is not technical modesty. It is that the inputs are not all in the system. A retention decision depends on whether a matter is closed, whether an audit is pending, and whether counsel has issued a hold. Those facts live in people's heads, in email, and in conversations that never touched the drive. A tool that applies disposition on schedule will eventually destroy something under hold, and the institution, not the vendor, carries that.

The Drive AI is built to that boundary. It classifies documents as they arrive, files them by the structure you describe in plain English, and answers questions across a drive like which client folders have had no activity since 2022. That gives a records coordinator the raw material for a disposition review without a month of manual inventory.

What it does not do is delete records when a retention period lapses, apply disposition, or track legal holds. Those remain human decisions on a human's authority, and the correct output of any automation here is a list somebody signs off on.

The realistic goal is not an automated retention schedule. It is a retention schedule that produces a reviewable queue each quarter instead of an annual guilt-driven cleanup that nobody has time for.

Frequently Asked Questions

How do you ensure compliance with a records retention schedule?

Classify records into series at intake rather than at cleanup, record the event that starts each retention clock, and review disposition candidates on a fixed cadence rather than ad hoc. Check every candidate against active legal holds before disposal, and keep a documented authorization step for records that have met retention.

Who is responsible for following a records retention schedule?

In most institutions, the individual department or unit holding the records, not the central records office. The central office writes the schedule and advises. UBC's manual states that individual units must manually remove digital records no longer required under the schedule, which is the typical division of labour.

What happens if you keep records longer than the retention schedule requires?

Over-retention increases storage cost and discovery exposure, because material you still hold can be requested in litigation even after you were entitled to dispose of it. It can also itself be a policy violation, since a retention schedule sets how long records are kept, not merely a minimum.

Can a retention schedule be enforced automatically?

Partially. Systems can automate disposal where a reliable signal exists, as UBC does for some collaborative messaging and default mail folders. Records on shared drives generally cannot be handled this way, because file metadata does not record which series a document belongs to or when its retention clock started.

What is disposition in records management?

Disposition is the final stage of the record lifecycle, when a decision is made to either destroy the record or transfer it to an archive. It is governed by the retention schedule and suspended by any active legal hold, audit or investigation.

Where to start

Pick one record series, not the whole schedule. Take the series your unit holds most of, work out what event starts its clock, and find out whether that date is recorded anywhere a person could look up. Usually it is not, and fixing that for one series teaches you what the other twenty need.

From there, what is ROT data covers identifying what is eligible in the first place, and legal holds and records destruction covers the check that overrides every schedule.