Starting in January of 2023, businesses subject to California Privacy Rights Act (CPRA) may be required to publish the retention periods for all categories of personal and sensitive information they collect, manage, store, share, or sell.
CPRA Section 1798.100. General Duties of Businesses that Collect Personal Information states that businesses subject to CPRA need to disclose:
The length of time the business intends to retain each category of personal information, including sensitive personal information, or if that is not possible, the criteria used to determine that period provided that a business shall not retain a consumer’s personal information or sensitive personal information for each disclosed purpose for which the personal information was collected for longer than is reasonably necessary for that disclosed purpose.
How can you determine defensible retention periods for corporate applications?
In previous posts, we discussed how firms can define records management retention periods at the enterprise level for corporate records. In this post, we’ll explore how firms can help the resources responsible for retention in business applications, such as technical system owners (TSOs) or business system owners (BSOs), use the corporate records retention schedule (RRS) to determine the specific retention periods for the data in their applications.
While the solution is simple in principle, i.e., compare the data types in the application to the RRS, in practice, it’s more complex.
In the first place, in our experience, most firms have 1.5 to three enterprise applications per full-time employee (and some even more), which means that the average Fortune 1000 firm has thousands (or tens of thousands) of enterprise applications that will need to have retention periods defined for CPRA compliance.
If a records management resource had to meet with each application BSO or TSO to determine retention requirements, that would mean one or more employee working full-time for a year to define retention periods for all enterprise applications. Add to that the time it will take to implement retention periods in each application and this would make hitting January 1, 2023 (or anywhere close) for data retention difficult if not impossible.
So what’s the answer? Automation.
Automating Retention Period Definition
The first step in automating retention period definition for enterprise applications is to identify the full range of legal and compliance obligations on corporate data, which typically include records management, privacy, and legal, as well as more specialized, industry specific, obligations, such as FDA drug development, GLBA, HIPAA, or NERC-CIP.
In more mature organizations, these obligations should be reflected in the existing corporate RRS, as this will include all legal, regulatory, and other obligations for how long an organization must keep its data. If this is the case for your organization, you should use the RRS as the starting point; but if your organization’s RRS is out of date (or if you have no RRS), then you’ll need to update or develop and publish one before you can tackle automating retention period definition.
Starting from an up to date RRS, you need to define the decision tree for retention period definition based on records management, privacy, legal, and other retention obligations on corporate data. Best case, your corporate RRS is organized by functional area and record type. If this is the case, you’ll start by parsing the RRS into categories and sub-categories to guide a “choose your own adventure” drill down to the appropriate retention periods for corporate data. If this isn’t the case, you’ll need to analyze your corporate RRS to determine the best way to bucket it so that BSOs and TSOs can understand the levels of categorization and make selections to arrive at the appropriate retention periods for their data.
Once you have a decision tree for determining retention periods, you need to convert it into an application that can support a records retention portal that BSOs and TSOs can understand and use to generate the retention periods for their application. This decision tree should detail the steps in the retention period definition process, which will typically include defining the business function, the data types, and the geographical jurisdictions in play for each application. With these three defined, and with an up to date RRS, it should be straightforward to determine the retention periods for the data types in each application.
Creating a Retention Period Definition Protocol
From here, you need to transition to developing a protocol for determining retention periods. And while this can be done with something as simple as a standard operating procedure (SOP) to guide BSOs and TSOs to the retention periods for their applications, developing more automated, software-based methods is preferable. And while the specifics of developing such applications will depend on your organization’s distinctive software development practices, there are some common best practices we can present here.
First, annotated wireframes are an important initial step. They will allow you to communicate key functional and non-functional requirements to your IT development team and act as a baseline for evaluating the solution delivered against the requirements requested. And while there are a wide range of approaches to wireframes, at their most basic they should provide an indication of both the UI elements and functionality of the application. They do not need to define the sum total of user-system interactions, as these will be ironed out during the development process.
Second, the wireframes should be focus group tested with end users to discover any issues with UI and functionality. This can be done with a “throwaway” application prototype, a PPT (or even Excel spreadsheets)—but whatever method you choose, the ultimate goal should be that you engage end users with the design you’re proposing in order to ensure that they (1) can understand the interface, (2) can move through the screens with no issues, and (3) have no other issues with the proposed design. The feedback from these focus groups will be a key input in your finalization of the retention period definition portal.
Once the focus groups are complete, a beta solution can be built based on the initial design, updated to reflect the results of the focus groups. This beta solution should be piloted with a sub-section of the end user audience to gather feedback and confirm that the solution will perform as expected during enterprise roll out.
Once the pilots are complete and the results are reflected in the solution, you can roll out the final retention period definition portal. With this done, you can then move to promoting the application so that all BSOs and TSOs are aware and will use it to determine retention periods for their enterprise applications.
A First Step in the Journey
Despite the significant value a retention period definition portal provides to organizations that need to comply with CPRA, don’t forget that this is just the first step of a long and arduous journey—records retention (and disposition according to the RRS) will still need to be actually implemented in all applications in order to enable full CPRA compliance. This is no mean feat and will certainly require a more significant level of effort to achieve, but without the first step of a retention period definition portal, CPRA compliance by January 2023 will be much more time-intensive and unlikely.
© Copyright 2022. The views expressed herein are those of the author(s) and not necessarily the views of Ankura Consulting Group, LLC., its management, its subsidiaries, its affiliates, or its other professionals. Ankura is not a law firm and cannot provide legal advice.
