Among the recent whirlwinds around data privacy, the fines and rumors of fines doled out in Europe under the GDPR, the vague mandates insinuated under the California Consumer Privacy Act (CCPA), big news data breaches and near-universal confusion as to what companies can do to comply, there is, at the heart of the matter, a simple and often overlooked fact—no matter the complexity or simplicity of a company’s regulatory environment; the complexity or simplicity of a company’s electronic systems, privacy compliance cannot begin to be met without a functioning retention schedule in place.
Beyond the more obvious attributes and functions of a retention schedule—you cannot protect and manage information that is not properly named, classified and assigned. Legally compliant retention—privacy commissioners in various EU countries have quickly realized that the umbrella mandate of keeping information “no longer than is necessary” (a central tenant of the GDPR) can only be enforced (and conversely satisfy compliance) by defining in numerical terms, a rationally attained retention period that “satisfies” no-longer-than-is-necessary constraints.
In a recent case in Denmark (Supervision of IDdesign’s processing of personal data, Journal number 2018-41-0015), the privacy commissioner audited the company’s IT system to determine the extent to which customer data was being retained, as a first-step in determining the no-longer-than-is-necessary rationale; as a second step the privacy commissioner then demanded to see the company’s records retention policy to determine whether it was being implemented within electronic systems (the privacy commissioner actually performed a detailed analysis of the company’s electronic systems to verify that customer information was indeed being destroyed). Fines were implemented when customer information was found existing in the electronic system beyond the no-longer-than-is-necessary retention period because, 1) no retention schedule was in place, and 2) as a result, records were being retained far too long. And so, IDesign was fined 1.5 million Danish Kroner, about $222,000 U.S.
In the U.S., legislators are also catching on to the need for retention schedules in relation to data protection. Colorado passed a new law in 2018 mandating that all “covered entities” (covered entity is defined as “a person [. . .] that maintains, owns or licenses personal identifying information in the course of the person’s business, vocation, or occupation,”) maintain a retention policy (“develop and maintain written policies on the disposal of personal information”). Likewise, the California Consumer Privacy Act (CCPA) states that the intent of the Legislature is “to further Californians’ right to privacy by giving consumers an effective way to control their personal information…” Central to a retention schedule’s function is the effective way to control information and in order for companies to pass on that control to consumers the company’s house must first be in order, that is, they need to protect and manage information by properly naming, classifying and compliantly retaining it.
Further, privacy laws such as the GDPR, CCPA and South Korea’s Personal Information Protection Act (as one single-country example) require a second-level approach to how information (and by inference a retention schedule) is structured. In order for information to be designated as containing Personally Identifiable Information (PII) it has to meet certain thresholds. These thresholds are defined slightly differently in different jurisdictions but they all point to the same thing, there has to be a combination of attributes or a single attribute that allows for personal identification, i.e., a name and address, a social security number, a name and birth-date, etc. These PII attributes are often best worked out (or assigned) on the document type level instead of the larger category level on a retention schedule.
It is, for example, impossible to determine if a retention schedule category such as Accounts Payable contains PII (though we can assume that it probably does, we cannot know for certain) until we drill down to the document type level (e.g., vendor invoice) and apply the threshold criteria—does the invoice contain one or more of the attributes that would designate it as PII? We need, then, this two-level approach to retention schedules and in turn to information governance. Each level is critical and having such a structure is essential for compliance.
Take the above example, for the vendor invoice we need a retention schedule category for Accounts Payable because we need to assign accounting laws to that category that tell us how long that accounting information need be kept (lets say the retention period for accounting records is 10 years—this is the retention number for many EU countries). We also need to know if there is any PII within that larger category and therefore need a list of more granular document types that can be “mapped” to that category because we can, in this instance, only assign the PII attributes on a document type level.
Why does this matter? Because of the no-longer-than-is-necessary mandate. Without a retention schedule category to which we can assign a legally required retention period we cannot define no-longer-than-is-necessary. Because we have assigned a legal retention period of 10 years to the Accounts Payable category we now know that we have to keep that vendor invoice (whether it has PII or not) for that legally mandated period (10 years). In this instance, no longer than is necessary equals 10 years. Now imagine trying to do all of these calculations without a retention schedule; it is nearly impossible. And even supposing you can do the calculating, without a formal retention schedule, how can you demonstrate your due diligence if the Privacy Commissioner comes knocking, as happened to IDesign, in Denmark? The retention schedule serves as both the compliance tool and the compliance documentation.
If a company wants to keep those Accounts Payable records for longer than 10 years then they would have to come up with a defensible rationale for doing so (these requests for longer retention periods can be submitted to privacy commissioners for approval—which is highly recommended, particularly in relation to keeping customer data), or they can de-identify the information or destroy the select document types that have PII and keep the rest. All in all the answer to these more complex gyrations of PII attribute determinations and no-longer-than-is-necessary rationales is quite simply a retention schedule (with the ability to assign document types to the higher-level categories).
Therefore, instead of freezing with that deer-in-the-headlights look and not taking any action because of the confusing complexity of a slew of privacy laws (and I do not disagree that these laws are often confusing) take the relatively easy step of assuring that your organization has first a retention schedule developed (with the requisite second-level document type capabilities) and second, that that the schedule is uniformly and consistently implemented throughout your organization
John Kain is the Vice President, Consulting Services, Montaña & Associates an Access Company. Mr. Kain has been a leading expert in records management and information governance for over 22 years. He is a respected authority on all aspects of information management and governance, with a deep focus in retention scheduling, policy matters, legal compliance and privacy within the international arena. He co-developed (with John Montaña) LexiTrac™, a state-of-the-art retention schedule management and development software offering that has become the leading tool in the industry. He is an active writer and speaker on many industry topics. His work has been published in Information Management magazine and Information Management Journal, among others. He is a member of ARMA International, the American Health Information Management Association and the Association for Information and Image Management.
