Write a comment on the follwing post:
De-Identified Data in Saas

Background and Overview

Depending on the extent of your experience with SaaS Agreements you may have come across the concept of “de-identified data” or “anonymized data.” As businesses become more data-driven, SaaS companies are realizing the value of the data they have in their systems. To unlock the value of the data, it needs to be able to be used in benchmarking and analytics. However, this raises concerns about the confidentiality of information and privacy. To sidestep those concerns, SaaS companies de-identify customer data, or in some cases anonymize the data (more on the important distinctions between those two in a bit). However, to do that they first have to have the right to do so in their SaaS Agreements.

SaaS companies wanting to offer data benchmarking and analytics must provide for the right to de-identify customer data in their SaaS Agreement. And, as noted in the previous article on Intellectual Property in SaaS, it is a best practice to establish ownership of de-identified data.

If your SaaS provider client is not doing anything with de-identified today, then this is still worthy of consideration. Because rights to de-identified data is essential to supporting any future data initiatives, it’s never too early to start positioning your client to successfully pursue those initiatives. After all, establishing the right before the actual practice is the only right way to do this.  

Before we look at best practices around addressing this concept in SaaS Agreements, let’s spend some time clarifying the underlying concepts around de-identified data and its cousin that it’s often mistaken for, anonymized data.
De-identified Data

De-identification involves removing (or sometimes altering) personally identifiable information (“PII”) from a dataset so that it is not readily traced back to an individual. The de-identification process typically involves removing obvious identifiers such as names, addresses, and Social Security numbers. However, certain indirect identifiers, like ZIP codes or birth dates, might still be present. In fact, as de-identified data is often used for benchmarking purposes, ZIP codes and birth dates are likely to remain in the dataset (for example, benchmarking “X” by a population of a certain age in a certain ZIP code).

De-identified data may not be readily traced back to an individual, but it might still carry some risk of re-identification if it is combined with other available data sources. This is a critical point to understand and where the discussion around de-identified data gets tricky.

If you agree to provide de-identified data as a SaaS provider, then you need to understand what the receiving party will do with it (as your SaaS customer will want to understand this as well). If you want to ensure against any risk of re-identification, then you can discuss employing certain techniques like k-anonymity and differential privacy to add noise or aggregate data (see embedded links if you want to geek out and go deep on these techniques).

De-identified data should be a defined term in the SaaS Agreement if it’s a relevant concern. Make sure the definition matches the concept. The definition may be cited to an applicable law. For example, in the case of de-identified data that is sourced from protected health information (“PHI”), HIPAA Rules have a proscriptive framework that must be followed for data to be considered de-identified.
Anonymized Data

De-identified data is not the same as anonymized data. Anonymization makes it practically impossible to re-identify individuals within the dataset, even in combination with external data sources.

Anonymization methods might involve generalization, suppression, or data masking to ensure that the data cannot be linked back to specific individuals. When data has been properly anonymized then privacy protection should be ensured.

While both de-identified and anonymized data aim to protect privacy, the key difference lies in the level of protection and the potential for re-identification. De-identified data might still carry some risk, whereas properly anonymized data should have minimal to no risk of re-identification.
Best Practice Example

X. Ownership

X.3         De-Identified Data.  Company shall have the right to access, compile, and aggregate information supplied by Customer, including Customer Data, into De-Identified Data. Company shall own all De-Identified Data.  Company may use or distribute such De-Identified Data for any lawful purpose, including without limitation, analytics, benchmarking and research purposes. 

A. Definitions

A.Y “De-Identified Data” means Information that has been compiled and modified by Company so that it does not include (i) any personally identifiable information of any individual; or (ii) the identity of any company, trade group, or any other entity. 

Addressing de-identified data in the Intellectual Property Ownership section is the best practice because it affords the SaaS company the most rights to the de-identified data. While a perpetual license is not the worst fallback position, in such case make sure it is transferable. But make every effort to get agreement to ownership of the de-identified data by the SaaS Company. The justification for SaaS company ownership is that the customer’s data has been transformed into a new dataset using proprietary methods.

The example definition is a best practice as it clearly states what identifiable information is going to be excluded from the de-identified data. It addresses identifiable information from both the standpoint of individuals and corporate entities. This is best practice in a business-to-business context as there will likely be concerns about privacy issues and proprietary information.
Conclusion

Whether you represent a SaaS company or customer, be certain you understand the differences between anonymized data and de-identified data. If concerns about re-identification are high, then discuss paths to minimize that risk through techniques like k-anonymity and differential privacy. As our world becomes more data-driven, SaaS companies need to be thinking about how they use data in their systems. So, if you represent a SaaS company and don’t currently address de-identified data in your agreement, then it’s time to have a conversation with your internal business partners. If your client envisions using de-identified data one day, legal cannot be the last to know as the terms to permit such activities need to be in place with customers before any such initiatives can get underway.