Retention schedules are essential in bringing order to a company’s complicated, chaotic information environment. Whether they succeed in doing so depends largely on whether they are structured properly. So, the age-old question is, what’s the best way to go – organizing the schedule by department/group, or by information content types?
The answer is both, plus an absolutely crucial element that’s missing from the question – the information’s context.
Departmental v. Content-based Retention Schedules
A departmental retention schedule is organized by the company’s major departments or groups and, for each, lists the data types “owned” or used by the particular segment of the company. This approach was appealing in an old-school, “get ‘er done and move on” policy-making world, and that’s why many dusty, legacy records retention schedules we’re asked to update are organized this way. But there are three key failings of the departmental approach:
- Department-based retention schedules tend to be granular and low altitude, with many hundreds of data types listed in total for the company.
- Because each department is addressed individually, there’s a lot of repetition, with common data types appearing multiple times across different departments. This redundancy allows inconsistencies to develop over time between departments, and it also makes updating more challenging due to the risk of loose ends.
- Department-based schedules also are not resilient. Even if they were perfectly accurate when made, sooner or later the company reorganizes, blowing apart the schedule’s fundamental structure.
A content-based retention schedule is organized by the information itself, regardless of which company department “owns” or uses it. Thus, contracts and other common content types appear simply once in the schedule. This brings several benefits. Content-based schedules can be less lengthy, even “big bucket,” which makes them simpler both to navigate and to apply to electronic data storage systems. They are easier to keep internally consistent and to update. And they are resilient, surviving the inevitable shifts of departmental turf.
But content-based retention schedules have a shortcoming. It’s harder for those in a particular department or group to easily see which retention rules address their data. This problem is magnified with a big bucket approach, because many individuals want granular specificity – they have particular data or documents in hand, and they want a list of their department’s data types that makes it easy for them to see exactly what to do with them.
So … do both. Make everybody happy. Have a content-based, big(er) bucket enterprise retention schedule. And at a lower altitude, create departmental/group file plans, which are logical structures for the specific record types “owned” or used by the individual departments. Tie the departmental file plans to the enterprise retention schedule, so that updates and changes can flow easily and reliably up to the retention schedule or down to the file plans. Include more specific information in the file plans, such as the locally-used names of specific record types and the department’s approved storage locations. And use the file plans to establish directory structures and electronic folders for storing unstructured data in drives or ECM systems, which (a) actually accomplishes something concrete, while (b) ensuring consistent compliance with enterprise rules derived from the retention schedule.
In a “flat document” policy world, the retention schedule and file plans are separate documents, kept in sync by cross-references. Better yet, with a “relational data” policy approach, the retention schedule and the file plans are housed and tied together in a database, accessible to users through the company’s intranet. Access rights based on department and role can ensure that the right retention schedule and file plan information is available to any who need it, without the clutter of information they don’t need (or are unauthorized to see). And drill-down capabilities can be used to simplify the user experience and to meet different users’ needs.
But Context is Key
We’re still missing a truly important consideration. Data content, standing alone, does not tell us all we need to know about how long the data must be kept. For example, let’s take a garden-variety commercial contract, the official version of which Company X will retain until expired plus six years. In each of the instances below, the content of the contract document is precisely the same:
- The original hardcopy executed contract: retain until expired plus six years.
- A scanned official electronic version of the original contract: retain the official electronic version until expired plus six years, and dispose of the original paper version as soon as the scanning quality control/quality assurance period has passed (or at least one year after scanning if Company X is a federal contractor subject to the FAR).
- A reference/convenience copy of the contract: dispose of once no longer useful as reference, but no longer than expired plus six years.
- A copy of the contract in the working papers for an internal compliance audit: retain with the other working papers for the applicable retention period for internal audit records, such as until audit completion plus five years.
- The contract under legal hold due to pending or impending litigation: preserve until the legal hold is released, and then, if no other pending legal holds apply, release it to ordinary course of business retention rules, such as under 1. – 4. above.
- Backup versions of the electronic contract versions in 2. – 5. above: keep no longer than the period of time deemed necessary for the backup data to fulfill its disaster recovery restoration purpose, such as a cycle of anywhere from 10 days to two months, as determined in Company X’s backup policy.
Same content, yet because the contexts are different, six different results for how long the content is kept. And this is as it should be. So, when building or using a content-based schedule, don’t forget to contemplate context.