Setting Retention Triggers and Cutoffs

A retention period only means something once you know the moment it starts. A schedule that says “retain three years” answers how long but not three years from when. The mechanism that answers the second question is the retention trigger (the event that begins the retention clock) paired with the cutoff (the administrative act of closing a file so the clock can start running). Getting these two concepts right is what separates a schedule that disposes of records reliably from one that quietly accumulates everything forever because nothing is ever eligible.

Triggers and cutoffs are the operational heart of retention and disposition. They translate the legal and policy decisions captured in a records schedule into something a person—or, increasingly, a system—can execute on a predictable cadence. This article explains the two main families of triggers, how cutoffs function as a batching device, and the practical pitfalls that cause well-designed schedules to fail in the field.

Time-Driven Versus Event-Driven Triggers

Retention triggers fall into two broad categories, and most schedules use a mix of both.

• Time-driven (or time-based) triggers start the clock on a recurring calendar boundary, typically the end of a fiscal or calendar year in which the record was created or last acted upon. A record described as “destroy 3 years after cutoff” with an annual cutoff becomes eligible three years after the close of the year it was filed. Time-driven triggers are simple, predictable, and easy to automate because the triggering date is known the moment the record is created.

• Event-driven (or event-based) triggers start the clock only when a defined business event occurs—a contract expires, an employee separates, a case is closed, a piece of equipment is decommissioned, a loan is paid off. The retention period is then expressed relative to that event: “destroy 6 years after contract termination.” The challenge is that the event date is unknown when the record is created and may arrive years later, so the system must be told when the event happens.

A common and powerful pattern is the event plus time combination, where an event triggers a cutoff and a time period runs afterward. “Superseded or obsolete, then destroy when no longer needed” and “destroy 5 years after case closure” are both examples. The event establishes the starting line; the time period sets the distance to the finish.

Cutoffs: Closing the File So the Clock Can Start

A cutoff (sometimes called file closure or breaking the file) is the act of ending an active accumulation so that retention can begin. In paper practice, this meant literally starting a new folder—closing the FY2024 contracts folder at year end and opening FY2025. The retention period applies to the closed file, not to individual documents added piecemeal.

Cutoffs matter for two reasons. First, they let you apply one retention calculation to a whole batch of records rather than tracking each item’s individual age, which is administratively essential at scale. Second, they prevent the clock from running on a file that is still receiving active additions. Without a cutoff, a record that is still being added to in year four would already be eligible for destruction—an obvious problem.

Cutoffs themselves can be time-driven (close every file at the end of the fiscal year) or event-driven (close the case file when the matter concludes). The key discipline is consistency: a cutoff that is supposed to happen annually must actually happen annually, or the eligibility dates downstream will be wrong.

Designing Triggers That Survive Contact With Reality

Several design choices determine whether triggers work in practice:

• Choose observable, recordable events. An event-driven trigger is only as good as your ability to detect the event. “Project completion” is useless if no one records the completion date. Tie triggers to events that already produce a system signal—a status change, a closed flag, a termination date in an HR system.

• Avoid ambiguous events. “When no longer needed” and “upon supersession” require human judgment and tend to stall. Where you must use them, pair them with a maximum time backstop so records cannot live indefinitely.

• Document the trigger logic in the schedule. The schedule should state plainly what starts the clock, how long the period runs, and what cutoff applies. Ambiguity here is the most common reason disposition does not happen.

• Plan for legal holds. A hold suspends disposition regardless of the trigger. Your trigger logic must coexist with hold logic so that an eligible record under hold is preserved, then released back into the disposition workflow when the hold lifts.

Automating Triggers in Electronic Systems

In electronic records management, triggers and cutoffs become metadata-driven rules. Time-driven triggers are straightforward because the system can compute eligibility from a creation or filing date. Event-driven triggers are harder: the system needs an explicit signal—an API call, a workflow status, a manually entered event date—to know the event has occurred. Capturing that event reliably is usually the hardest part of an event-driven implementation, not the retention math.

Buyers once leaned heavily on the DoD 5015.2 standard as a checklist for these capabilities. Notably, NARA revoked its endorsement of DoD 5015.2 in 2022 in favor of the Universal Electronic Records Management (ERM) Requirements developed through the Federal Electronic Records Modernization Initiative (FERMI). Agencies and vendors now look to those functional requirements—covering capture, maintenance, and disposition including trigger and cutoff handling—rather than treating 5015.2 certification as the benchmark. International standards such as ISO 15489-1 likewise frame disposition as a controlled, authorized process driven by appraisal decisions rather than ad hoc deletion.

Common Failure Modes

Trigger and cutoff problems are usually quiet. Records do not get destroyed prematurely; they simply never become eligible, and storage grows. Watch for: schedules that specify a duration but no trigger; event-driven triggers with no mechanism to capture the event; cutoffs that are defined in policy but never performed; and inconsistent fiscal-versus-calendar-year conventions across departments. Each of these breaks the chain between how long and from when, and the result is the same—disposition stalls. Periodic reconciliation of what should be eligible against what the system reports as eligible is the most effective way to catch a broken trigger before it becomes a years-long backlog.