Comparative Analysis of Privacy Issues under US, EU (DPD / GDPR), Canada, Japan and PCI DSS Legal Fr
A few years ago, Privacy issues were a rare occurrence in business transactions. In commercial agreements, the main concerns typically centered around the scope of licenses and IP ownership, indemnification framework, and liability limitations. In M&A deals, IPO underwritings and investments, Privacy issues usually arose as a warranty prong and rarely was there any actual diligence from the acquirer or investors to explore the activities behind the warranty.
Over the past few years, however, Privacy issues have emerged as a major issue in many commercial agreements, and are now a more serious diligence task in acquisitions, IPO underwritings and equity rounds, although the analysis is often still not calibrated to the technology and business model of the target.
In the last few years, I have seen many SMBs seeking to negotiate data clauses, not necessarily because they understood the real Privacy issues behind their concerns, but often because they knew enough about PCI compliance and about the value of their consumer data to worry about data misuse or unauthorized monetization. On the enterprise side, I have seen some of the largest CPGs, entertainment companies and content producers, global gasoline and commodity conglomerates, and large scale US and international retail operators and franchisors focus on data Privacy at least as much as they focused on IP infringement indemnification. It is now common for sophisticated enterprises to engage in detailed diligence with their technology vendors about data security procedures, data retention, and the subcontractors that may be handling personal data, rather than just accepting a contractual assurance or warranty, which is something that almost never happens with respect to IP indemnification and infringement risks.
While the level of sophistication in negotiations involving Privacy has increased in both US and international transactions, there are still pervasive misunderstandings of what Privacy laws require and of the equitable balance of risks and benefits between B2C companies and their vendors, particularly in engagements involving SAAS or transactional pricing models. I also see companies developing web or mobile platforms that are struggling to understand what exactly they should do about Privacy in the US, EU and APAC, what type of consents they should seek from consumers, and how they could use consumer data for analytics and behavioral profiling.
This article seeks to achieve two main goals:
A. Share a few perspectives that may be of interest to companies that handle consumer-level data in the US, EU, Canada and Japan, and particularly to companies involved in the Payments space, companies operating in the data analytics or data monetization segments, B2C companies operating online or mobile platforms with significant end consumer interactions, and technology vendors that handle consumer data on behalf of B2C companies;
and
B. Provide an international comparative analysis of some of the most important issues that arise in the area of Privacy across the US, EU (considering both the current Data Privacy Directive (DPD) and the upcoming General Data Protection Regulation (GDPR) framework), Canada and Japan, together with some consideration of international regulatory frameworks such as the PCI DSS standards.
I hope this helps you better focus your resources on Privacy issues as you develop your business models and technologies. I also hope that some of this information gives you the confidence to negotiate your commercial transactions and acquisitions/investment deals without missing issues, and without over-negotiating issues that have simple solutions. Best of luck!
A. Thoughts about Current and Emerging Issues in the Privacy Space:
1. Many organizations with activities in the EU are currently investing significant efforts to achieve GDPR compliance, partially motivated by the fear of significant financial penalties that are codified within the GDPR legislation (see, e.g., Article 83 of GDPR, which establishes fines against both data processors and data controllers in certain circumstances of up to 20M EUR or 4% of global gross trailing revenue). While the need to achieve GDPR compliance is certainly valid, the reality is that in the context of existing international Privacy legislation, GDPR could be construed as more of an evolutionary step rather than a revolutionary framework, and some of the urgency perpetuated by the media and by companies involved in GDPR compliance management may be overstated. As you review the comparative table below, note for example that the data security standards established under various US laws are at least as specific and demanding as those defined by GDPR. Compare also California’s “Shine the Light” law on consumer right to view data defined by Section 1798.83 of the California Civil Code with the data disclosure requirements established by GDPR and you will notice that GDPR and California compliance requirements are not too far from each other. And while data anonymization guidelines issued by the EU remain an excellent guideline for any company involved in data analytics and big data processing, some of the anonymization guidelines issued by US legislation (e.g., see the de-identification guidelines in HIPAA) and the guidelines in the Anonymously Processed Information Report issued by the Personal Information Protection Commission Secretariat of Japan on February 2017 are similar and equivalent in scope. So the global trends on Privacy are clearly towards convergence, even though the countries themselves may not be directly coordinating activities, and compliance with any particular framework should become easier over time for companies with international operations.
StartFragment2. One issue that may arise in negotiations between sophisticated commercial entities relates to the allocation of risks, costs and responsibilities to handle consumer disclosures in the event of a personal data breach. A complication is that breach notification obligations arise for both Governmental and commercial entities even before the occurrence of a breach has been confirmed. See for example Section 1798.82 of the California Civil Code: “A person or business that conducts business in California, and that owns or licenses computerized data that includes personal information, shall disclose a breach of the security of the system following discovery or notification of the breach in the security of the data to a resident of California (1) whose unencrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person, or, (2) whose encrypted personal information was, or is reasonably believed to have been, acquired by an unauthorized person and the encryption key or security credential was, or is reasonably believed to have been, acquired by an unauthorized person and the person or business that owns or licenses the encrypted information has a reasonable belief that the encryption key or security credential could render that personal information readable or useable.” EndFragment
This means that in a contract between a B2C company and a vendor that is handling data in the background for the company, the company may want to impose obligations on the vendor to react to data breaches preemptively, even before a breach has been affirmatively confirmed.Among others, the company may ask the vendor to handle disclosures to end consumers, a process that could be both very expensive and logistically complicated.The vendor, however, may be justified in pushing back on such requests, particularly in a commercial engagement that uses a SAAS or transactional pricing model, where the B2C company may be realizing significantly higher economic returns from the relationship compared to the vendor.
Needless to say, for a vendor, an obligation to investigate and react to a breach that has not even been confirmed would be highly concerning. What if the breach turns out to not have been real and the reputational damage to the vendor is irreversible or material?What if the breach involved a small number of end consumers and is easily remediable, but the wide scale notification is later found to have been unnecessarily broad and expensive, and even worse, what if a broad disclosure facilitated additional security attacks and breaches?
When negotiating the liability and indemnification framework for an agreement between a B2C company and one of the company’s data vendors, how should liability and costs be allocated between the parties? What if the vendor caused the breach and the response was not prompt enough, or the disclosure was not broad enough? What if the B2C company reacts preemptively to an event that causes the company to “reasonably believe” that a data breach has occurred, causes its vendor to incur significant financial or reputational costs issuing consumer and public notifications for that event, and then the event is retroactively found to not have been an actual breach, or the breach is found to have been immaterial or easily remediable? Issues of indemnification and cross indemnification can certainly become complex and may not be easy to negotiate.Additionally, the relative ROI analysis in SAAS and transactional pricing engagements further complicates the allocation of risk and liability between B2C companies and their technology vendors.
An additional complication for data vendors is that in addition to contractual negotiations with their B2C customers, the vendors are also subject to direct and parallel legal requirements. See for example paragraph (b) of Section 1798.82 of the California Civil Code: “A person or business that maintains computerized data that includes personal information that the person or business does not own shall notify the owner or licensee of the information of the breach of the security of the data immediately following discovery, if the personal information was, or is reasonably believed to have been, acquired by an unauthorized person.” Not only does the vendor have to navigate complex negotiations with its customers, but in the end, the vendor also has to directly manage the legal requirements placed by law.This complication is particularly concerning for data vendors that receive personal data from multiple merchants.If a breach has occurred, which customer provided the respective consumer data?Was the affected data augmented with additional data, and if so, how does the vendor identify all of the companies that provided that data and notify them promptly?
3. It is interesting to note that California law does not affirmatively require a company to respond to a consumer’s inquiry regarding the company’s use of the consumer’s information.California Civil Code § 1798.83 requires the company to respond to a consumer request with respect to the company’s sharing of data with third parties.In 2008, the California Office of Privacy Protection issued a set of Recommended Practices on California Information-Sharing Disclosures and Privacy Policy Statements, in which it made the following recommendation for the introduction of a consumer disclosure law that specifically requires companies to “… Respond to a customer’s request for an Information-Sharing Disclosure as soon as possible after receiving it, but no later than within 30 days for a request made to the contact point designated in the Notice of Information-Sharing Disclosure.” Nevertheless, companies that operate in California and have the ability to respond to consumer requests may still choose to respond following a process similar to that required by GDPR.In general, given the global trends towards convergence of Privacy laws, developing the ability to segregate and track individual consumer profiles is certainly advisable for companies handling personal data for online and mobile platforms even if they don’t find themselves subject to GDPR.
StartFragment4. It is generally accepted that once data is properly anonymized, it can be used with essentially no limitations under all privacy frameworks, including GDPR. It is surprising, however, to notice that GDPR may contemplate the use of personal data outside the scope of the consumer consent and without being fully anonymized under certain circumstances: “Where the processing for a purpose other than that for which the personal data have been collected is not based on the data subject's consent …, the controller shall, in order to ascertain whether processing for another purpose is compatible with the purpose for which the personal data are initially collected, take into account, inter alia: (a) any link between the purposes for which the personal data have been collected and the purposes of the intended further processing; (b) the context in which the personal data have been collected, in particular regarding the relationship between data subjects and the controller; (c) the nature of the personal data, in particular whether special categories of personal data are processed, pursuant to Article 9, or whether personal data related to criminal convictions and offences are processed, pursuant to Article 10; (d) the possible consequences of the intended further processing for data subjects; (e) the existence of appropriate safeguards, which may include encryption or pseudonymisation.” (See GDPR Article 6.4). Similar concepts also exist under the DPD (see Article 6.1(b)) and under Canadian law (see PIPEDA, Division 1, Section 7(2)(c)).
StartFragment
5. GDPR may generate ongoing logistical complications for commercial entities, and possibly also a wave of nuisance litigation.
See for example Article 15, which requires a data processor to disclose to a consumer upon request “ where the personal data are not collected from the data subject, any available information as to their source.” This means that a company involved in data analytics that receives information from multiple sources and aggregates it could be subjected to open-ended requests about the data sources, from multiple consumers, on an ongoing basis. Similar concepts also exist under US laws and other countries’ laws. We plan to explore this issue in more detail in the future.
Note also the provisions of Article 18 of GDPR, under which a consumer has the right to “obtain from the controller restriction of processing where … the accuracy of the personal data is contested by the data subject, for a period enabling the controller to verify the accuracy of the personal data.” Note also Article 19, under which a controller must “communicate any rectification or erasure of personal data or restriction of processing … to each recipient to whom the personal data have been disclosed, unless this proves impossible or involves disproportionate effort. The controller shall inform the data subject about those recipients if the data subject requests it.”
If a consumer makes repeated requests that could constitute a harassment of the data controller, the controller may assess “a reasonable fee based on administrative costs.” This may provide a mechanism for companies to discourage nuisance inquiries from consumers. Similar concepts exist under other country laws (e.g., Japan).
EndFragment
StartFragment
6. GDPR requires data processors to respond to consumer requests within 30 days and must provide “a copy of the personal data undergoing processing.”
One question that arises is to what extent should the data controller engage in diligence and identify verification for the consumer? What if the request is an attempt to steal the identity of a consumer? And if the consumer identification process takes some time, what if the data controller misses the 30-day deadline while still acting in good faith?
7. Article 28 of GDPR establishes a number of specific requirements that are directly applicable to companies acting as data vendors for EU companies.
StartFragment
For example, Article 28.2 provides that “The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes.” In commercial negotiations, the customer/data controller will typically ask for the right to approve each subcontractor, individually. This is not a good solution because although it may appear to be a good position for the controller, neither the controller nor the processor want a logistically intensive relationship where the vendor continuously sends a stream of subcontractor names and the controller has to respond to that. Which subcontractors working for the data vendor should be flagged and sent to the data controller for approval? How about an external developer who is writing an interface and/or licensing an API to transmit data between the vendor’s internal systems? How about a consultant company with a team of 2+ people who are temporarily engaged to develop some analytics or do some data cleanup on the dataset provided by the controller? Should Google or Microsoft be disclosed as vendors if the data processor’s email system is hosted by one of those cloud services?
A better solution may be to reach an agreement between the data controller and data vendor under which classes of permitted subcontracting entities are identified and authorized in advance, with at least one example of subcontractors in each class, and with the data vendor committing to notify the data controller if any material changes occur. Another solution may be for the vendor to maintain a database of subcontractors online, which the data controller can access at any time, with the understanding that the data vendor will make (commercially) reasonable efforts to maintain the accuracy of that list.
In any event, the data vendor must be prepared to accurately identify upon request the actual subcontractors that qualify as data processors for any particular controller given that various requirements under US, EU, Canadian and other laws mandate the ability to identify those subcontracting vendors specifically in some circumstances.
Also note that Article 28 Sections 3-9 of GDPR identifies a number of specific issues that must be addressed in a commercial contract between a data processor and a data controller, such as the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects, and the obligations and rights of the controller. The data vendor and the data processor will typically develop their own template agreements seeking to address in advance these issues. In most cases, negotiations around these topics should not be overly difficult given the specificity of the GDPR requirements, and given that GDPR has jurisdiction over both data controllers and data processors.
Finally, note that under Article 28.10 of GDPR, a data processor that exceeds the scope of activities agreed upon with the controller, such that the data processor can be construed to determine on its own “the purposes and means of processing” the personal data received from the controller, will be construed to be a data controller itself.
B. International Comparative Analysis of Select Privacy Issues:
The table below provides a comparative analysis of the following Privacy issues under US, EU-DPD, EU-GDPR, Canadian, Japanese and International legal frameworks:
A. Applicable Privacy Legislation Framework
B. Data Security
C. Mandatory Privacy Policies
D. Management of Data
E. Consumer Right to View Data
F. Consumer Right to Delete Data ("Right to Be Forgotten")
G. Breach Notification
H. Consumer Consents, and Opt-in v. Opt-out Frameworks
I. Data Processor v. Data Controller Issues
J. Data Retention
K. Automated Decision Making based on Personal Data
L. Anonymization of Data
M. Privacy Law Enforcement
N. Treaties and International Data Flow
Notes:
1. Legal and regulatory framework for Privacy in the US:
Federal Laws (e.g., 4th Amendment of the US Constitution (protection against unreasonable searches and seizures), 14th Amendment of the US Constitution (Due Process Clause interpreted by the Supreme Court to provide a fundamental right to privacy), Privacy Act of 1974, Fair Credit Reporting Act of 1970 (FCRA), Electronic Communications Privacy Act of 1986 (ECPA), Gramm-Leach-Bliley Act of 1999 (GLBA), Right to Financial Privacy Act of 1978(26), Federal Trade Commission Act (15 U.S.C. §§41-58) (prohibits unfair or deceptive practices, addresses offline and online privacy and data security policies), Children's Online Privacy Protection Act of 1998 (COPPA), Health Insurance Portability and Accountability Act of 1996 (HIPAA), Freedom of Information Act of 1966 (FOIA), FCRA (credit reporting), the Financial Modernization Act of 1999 (GLBA)(27) (financial sector), the Cable Communications Policy Act of 1984, the Videotape Privacy Protection Act of 1988, Telephone Consumer Protection Act of 1991, Telecommunications Act of 1996)
State laws (e.g., California - Article 1, Section 1 of the California Constitution (“CA SB 1386 (implements consumer remedy for breaches involving personal data and establishes breach notification obligations for personal information holders), New York - NY Civ Rights L § 50 and 51 (2014) (establishes a violation of consumer privacy using name, portrait or picture as a misdemeanor and implements a civil remedy for consumers), New York - 23 NYCRR § 500 (implements cybersecurity requirements for financial institutions), etc.
2. The EU-US Privacy Shield Framework provides a method for companies to transfer personal data to the United States from the European Union (EU) in a way that is consistent with EU law. To join the Privacy Shield Framework, a company must self-certify to the Department of Commerce that it complies with the Privacy Shield Principles.The FTC has committed to make enforcement of the Framework a high priority, and will work together with EU privacy.The Framework replaces the U.S.-EU Safe Harbor Program.The Swiss-US Privacy Shield Framework is similar to the EU-US framework and covers data exchanges between Switzerland and the US.
3. Legal and regulatory framework for Privacy in Canada:
National-level Federal Privacy legal frameworks: Personal Information Protection and Electronic Documents Act of 2000 (PIPEDA) and Privacy Act of 1983, Canadian Charter of Rights and Freedoms.See also Bill S-4 enacted on June 18, 2015 amending PIPEDA,
Province-level Privacy Legal Frameworks:Quebec Charter of Human Rights and Freedoms, Ontario FIPPA/MFIPPA, Quebec Act Respecting the Protection of Personal Information in the Private Sector (PPIPS), Quebec Act Respecting Access To Documents Held By Public Bodies And The Protection Of Personal Information, Ontario Personal Health Information Protection Act (PHIPPA), British Columbia Personal Information Protection Act - (BC PIPA) , Alberta Personal Information Protection Act (Alberta PIPA), Manitoba Personal Information Protection And Identity Theft Prevention Act (Manitoba PIPITPA)
If you would like to discuss any aspect of this article please do not hesitate to contact us at info@svskyline.com.
The opinions in this article are limited to the scope of this article, and do not necessarily reflect our opinions in general, or the opinions of any of our clients or business affiliates. This information is provided for informational purposes, is not guaranteed to be accurate or up to date, and does not constitute legal advice.
