A Proactive Playbook in a Digital World: Managing Data Preservation In Software-Based Litigation

Given the stakes, it is essential to understand your software systems and to work with outside counsel to prepare a data preservation plan tailored to the case. This involves developing a thorough understanding of software development processes, the flow of data within those systems, and where data is ultimately stored. Adopting a proactive approach at the preservation phase can pay dividends once discovery requests start arriving. During document preservation, you’ll be in a position to minimize the risks of spoliation while preparing a cost-effective plan to preserve discoverable materials. And when discovery requests do come, you’ll have the confidence and familiarity with the scope of discoverable materials to respond to those requests quickly, efficiently, and — most importantly — defensibly.

Of course, a complex digital preservation plan may not be appropriate for the context of your particular anticipated litigation. See here for our discussion of when and how to push back against unreasonably burdensome preservation and collection of dynamic data.

Learning the Building Blocks

At the outset, you’ll need to have a basic understanding of key software development and digital infrastructure terminology. Below are a few concepts worth familiarizing yourself with before delving into developing a data preservation plan:

• Source Code is a set of directions, written in a programming language, that tells a computer what functions to perform. Whether dealing with how a software product operates or how your website interacts with users, the source code will tell much of the story. Source code can be proprietary and privileged, or it can be open-source — allowing for the general public to independently contribute improvements to the product. Be aware that proprietary source code may contain some of your company’s most closely held secrets, and that inadvertent disclosure of that information may expose your company to cybersecurity risks, or assist competitors in developing their products.

• Version Control tracks and manages changes to source code — for example, if you edit a source code file, a version control system would track what changes you made. Source code almost always lives inside a version control system — keeping track of code modifications allows for quick reversion and fixes — such as Git, Subversion, Mercurial, and others.

• Data Storage refers to how files and information are stored within your systems. As a category, this usually refers to data stored as your software is running and performing business functions, rather than the mere storage of source code. This could include storage of customer information (including personally identifiable information) and other business information. Importantly, as data volumes increase, so do storage costs and potential tradeoffs, such as latency in accessing, collecting, or reviewing the various types of data.

• Third-Party Vendors and Infrastructure Providers often manage data collection and storage on behalf of a company. While data can be stored in private cloud or on-premises systems, many companies choose to outsource parts of their digital infrastructure. While these arrangements allow for efficiencies, they can also create concerns over who holds custody over data — and how to preserve and access that data if it becomes relevant in litigation.

Identifying Key People — And Asking the Right Questions

Once you have a basic understanding of these concepts, you need to assist outside counsel in identifying and interviewing key personnel associated with potentially relevant software products and services. These stakeholders are not limited to primary developers or data scientists. Project managers and business analysts can also provide boots-on-the-ground insight on where data comes from, and where it’s going. Further, many sophisticated companies have specific teams dedicated to cybersecurity that may have valuable insights. And if you are fortunate to have eDiscovery, data governance or data privacy professionals, be sure to consult them as well.

When engaging your key digital personnel, make sure to ask the right questions. While each company is unique, we suggest the following considerations:

• The Lifecycle of Software Development: How are new digital features planned, developed, and maintained? What happens to data when a digital feature is “phased out” or otherwise not maintained?

• Data Flows: Where does data originate? Where does it go after it is received by the company? How is it used? Where is it ultimately stored? Is there a plan for data disposal?

• Existing Data Governance and Data Privacy Framework: Does your company have a data privacy protocol in place? Is there an existing data or information governance policy? Is potentially relevant information — such as data that could become the target of a lawsuit — governed by any existing protocols?

• Data Privacy Concerns: With the proliferation of state data privacy laws, and international regulations like the GDPR, your preservation obligations may conflict with other obligations under those regulations. For example, many data privacy laws include a “right to be forgotten,” which requires companies to delete information associated with a person at their request. If the company is subject to these laws, you may need to pause that deletion process, and investigate what additional measures are necessary to notify people who make such requests that they cannot be completely honored in compliance with the relevant privacy laws. If your data preservation and privacy obligations cannot be reconciled, consultation with opposing counsel, or a request for protective relief may be necessary.

Creating and Implementing a Data Preservation Plan

After meeting with outside counsel and your key personnel, your counsel will have the information necessary to assemble a data preservation plan that covers the company’s needs in view of pending or threatened litigation. Below are some essentials that should serve as focal points for your framework:

• Preparing a Data Preservation Inventory: A data preservation inventory is a document that summarizes the results of your interviews with key personnel that identifies where information is stored and why it is or is not potentially relevant. Creating a data preservation inventory assists you in efficiently discussing, deciding, and implementing appropriate preservation strategies for various data stores. Many IT teams may already maintain a listing or “data map” that can serve as your starting point.

• Developing a Specific Preservation Strategy for Each Data Source: Data can be stored in a multitude of formats, including source code version control systems, production databases, blob storage, or others. New ways of storing and processing data are being developed nearly every day. Accordingly, there is no one-size-fits-all approach for preserving data. You will need to design a preservation strategy for each source, which should be noted in the data preservation inventory.
• Collaborating With Your Client’s IT Team: After you create a data inventory and develop a preservation strategy for each data source, work with your IT or eDiscovery team to implement appropriate preservation measures. Work with outside counsel to update or resend preservation hold notices and track both initial acknowledgment of the holds and routine compliance with them over the course of time. A plan does little if it is unadhered to.
• Coordinating With Data Privacy Professionals: If any of the potentially relevant data includes information subject to data privacy laws or data privacy governance programs at your client, coordinate with the appropriate teams to ensure that they are aware of the scope of their preservation obligations, and understand the plan to comply with data privacy laws while also preserving potentially relevant data. If the data preserved may include personally identifiable information that is not directly relevant to the case, it may also be valuable to discuss options for de-identifying or otherwise limiting disclosure of that information in response to discovery requests.

Potential Pitfalls

Every system is different, and the steps outlined above are meant to help you anticipate potential issues that may arise during this process, but below are some common pitfalls to consider:

• Third-Party Vendors: As noted above, third parties used for software development or processing and storing of data will be a complication. Identify the relevant parties early and consider logistical hurdles and contractual rights or limitations to preserving and extracting data. For example, third parties may have their own data disposal protocols that may need to be modified.

• Messaging and Ticketing Systems: Account for software ticketing systems (such as Jira) or business messaging platforms (such as Slack) to facilitate maintenance, fixes, and development.

• “Dark” IT: Employees may be using messaging or other tools that are not approved or maintained on company servers. To the extent that you can, investigate the use of any “unofficial” tools, determine if relevant information has been communicated and how it can be preserved. Consider immediate collections to safeguard any off-server data, and emphasize to the impacted employees not to use the tools and why.

• Protective Orders: Because the preserved information may contain business confidential and trade secret information, producing parties may request protective orders to govern the review of source code – sometimes strictly limiting access to inspection. Consider, for example: NDAs for source code experts, limitations on internet access during the source code review, restricted access for attorneys who also help outside parties acquire patents, or cleanroom-only access to source code (see, for example, the protective order entered in Unwired Planet v. Apple²).

• Data Privacy and Cybersecurity: Discuss whether company software or websites collect or store any personally identifiable information, and assess the impact of privacy laws/regulations. To the extent that additional software is incorporated into your software environment to ensure compliance with a litigation hold, run backups, or perform other functions, ensure that the company’s cybersecurity staff is involved to ensure that such measures do not create unreasonable additional cybersecurity vulnerabilities.

While software discovery may seem daunting, your company will benefit from a vigilant approach if it is ever confronted with a software-related lawsuit.

At Vinson & Elkins, we have extensive experience in cases involving software and digital infrastructure, including patent, privacy, contract, and negligence litigation. We are always happy to discuss how we can support you if you are faced with actual or threatened litigation involving your software and digital infrastructure.

¹In QueTel Corp. v. Abbas, 819 F. App’x 154 (4th Cir. 2020), the Fourth Circuit upheld a District Court’s decision to award judgment as a sanction for a party’s spoliation of evidence. In particular, the QueTel panel noted that the defendants “destroyed the computer used to develop” the software implicated in the lawsuit, “deleted a source code control system” and numerous replacement files on a replacement computer, and “failed to disclose” the destruction of the computer until being confronted about such by the plaintiff’s counsel. Id. at 156. And in Gov’t Emps. Health Ass’n v. Actelion Pharms. Ltd., 343 F.R.D. 474 (D. Md. 2023), a magistrate judge recommended a corrective jury instruction and attorneys’ fees after a party inadvertently destroyed data belonging to a former president of the company at issue. 

²Unwired Planet LLC v. Apple Inc., No. 3:12-CV-00505-RCJ, 2013 WL 1501489 (D. Nev. Apr. 11, 2013).