Is China’s Personal Information Protection Law Contributing to the Global Supply Chain Snafu?

Less than a month after China’s Personal Information Protection Law (PIPL) took effect, ships in Chinese waters began disappearing from industry tracking systems.

While the PIPL governs the collection and cross-border transfer of personal information, which is broadly defined as information related to an identified or identifiable natural person that is recorded electronically or by other means, there is no reference to shipping data within the provisions of the PIPL, nor is shipping data included in the definition of personal information. Nevertheless, some domestic providers in China have reportedly ceased providing information to foreign companies, ostensibly because of the PIPL.

Continue Reading

Are More European Standard Contractual Clauses Coming?

On November 18, 2021, the European Data Protection Board (EDPB) adopted its new draft guidance on the interplay between Article 3 of the European Union’s General Data Protection Regulation (GDPR) and Chapter V of the same law. This new guidance specifies that personal data processing by organizations in countries outside the European Economic Area (EEA) is governed by the transfer restrictions of Chapter V, even when the organization is subject to the GDPR through the law’s extraterritorial applicability. But the EDPB unhelpfully leaves open the question of how to comply with Chapter V in such circumstances, acknowledging that the required transfer tools are currently “only available in theory.”

Article 3 lays out the GDPR’s territorial scope, including extraterritorial provisions that bring organizations not established in the EEA within the GDPR’s scope when they offer goods and services to or monitor the behavior of individuals in the EEA. Meanwhile, Chapter V (Articles 44-50) restricts transfers of personal data to countries outside the EEA unless appropriate transfer tools, also identified in Chapter V, are used to ensure that the personal data transfer does not undermine the level of protection guaranteed by the GDPR.

Continue Reading

China Issues Draft Measures on Security Assessment of Cross-Border Data Transfer

On Oct. 29, 2021, the Cyberspace Administration of China (CAC) published the “Draft Measures on Security Assessment of Cross-Border Data Transfer” (Draft Measures) for comment through Nov. 28. The Draft Measures follow and are based on China’s Cybersecurity Law (CSL), Data Security Law (DSL), Personal Information Protection Law (PIPL) and related regulations. These measures appear intended to replace those previously published by the CAC and, once promulgated, will give effect to key requirements in the PIPL that came into effect on Nov. 1.

Security Assessments

If made final, the Draft Measures will require data processors to conduct a security assessment before conducting any cross-border transfers of “important data” and personal information collected and produced in China. While not explicitly defined in the CSL or DSL, the draft Data Security Management Measures published on May 28, 2019 and the recent draft Information Security Technology – Guidelines on Identification of Important Data have defined “important data” as data that, if disclosed, may affect national security, economic security, social stability or public health, safety and interest, such as undisclosed government information, information relating to large-scale population, population genetics and health, geography and mineral resources.

Continue Reading

California Privacy Protection Agency Board Chair Discusses CPRA Rulemaking Process and Agency Authority

Justin T. Yedor and Jeewon Serrato

On October 5, 2021, Jennifer Urban, who serves as Chair of the Board the California Privacy Protection Agency (the CPPA) spoke with members of the California Lawyer’s Association about the Board’s work to get the new Agency off the ground, the challenges it faces in doing so and the regulations to be issued under the California Privacy Rights Act (the CPRA). This occasion marked the first time Chair Urban addressed a public audience since her appointment earlier this year to lead the CPPA Board. While Chair Urban spoke at the event as a private citizen and not on behalf of the Board or the Agency, her remarks provided a useful recap of where things stand with the CPPA and what to expect over the coming months.

Chair Urban’s answers to the questions raised during the event provided a succinct summary of the topics discussed at the Board’s September 7 meeting, and she noted her enthusiasm about the selection of Ashkan Soltani as the CPPA’s first Executive Director. Our coverage of the September 7 meeting and the CPPA’s Invitation for Preliminary Comments on Proposed Rulemaking is available here.

Continue Reading

FTC Puts 700+ Companies on Notice to Expect to Pay Penalties for Any Endorsement Violations

By: Linda Goldstein, Amy Mudge, Randy Shaheen, Jack Ferry and Matt Renick

The Federal Trade Commission (FTC or Commission) announced on Oct. 13 a widespread enforcement action against deceptive endorsement practices. The Commission sent a Notice of Penalty Offenses to more than 700 companies, notifying them that conduct related to fake or misleading endorsements and reviews could subject them to significant civil penalties. Deceptive reviews and endorsements have been a focus of recent FTC cases and guidance, but these letters reflect its largest action to date and serve as a warning to industry that the Commission intends to actively enforce this area of the law.

The FTC notes in the press release and template letter that its Endorsement Guides and recent enforcement actions in this space best illustrate violations of the law. It cites the following examples of misleading conduct:

Falsely claiming an endorsement by a third party; misrepresenting whether an endorser is an actual, current, or recent user; using an endorsement to make deceptive performance claims; failing to disclose an unexpected material connection with an endorser; and misrepresenting that the experience of endorsers represents consumers’ typical or ordinary experience.

When the FTC refers to an “endorser,” it defines that term as anyone with a material connection to the company. Typically, this means a person who is paid, but it could also mean a person who is sent a free product or receives some other form of compensation. Companies should review their marketing materials to make sure that their endorsers are not making any deceptive claims. If you cannot make a claim in your own advertising, then you cannot pay or otherwise compensate someone to make it for you. This includes third-party endorsers who are incorporated into traditional advertising such as a commercial, as well as influencers who are compensated to post about a product or service on social media.

It’s also important to note that the FTC specifically mentions reviews, which can be a kind of endorsement if there is a material connection between the reviewer and the company. The FTC has previously taken enforcement action against fake reviews. This affects more than companies fraudulently posting fake reviews, however, because if a company compensates a reviewer, for example, by offering a small gift to everyone who posts a review, technically, it must disclose that material connection.

As a reminder, the FTC usually enforces this type of conduct through Section 5 of the FTC Act, which broadly prohibits deceptive practices in advertising. The FTC’s ability to obtain equitable relief under Section 5 was stymied by a recent Supreme Court ruling, as explained in our previous blog post on the subject. Here, the Commission is working around that limitation by sending notice letters of conduct that has been found unlawful in previous FTC administrative orders. This gives companies the actual knowledge required to create liability under 15 U.S.C. § 45(m)(1)(B) that an act or practice is unlawful. The civil penalty is up to $43,973 per violation.

Notably, the FTC expressly states both in the list of companies receiving a letter and in the sample letter template that “FTC staff is not singling out your company or suggesting that you have engaged in deceptive or unfair conduct.” Instead, the Commission sent these letters to the largest companies in different areas. This gives it the ability to take action against these companies under 15 U.S.C. § 45(m)(1)(B) and also notifies the marketplace at large that these practices will not be tolerated.

Whether or not they received a letter, companies should be reviewing how they treat endorsements and reviews. We advise clients on these issues every day. If you have any questions about best practices in these areas, please reach out.

The Impact of Data Security Incident Trends on Commercial Transactions: Part II – Development Agreements

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:

  1. 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.
  2. 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:
    • 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?
    • 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.
    • 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.

8 Key Takeaways for Initial Defenses Under the CCPA and CPRA

Authors: Marshall Mattera, Jeewon Serrato, Casie Collignon and Stanton Burke

Since the Jan. 1, 2020 kickoff for private enforcement under the California Consumer Privacy Act (CCPA), plaintiffs have filed scores of class actions invoking the CCPA. Such claims, when properly made, present substantial risk to companies including statutory damages up to $750 per consumer. Early key takeaways can help companies limit risk under the CCPA and the anticipated California Privacy Rights Act (CPRA), largely not operative until Jan. 1, 2023.

Takeaway 1: Plaintiffs May Not Sue for Non-Actionable Security Incidents

The CCPA permits private lawsuits based on certain security incidents. As one court dismissing a claim has stated, “to succeed on a CCPA claim, a plaintiff must allege that his personal information was subject to unauthorized . . . disclosure as a result of a business’s failure to implement and maintain reasonable security procedures and practices.”  Disclosures that are authorized by terms and conditions, or not caused by a failure to provide reasonable security, may not be actionable.

CPRA Perspective: The CPRA keeps the limitations on actionable security incidents.

Continue Reading

New Director of HHS Office for Civil Rights Announced: What could Lisa J. Pino’s appointment mean for future HIPAA enforcement?

More than eight months into the Biden administration, the U.S. Department of Health & Human Services (HHS) announced the appointment of Lisa J. Pino as the new director of the Office for Civil Rights (OCR) on Sept. 27, 2021.

As the new director of the OCR, Pino will be responsible for enforcing the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and supporting the Biden administration’s agenda for the OCR. As we have seen with previous directors, including Severino and Samuels, an appointee’s background can give us insight into what the focus of their enforcement actions and areas of importance might be and, importantly, what HIPAA-covered entities and business associates should be paying closer attention to. Continue Reading

Effective Oct. 1, 2021: Connecticut Expands Data Breach Notification Statute

On June 16, 2021, the Connecticut General Assembly adopted an expanded version of Connecticut’s data breach notification statute (2021 CT H.B. 5310 (NS)). Through this expansion, Connecticut’s data breach notification statute will be updated, effective Oct. 1, 2021, to (1) broaden the definition of “personal information,” (2) shorten the amount of time within which businesses must notify Connecticut residents and the Office of the Attorney General of a data breach, (3) allow for email notice when login credentials are breached, (4) remove the requirement for law enforcement consultation when conducting a risk assessment, and (5) include a HIPAA/HITECH exemption.

What is most notable about Connecticut’s revised data breach notification statute is the omission of a particular provision from the final version of the statute. When the statute was originally introduced to the Connecticut legislature on Jan. 22, 2021, it included an unprecedented provision that would have required entities that suffered data breaches to provide “preliminary substitute notice” of the data breach if the entity was unable to identify and notify affected Connecticut residents within 60 days after the discovery of the incident. The preliminary substitute notice would have consisted of (1) email notice to all affected Connecticut residents whose email addresses were known to the entity; (2) conspicuous posting of the notice on the entity’s website; and (3) notification to major statewide media, including newspapers, radio and television. Even after providing “preliminary substitute notice” of an incident, the entity that suffered the breach would have had to then provide direct notice of the incident to affected Connecticut residents. The final version of the statute, however, does not include this preliminary substitute notice obligation.

Continue Reading

CPRA Rulemaking Begins with an Invitation by the New California Privacy Protection Agency

By Justin Yedor, Stanton Burke, and Jeewon K. Serrato

For businesses awaiting guidance on how to comply with the California Privacy Rights Act (the “CPRA”), the new California Privacy Protection Agency (“CPPA”) began the rulemaking process on September 22, 2021 with an Invitation for Preliminary Comments on Proposed Rulemaking (the “Invitation for Comment”).  In the Invitation for Comment, the CPPA specifically highlights eight areas in which the Agency is particularly interested in receiving comments, though it welcomes comments in any other area subject to regulation under the CPRA.  The Agency also published Tips for Submitting Effective Comments to help guide the process.  The deadline to submit comments is November 8, 2021.  Read below for practical takeaways on the CPRA rulemaking process and why businesses may want to participate.

The CPPA’s Plan for Promulgating Regulations

The CPRA established the CPPA as a first-of-its-kind administrative agency solely dedicated to protecting the privacy of Californians’ personal information.  The CPPA is charged with enforcing the CPRA as well as issuing regulations interpreting the statute.  The CPRA specifically lists 22 topics to be addressed by the regulations.  As we saw with the California Consumer Privacy Act (the “CCPA”), the contents of these regulations can be crucial in understanding how to comply with the law.  With the CPRA going into effect on January 1, 2023, businesses now have 15 months to complete the compliance program for the CPRA.

Continue Reading

LexBlog