TECHNOLOGY, OUTSOURCING, AND COMMERCIAL TRANSACTIONS
NEWS FOR LAWYERS AND SOURCING PROFESSIONALS

The European General Data Protection Regulation (GDPR) took effect in May 2018, requiring companies that handle or process EU residents’ personal information to conform to practices that seek to more fully protect consumer sensitive information. Companies that fall under this category, known as data controllers, must secure consumer consent or another legally acceptable method of gathering personal information, notify individuals of the personal information that is collected and how it will be used, and limit the collection and maintenance to necessary information for a limited period of time. The individuals whose personal information is gathered also have a right to access the information, limit its use, and withdraw their consent from data controllers for such use.

In this month’s Contract Corner, we are highlighting considerations for drafting an up-to-date privacy policy. In Part 1 of this series, we provided background on the general legal landscape for privacy policies in the United States and general issues that need to be addressed for an up-to-date policy. In this Part 2, we will provide some specific pointers on drafting, updating, and disclosing such policies.

Additional Information to Include

In addition to the list of items that should generally be covered in every privacy policy we provided in Part 1, the following are additional items you may need to set out in your specific privacy policy:

  • Directions for customers to access and update data (e.g., password resets, contact information updates, and mechanisms for unsubscribing)
  • Contact details or other means of reaching persons in your organization that can address user queries or concerns
  • Information regarding notifications when the privacy policy is updated (see below for considerations when reviewing and updating your policy)
  • Mechanisms for users to agree to and accept the terms of the privacy policy, as well as means for users to opt out

Drafting and posting a clear, concise, and accurate privacy policy is one of the most important tasks when creating a company’s website, particularly given today’s legal and regulatory environment. Privacy policy legal requirements are becoming more stringent and shortcomings less tolerated, and consumer sensitivity to privacy concerns are at an all-time high.

Despite these concerns, many companies’ policies are seemingly insufficient. A recent opinion piece published as part of the New York Times’ Privacy Project assessed 150 privacy policies from various companies and found that the vast majority of them were incomprehensible for the average person. At best, these seem to have been “created by lawyers, for lawyers” rather than as a tool for consumers to understand a company’s practices.

In this month’s Contract Corner, we will highlight considerations for drafting an up-to-date privacy policy. Part 1 of this month’s Contract Corner will provide background on the current legal landscape for privacy policies in the United States and general issues that need to be addressed.

Does your website or application collect user data? Does your company sell that user data to other third parties, such as advertisers? Does your company disclose this practice to your users in a privacy policy or terms or use? If you answered yes to these questions, you are most certainly not alone. But is your disclosure sufficient? That is the question a new challenge is poised to answer.

As 2018 comes to a close, we have once again compiled all the links to our Contract Corner blog posts, a regular feature of Tech & Sourcing @ Morgan Lewis. In these posts, members of our global technology, outsourcing, and commercial transactions practice highlight particular contract provisions, review the issues, and propose negotiating and drafting tips. If you don’t see a topic you are interested in below, please let us know, and we may feature it in a future Contract Corner.

In Part 1 of this series, we provided an overview of data (or knowledge) commons and some key issues to consider, but how does one actually create and manage a data commons? To find your feet in this budding field, build on the theoretical foundation; address the specific context (including perceived objectives and constraints); deal with the thorny issues (including control and change); establish a core set of principles and rules; and, perhaps most importantly, plan for and enable change.

Although the EU’s General Data Protection Regulation (GDPR) has been in force for more than six months, many organizations are still getting to grips with some of the practical requirements, including ensuring that their contracts comply with Article 28, which mandates a number of key clauses if personal data is being processed under the service agreement.

With potentially hundreds of in-scope contracts, customers and suppliers alike have developed standard-form data processing addendums (DPAs) or similar contract documents in order to address these Article 28 requirements. DPAs are fast becoming the preferred approach for both new agreements and existing contracts.

You may have heard of the “tragedy of the commons,” where a resource is depleted through collective action, but knowledge is different from other resources—knowledge can be duplicated, aggregated, integrated, analyzed, stored, shared, and disseminated in countless ways. Given that knowledge is a critical resource for seemingly intractable problems, the opportunity of the commons (or the tragedy of the lack of commons) is worth thoughtful consideration.

Imagine that you or a loved one is suffering from a terminal or debilitating disease and that data and knowledge are out there, waiting to be combined and harnessed for a cure or a transformational treatment. Imagine that self-interest (including attribution), legal restrictions (including intellectual property protections), inertia, complexity and difficulty of collective action, and other weighty forces are between you and that breakthrough discovery. Though not a new concept, commons have been garnering attention lately as an alternative framework for catalyzing groundbreaking research and development, particularly when relevant data and knowledge are scattered and particularly in the life sciences community. But before we all throw away our patents and data-dump our trade secrets, there are some thorny aspects to governing a data (or knowledge) commons. For example:

  • A commons is essentially its own society. Anyone who has been part of a homeowners’ association knows that collective governance is almost always muddy. Aligning incentives, objectives, and values can be challenging.
  • Founders may have trouble relinquishing control or enabling change. Participants may become confused or upset if rules or priorities change.
  • Commons are not as well understood and tested. They must coexist with, and within, other systems that may be more rigid and rules-based. Participants may be logistically, intellectually, and otherwise tied to traditional methods and may prefer semi-exclusive zones rather than open collaboration.
  • It may be difficult to measure the effectiveness or value of commons.
  • Policing activities (e.g., authentications or restrictions) may be burdensome. And once the cat is out of the bag, it’s difficult to undo uses or disclosures.
  • Commons managers may not be willing to take on certain responsibilities or liabilities that would make participants more comfortable.
  • Different types of information and tools have different levels of sensitivity and protection. Certain information, like personal data, is highly regulated.

Scholars have taken theoretical frameworks built for natural resources and adapted them to the data commons setting. Key findings include that data commons must be designed to evolve and that communities with high levels of shared trust and values are most likely to succeed. Whereas governance through exclusivity (e.g., patents) is useful when trust levels are low, a resource sharing governance model (e.g., commons) can be effective when trust levels are high.

If you’d like to know more:

  • We will be hosting a webinar with one of the aforementioned scholars—Professor Michael J. Madison, faculty director at PittLaw—on Tuesday, December 18, 2018, from 12:00 pm to 1:00 pm ET. Register and join us for the discussion.
  • In a subsequent post, we will provide some tips and considerations with respect to drafting policies, standard terms, data contribution agreements, and other governing documents for data commons.

Knowledge sharing has long been an important element of academic research. And now collective sharing and governance of data assets throughout the scientific community, including for-profit participants, is gaining momentum. During their webinar, Out in the Open: The Knowledge Commons Framework, Emily Lowe, Ben Klaber, and Professor Michael J. Madison, faculty director at PittLaw, will discuss issues related to knowledge commons. Topics will include the following:

  • A fundamental overview of knowledge commons, including the framework’s strengths and weaknesses
  • Standard requirements regarding data contribution, access, use, sharing, protection, and attribution
  • How to decide if a knowledge commons framework is right for your business, and if so, how to implement it successfully

Drafting and negotiating the data protection provisions in services agreements can be one of the trickier and more time-consuming aspects of the contracting process. One of our prior Contract Corner series from 2014 discussed the importance of documenting security requirements and monitoring security commitments, addressing security incidents, and key issues to consider when drafting liability provisions. In this Contract Corner, we revisit some of these issues based on the latest contracting trends that we are seeing for services agreements and dive into additional considerations when addressing key data safeguard provisions.

Assess and Define the Data

At the outset of the contracting process, it is important for the deal team and the key stakeholders to evaluate and properly define the types of data that the service provider will access or process as part of the services. A sound understanding of the scope of data involved in a services transaction helps establish expectations up front and will drive a contract that contains the right level of security requirements and an appropriate allocation of liability for security breaches. The contract should then reflect the output of this internal assessment through carefully crafted defined terms that will flow throughout the data safeguard provisions.