Event-Based Retention Rules

Every Records Retention Schedule contains retention rules that require an event to occur before the retention clock starts. For example: an employee is separated from the organization or a contract is terminated or a particular model of appliance is no longer in production. Depending on your industry, up to 50 percent – or more – of your rules may fall into this category. And, if you are like most organizations, you continue to struggle with an effective way to flip the switch that begins the destruction eligibility count down. In fact, recent statistics show that 67 percent of organizations agree that their RIM program would benefit from fewer event-based retention periods.1

This white paper offers some potential options for tackling the event-based retention conundrum. As you read through them, you will need to consider your organization’s risk profile, ability to commit resources, and attitude towards “keeping everything” to determine if one or more are applicable to your situation.

The Challenge

At the heart of the struggle for the compliant life cycle management of records with event-based rules is the reliance on an individual or workflow to indicate – and communicate to the appropriate system of record – when the active life of a record is over. This knowledge exists in the business unit or department in which the records are created, received, and managed, putting the responsibility for declaring a trigger event squarely on their shoulders. The Records and Information Management (RIM) team is, in effect, out of the picture.

Event-based rules tend to be manageable for paper records. Providing you have the space, you can keep active records onsite until the event occurs, then pack them up and move them off-site at which time the retention countdown starts.

If you are lucky, you have a records coordinator network to support this activity in the business units. If you store active files offsite with a storage vendor, you can relay the appropriate action to begin the destruction eligibility clock, providing you keep detailed records of what you sent to storage in which carton. But expecting a human to know when the trigger event for electronic content occurs is a formidable, if not nearly impossible, task.

Organizations are anxious to connect Retention Schedule rules to content in electronic systems in order to improve compliance with the policy and gain control over storage costs. Unfortunately, business applications have varying degrees of functionality to retain records according to a retention policy, let alone to track and purge records based on trigger events. While the desire for an enterprise approach to consistently manage records regardless of their format or retention rule is strong, the ability to straddle the gap between intent and practice is weak.

Event-Based Retention Rules: Proven Practice

The following approaches to coming to terms with event-based retention are proven practices adopted by a variety of organizations. In many instances, recommendations were made to the RIM Steering Committee (typically comprised of representatives from IT, Legal, Compliance, Business Units, and RIM) who ultimately made the decision to proceed.

Risk-Based Conversion To "Fixed" Or "Create Date" Rule

Retention rules fall into two general categories: create date (fixed or time-based) and event-based as per the examples below

Create Date:

- Retention begins the date the record is created

Event-Based:

- Retention begins when the record is no longer active

- Retention begins when a triggering event occurs

The calculation of create date retention/destruction for a record can be straightforward within electronic systems providing the “Date of Creation” can be identified and a retention rule associated with the record type. If so, simple math can be applied to determine the date when a record is eligible for destruction.

Taking action on event-based retention periods within applications or repositories is significantly more complicated because of the complexity and variety of triggering events, and an application’s potential limitations. While some applications may have native capabilities that can be enabled to accommodate complex retention rules, there still needs to be a method of communicating the trigger event. This could be as simple as checking a box within an HR application to indicate that an employee is no longer with the organization. However, many applications or repositories cannot be adapted easily or inexpensively to calculate retention after a triggering event occurs – and the challenge prevails in most instances as to how to convey the occurrence of the event.

Event-Based Retention Objectives are:

  • Reduce risk and cost of retaining records indefinitely or inconsistently beyond legal requirements
  • Comply with organizational records and information management policy
  • Comply with privacy laws that require deletion of an individual’s records when no longer required for business purposes
  • Translate complex legal requirements into actionable steps for implementation to electronic systems

The exploration of options and successful enablement of this functionality requires the inclusion of the RIM team in the business requirements, selection, and implementation phases of an application. Fortunately, according to the recent 2014 Cohasset/ARMA/AIIM Information Governance Survey Benchmark report, over 50 percent of RIM practitioners report that they now work closely with their IT counterparts to convey and enact RIM requirements.

To circumvent the inability to connect an event to a record, wherever it may be located, and keeping it forever, the most popular solution to managing event-based rules is to convert them to a create date rule. For example, if an automobile driver’s policy is valid for one year, convert the “keep while active + 6 years” rule to 7 years: this equals the active life of the policy plus the 6 year retention requirement. The expectation that the trigger event can be identified and communicated to an application is removed, allowing for eventual destruction of the record.

This is an approach that must weigh risk, meet compliance requirements, and comply with the objectives of an organization’s overall RIM strategy. A review of an organization’s Records Retention Schedule will reveal certain event-based record classes or series that are habitually involved in litigation or experience a high degree of regulator or customer scrutiny, which can never be converted to a create date rule. But there are others that have a low risk profile and are suitable candidates.

In determining the pre-trigger event life span of a record class, organizations use the typical number of years a record is active or, more conservatively, the longest expected period of time. For example, the average number of years for a consumer to pay off a loan may be 15 years, but an outlier could take 20 years. Other record classes may prove impossible to agree on an amount of active years given the unique nature of the life of a product or insurance policy. Key stakeholders, including business units, have to settle on which number to add to the retention rule to establish the create date rule – and the decision-making process must be documented.

While this method may not be suitable for all organizations, it can accomplish the following if done in a consistent manner:

- Prevent deferring the problem of identifying records for destruction to the next generation(s)

- Provide a logical, yet compliant, solution for enabling records destruction per policy

- Mitigate risk and cost of unnecessary production of records for litigation

- Break the “keep everything” mindset

Getting Started

Decisions for alternative recommendations to convert event-based retention rules into actionable retention periods must be approached carefully, and always with an organization’s risk profile in mind. A thoughtful review of the Records Retention Schedule must be undertaken by all key stakeholders. To do this, the organization may decide to reach out to an external consulting firm to facilitate and uide this process.

For starters, the RIM team will need to discuss the possibility for alternative approaches to event-based rules with the Steering Committee. If the Legal, Compliance, and IT members agree to explore options, the RIM team can then identify the record class candidates and make initial recommendations for conversion to create date rules – or to pass. Supporting information may be derived by analysis of paper record destruction decisions and time lines. The RIM team may then meet with the relevant business units to discuss records life cycle management and agree on a create date rule. The IT department must weigh in on the records management capabilities of the applications that house the affected records. The penultimate step is to return to the Steering Committee to request approval of the requested changes, always providing the justification for making specific decisions. Lastly, changes to the rules must be published and updated wherever required.

Build Connectors to Systems of Records

If a record resides in a system of record other than that in which it was created, build a connector or application programming interface (API) between it and the business application. For example, if a contract is moved into an electronic content management (ECM) system from a contract creation application, create a mechanism by which the conclusion of the contract can be communicated from the application to the ECM. Of course, this still requires a human to “flip the switch.”

Periodic Review of Content

Another approach is to schedule consistent, periodic reviews of records that fall within the event-based classification set.

While not popular or always practical, the default for monitoring records for which a trigger has occurred is by brute force. Business unit personnel will need to keep track of events, such as the termination of an employee, completion of a program or project, closure of a facility, termination of a contract, etc. in order to trawl applications or repositories in which the record is stored. Ideally, this activity can be supported by the use of technology in the form of search terms or more sophisticated methods of identification and classification.

Examples of Triggering Events

Completion or termination of the project Upon final settlement or rejection of a claim
When the policy, program, or procedure is superseded When the annuity is closed or sold
When the customer account is closed When the bankruptcy is settled and all appeals closed
Upon the sale or disposition of the fixed asset Upon the termination of the contract, agreement, permit, or license
When the benefit plan is no longer active and benefits are not payable Upon the expiration of copyright, patent, or trademark
Upon termination of employment Until the product is no longer manufactured or in use
When the job description is obsolete or superseded Until the loan is paid off
When the software application is superseded or no longer in use Until the patient’s date of last visit

Conclusion

The difficulty in managing event-based retention rules is a significant contributor to the fact that 78 percent of organizations cite the biggest challenge to the success of their RIM program is the “keep everything culture.” While alternative solutions are perhaps not ideal, they can provide a practical approach to the very real problem of destruction inaction and consequent non-compliance with policy. Until a better approach becomes available, most likely through enhanced tools, if there is consensus amongst key stakeholders and a commitment to consistent practice, then some progress can be made to better manage the life cycle of a sub-set of the organization’s information assets. Iron Mountain’s Professional Services team can help you take action in meeting the event-based retention challenge


1 - Source: 2013 | 2014 Information Governance Benchmarking Survey.