The 2021 edition of BakerHostetler’s annual Data Security Incident Response Report – a report based on the firm’s experience with data security incident response and litigation over the past year – features a number of important insights previously covered in this blog, including trends in global breach notification, healthcare industry risks and ransomware.
The report is a helpful tool for companies to identify and respond to trends in data privacy and security, especially as they relate to litigation, enforcement and risk management. But while this may not be as obvious, the data privacy and security risk trends identified in the report have also impacted general corporate transactions. Many different types of transactions, from mergers and acquisitions (M&A) to product/service development to standard commercial service agreements, have been impacted by the data privacy and security trends highlighted in the report. In this series, we’ll look at how some of the highlighted trends have had an impact on commercial transactions over the past year, and at some of the key data privacy and security sensitivities for businesses considering or involved in these transactions.
In our first post, we reviewed the impact of these data security trends on M&A. Now we will look at the impact on development agreements.
Data Privacy and Security in Development Agreements
“Development agreements” is admittedly a broad category of commercial agreements. Development agreements can cover everything from websites to medical devices to video games. For the purposes of this analysis, the concept of “development agreements” will primarily focus on the types of agreements where one party (Developer) is helping create, refine or modify something at the request (and typically expense) of another party (Client). But these arrangements can also take the form of joint development, collaboration or strategic alliance agreements in which two unaffiliated entities collaborate on the development of a product or service for later commercialization.
Development agreements are common in the tech fields; however, they are not exclusive to tech and play important roles in the digital transformations of nontech businesses. Data is often front and center in development agreements, as these projects usually require an element of testing and benchmarking, which often involves significant amounts of data. Developers also frequently need access to the Client’s systems to complete development. For example, if you are building a website, the Developer may need to access your systems and hosting environments. If you are developing a new customer relationship management (CRM) or enterprise resource planning application, the Developer may also need access to the customer data that will populate these applications. If you are developing a medical device, data may need to be shared for the purposes of regulatory compliance or clinical testing.
Because of the importance of data and shared network resources in these deals, data ownership and security issues are becoming more prevalent. As detailed below, this is driven, in part, by some of the trends identified in the report.
‘Digital Transformation’ Companies Are Frequent Targets of Cyber Incidents
It goes without saying these days that data security incidents are more than just a “big tech” problem, but the data from the report supports this conclusion. This means that many businesses that do not consider themselves tech companies remain susceptible to these incidents. When businesses utilize outside developers to help with digital transformation, they may be adding an access point and potential attack vector. While this may only be one new access point for the Client, that Developer may be working with hundreds of customers and thus the Client could face a security incident by association without being the intended target (the supply chain issue discussed in the report).
Additionally, in the report we see that incidents occur at businesses of all sizes, even small and midsize businesses, which are often the companies that do not have substantial internal development capabilities and thus are more likely to turn to outside forces for new websites, CRM applications, products and services.
Takeaway: Don’t assume you are not a target because you are not a “tech” company. Companies in non-tech industries that are undergoing digital transformations may be the most susceptible to incidents. When undergoing any development project consider how this project will impact your existing data privacy and security practices. Consider whether a data protection impact assessment would be useful to understand the challenges and opportunities brought on by the new development.
Addressing Data in Contracts with Developers
In our previous post, we addressed the increase in vendor and supply chain breaches. As stated in the report:
Supply-chain attacks have increased sharply over the past decade, and that trend continued in 2020 and early 2021. Supply-chain attacks have obvious appeal to attackers and will keep happening. Organizations need a broader perspective and should assume that all software and devices are vulnerable.
This issue is especially prominent in the development context where a vendor (and possibly a supply chain vendor) may need access to the Client’s systems or sensitive data. Further, developers often work with many clients at the same time and thus may have access and data from many companies, which could make for an attractive target in the supply chain. So what should a Client consider before and while engaging a Developer? The report can give you a starting place:
- Vendor vetting: Given the current cybersecurity landscape, proper diligence in a development agreement is more important than ever. This means both sides should inquire about data creation and use in the scoping phase. On the Client side, if the Developer will have access to your systems or data, you may want to see the Developer’s data privacy and cybersecurity policies before executing the agreement. On the Developer side, you may want to limit the data you access from the Client or prevent the Client from sending you certain data, at least initially, to avoid additional privacy obligations.
- Contractual terms and conditions matter: To ensure a collaborative arrangement, Clients and Developers should consider data ownership, use and security early in the engagement and bake them into the development agreement. Key areas include:
1. Data ownership: Parties to development agreements typically spend a lot of time and text dealing with intellectual property ownership issues but may not be as explicit with respect to the underlying data. Is data included in the definition of “intellectual property” or is it treated separately? It may be helpful to separate the data from the intellectual property and address it on its own. What additional restrictions need to be placed on personal information versus aggregate data?
2. Data privacy and security obligations: Clients and Developers should also take time to consider what privacy and security obligations should apply to the relationship at the onset. Does the nature of the project require the “service provider” provisions from the California Consumer Privacy Act (CCPA) and/or the Article 28 and transfer mechanism requirements from the General Data Protection Regulation (GDPR)? These can be addressed in the master development agreement or in separate data privacy/security addendums, and the actual obligations will vary depending on the nature of the development. However, Clients and Developers should be cautioned against accepting form data privacy and security addendums without reviewing the terms to ensure applicability and compliance.
3. Liability caps and indemnity: The liability caps and indemnification obligations are typically some of the most negotiated aspects of development agreements. As we will discuss in more detail in our next post in this series (service provider agreements), vendors (including Developers) have become increasingly reluctant to provide unlimited liability to protect Clients against harms caused by security incidents, going to great lengths to narrowly tailor the situations under which the vendors will bear risk. On the other hand, Clients have been increasingly reluctant to have a data security incident classified as a regular contract breach and be subject to regular contract damages. The resulting compromise, in many instances, is the “super cap.” The cost information provided in the report can be a helpful metric to argue for the super cap amount.
Takeaway: Choose your development relationships wisely. On the Client side, make sure you are comfortable with your Developer’s privacy and security practices, and make sure that your agreement appropriately addresses issues such as data ownership and liability for data security incidents. On the Developer side, understand what data and networks you will have access to so that you can manage Client expectations on privacy and security and avoid unnecessary liabilities or obligations.
Privacy by Design in the Development Process
As detailed in the report and in our prior post, the privacy and cybersecurity regulatory landscape continues to grow and evolve. Businesses undergoing a digital transformation spurred by tech development may be exposed to new regulatory schemes with which they are not familiar in their core business.
Because of these changes, Clients must consider data privacy and security during the development process, especially in the early design phase. This is where “privacy by design” comes into play. Deloitte defines privacy by design as “a framework based on proactively embedding privacy into the design and operation of IT systems, networked infrastructure, and business practices.”[1] Privacy by design requires addressing privacy in the design and implementation of new products, services and processes. To do this, both the Client and the Developer need to understand the privacy obligations and expectations. Your privacy-by-design process should be specific in order to comply with applicable privacy laws (such as the CCPA and GDPR), but general enough to address foundational privacy principles to ensure that the product can comply with future or changing privacy laws (the California Privacy Rights Act, forthcoming U.S. federal law, etc.). These steps should be well documented in the design and implementation process.
Takeaway: Implement and document a privacy-by-design process for new digital developments.
[1] https://www2.deloitte.com/content/dam/Deloitte/ca/Documents/risk/ca-en-ers-privacy-by-design-brochure.PDF.
