Well, here we go again. The Court of Justice of the European Union (CJEU) ruled July 16, 2020 in what’s known as Schrems 2 that the EU-US Privacy Shield treaty is invalid, effective immediately.
The wonderful mess we are in as of July, 2020
Why should you care?
As a partnership leader in the cloud software industry, you singularly negotiate the collection, integration, distribution, resale, and management of customer data by you and through your partners. You have a responsibility to correctly apply data management principles in nearly every partnership relationship you enter into.
However, it's a total pain in the ass and very confusing! Don't fret, we'll get you through this.
What is the GDPR?
In 2016, the European Union passed the General Data Protection Regulation (GDPR) to protect EU citizen’s data privacy rights, as called for in the EU founding charter. In particular, Article 8 of the Charter explicitly provides for a right to personal data protection.
The GDPR regulates how commercial companies either automatically collect and process personal data, or manually collect personal data to be put into a ‘filing system’ for people in the European Economic Area (EEA).
GDPR compliance is about more than Europe
Many other countries have adopted similar legislation to the GDPR, such as Brazil, Australia, Japan, South Korea, Argentina and Thailand, making any compliance issues a global issue.
Is the GDPR actually being enforced?
Enforcement is accelerating. Over 300 GDPR fines have been levied, most in the past year. However, many have complained GDPR enforcement is rare, slow and meagre.
Some have taken the cynical view that this is a tool to capriciously pick and choose winners in the market. US-based companies Google and Facebook are bearing the brunt of enforcement with fines in the tens of millions of euros, whereas it appears EU companies often receive much smaller fines in the few thousands of euros.
However, the reality is that regulatory bodies are understaffed and still ramping up. They are not particularly keen to make business impossible, so practice has been to levy small fines on businesses that diligently work to mitigate and repair damages. Meanwhile, they are focusing their attention on the biggest data risks which are naturally US companies.
Further, the European Union has 27 member states, each of which enforces the GDPR based on its own local policies. There are uneven standards this early on.
What is personal data?
The GDPR is specifically focused on protecting individual privacy. Personal data is any data related to an identifiable natural, living person.
Yes, this includes the obvious name, address, email, phone number and date of birth; and categories like their religion, political affiliation, or sexual orientation. It also could be their IP address, health data including mental health, employment status, psychological profile, education history, or even their favourite sports team.
If you can individuate a natural person from the data, that is also personal data. For instance, the company name of a sole proprietor; or company name plus job title; or browsing history that can uniquely identify one person over another.
What’s the problem today with the United States?
In the wake of Edward Snowden’s revelations of mass surveillance of non-US persons, the United States has been specifically named as a country with inadequate data protections of personal data.
Principally, this comes down to two things. The US does not limit law enforcement to data collection to what’s minimally and strictly necessary to perform their functions. Further, EU citizens lack sufficient, independent, and binding due process to adjudicate their personal data in the United States.
Are we really talking about espionage?!
Yes. If you can believe it, we’re all being held accountable for the United States intelligence regime. Since that is beyond any of us mere mortals to control, you can expect an unstable data trade relationship between the EU and the US for a long time.
It’s not just the United States
The same situation will apply to every other country with a strong bent towards mass surveillance.
Didn’t the Privacy Shield solve this problem?
The Privacy Shield framework called for the Department of Commerce to regulate companies certified under the Privacy Shield. It also appointed an Ombudsman to field complaints from EU citizens.
However, the EU courts have found the Ombudsman neither is judicially independent nor lacks the power to enforce binding decisions on the US intelligence community. Therefore, the Privacy Shield is inadequate.
It’s important to know that this was wholly unsurprising.
Does this mean the Privacy Shield is dead?
No, the Privacy Shield is fully in force. If you are certified under the Privacy Shield, you are still bound to your obligations under it both to the Department of Commerce and to any customers you entered into agreements under it.
However, you can no longer use it as a basis to legally transfer data from the European Economic Area (EEA) into the United States.
For now, you can use it to transfer data from Switzerland to the United States under their parallel treaty. However, expect that to fail as well.
Is there hope of a resolution?
There’s always hope. The United States and the EU are negotiating a third iteration of this framework.
Since GDPR passed, the United States has subsequently passed the CLOUD Act (2018) that requires US-based businesses to hand over data to law enforcement, even if stored on foreign servers controlled by foreign subsidiaries, only checked by the business objecting in court (expensively). It also allows the United States to enter into mutual law enforcement assistance treaties with other countries to expedite data exchange.
The United States recently also reauthorized section 702 of the FISA Act (2008) that authorizes the intelligence agencies to collect any information about non-US persons on foreign soil.
So, it’s not going to be easy.
What do you need to do right now?
Standard Contractual Clauses
All contracts between companies housing data in the US and EU citizens relying on the Privacy Shield may need to be amended to use "Standard Contractual Clauses". If you don't have such clauses in your contracts, you will need to add them immediately.
Here are two templates with explanations from the UK’s Information Commissioner’s Office (ICO):
And an excellent set of GDPR starter templates from iubenda.
In the context of your customer contracts, you’re a processor if you make no decisions about how personal data is used, transferred, exported, etc. Instead you do so only at the behest of your customer, the data controller. If you provide professional services related to your software, you will likely be a controller as well.
In the context of your own sales and marketing, where you collect personal data for email marketing, sales, and other activities, you’re a data controller.
Binding Corporate Rules
A much more expensive option is to create Binding Corporate Rules. These only govern transfers internally, between companies in a group, such as a multinational corporation. They require certification by the data protection authority (DPA) in each member state. You only need one lead DPA and two co-leads to gain fast track approval in the remaining states. Nevertheless, this is a difficult process and it has rarely been successfully carried out.
Relocate data to EU data centers
Another solution is to never transfer personal data out of the EU. In the medium to long term, migrating your cloud software into EU data centers (or other countries that have adequacy decisions, like Canada or Australia), and only relying on other services also hosted in the EU will greatly mitigate your risk to the EU and the other countries with similar GDPR laws.
Note, however, personnel or third-party services in the United States or other jurisdictions deemed inadequate will not be allowed to access personal data and thereby export it, even to provide customer support or if copied in an email chain.
Also, as mentioned above, with the United States CLOUD Act (2018), if the controlling company is US-based, it may not matter where the data centers are located. The US federal government can still demand access to the data.
Privacy-proofing your partnerships
Partnership relationships between cloud software companies, and between cloud software companies and service partners, can have a number of structures and arrangements that change who is liable for the data.
The key principle is to look at data from the customer’s point of view:
- Who ultimately is responsible for my data?
- Who holds my data?
- Who has access to the data?
- Who can make decisions about it?
- Who is aggregating my data?
Conversely, if someone is in the middle, and they aren’t touching the data, keep them out of it.
What are the core principles of data management and ownership?
- Customers own their own data.
- Individuals have the right to control data about themselves.
- Therefore, individual's data can only be used with explicit consent. That includes customers, partners, vendors, and your own staff.
- Data may be anonymized, aggregated, and deindividuated, as long as it is not used to make algorithmic decisions about the individual.
- Individuals have the right to know what’s recorded about them and they have the right to be forgotten (right to have their records deleted), subject to limitations of statutory records keeping.
- If you aggregate data about individuals (e.g. scraping public websites), you must send them opt-out notifications.
- Personal information (to be defined) must be collected opt-in, not transferred or sold without consent.
- Your business customers must be made explicitly liable to obtain consent from their customers for collection and use of their personal data.
When you are integrating two software products together, data will be exchanged. What are your responsibilities?
It depends on how the contracts work.
- Customer wants to integrate and sync between two products. If the customer entered into separate contracts between two software services, they are the data controller. They are the ones who decided how data is collected and transferred. You are just a data processor. You are authorized by your customer to initiate the transfer.
- The integration is done through an cloud connector / iPaaS the customer uses (e.g. Zapier). Similarly, the customer is controlling and authorizing the transfer. The cloud connector is another software system in their stack.
- You contracted with a cloud connector / iPaaS to implement the integration. In this case, you made a decision about how the data is managed. The cloud connector is a “sub-processor”. You’re responsible to verify they are compliantly managing data on behalf of your customers.
Regardless of who made the decision to transfer the data, you will be responsible for the implementation of any integration under your control.
In your API terms of service you should put in privacy clauses that require the same minimum safeguards and protections of privacy and confidentiality that you adhere to. Points of integration need also to be secured as they are openings for hackers to breach data.
Use secure authorization protocols like OAuth, rotate authorization credentials, keep your SSL certificates up to date, routinely conduct penetration tests, and add API monitoring to look for unusual activity.
If you import personal data through an integration that you then aggregate into a secondary product, you need to ensure that it has a clear path of consent. Otherwise you may taint your database.
Data sources and data subject consents, and dates, need to be recorded accurately, and possibly moved from system to system. If you have an API endpoint that collects personal data, you should require data source fields and dates.
Embedded partnerships (OEM)
You may enter into a contract with another software service to fulfil part of your product offering. Common examples include Stripe Elements or a cloud connector you whitelabel to implement your integrations.
Because you are transferring data to them to fulfil your obligations to your customers, they are subprocessors. Effectively they are you, and you are them.
You are fully responsible for everything they do to perform your contracts as you have to sold to your customers, and therefore not only should they legally agree to the same minimum standards, but you should also validate they are compliant.
Again, if they screw up, it means you screwed up.
When evaluating partners ask:
- Is the data stored in a secured environment, encrypted at rest and in transit?
- Is access to production code and data limited to a small number of officers or agents? Both at the server level (i.e. your dev team) and at the customer support level.
- Are all people who have access to customer data subject to confidentiality agreements?
- Are company computers with access keys or passwords secured, encrypted, and tracked as assets?
- Does the company have audit logs for who accessed customer data?
- Does the company conduct regular penetration tests?
- Do they have a point of contact for security issues?
- Do they have a 72-hours or better notification policy upon breach?
- Do they have a security bounty program?
- Do they have certifications like SOC-2, PCI-DSS, HIPAA, or ISO 27001?
If you or the customer rely on service companies, resellers, or retailers to bring your solution to market, anyone in the middle has responsibility to protect data as well.
Don’t make this mistake! Cloud software is not the same as licensed software
Quite often these arrangements are constructed incorrectly because the metaphors we have come from the licensed on-premise software industry.
With licensed software, commonly a system integrator or implementation partner would procure a copy of the software then install it on hardware controlled by their customer. The data in most cases will reside entirely within the customer’s control, and therefore data processing agreements were unnecessary.
Cloud software is different. The data resides in a data center outside the control of the service partner. You’re ultimately responsible for how the data is secured. They are only at best able to manage the relationship with you.
Therefore, it’s unreasonable to push liability for data protection onto your channel partners. Practically, most are not even capable of managing data security.
They aren’t VC-backed tech companies, set up like you are to handle data compliance. They aren’t likely to become SOC 2, HIPAA, Privacy Shield compliant, know how to manage Standard Contractual Clauses, etc. They are usually small companies who are providing subject matter expertise for implementation, like a small marketing agency setting up a marketing stack.
In fact, part of what cloud software partners sell to channel partners and customers alike is that you are taking on the compliance, privacy, and security costs and risks as specialists and experts.
What you should do
If you can, you should endeavour to own the contracts directly with your end customers, so you can flexibly adjust as the privacy environment changes.
This doesn’t have to be difficult.
Allow service partners to sign up on behalf of customers, as purchasing agents. As long as they are acting in the course of their agreement with the customer, and the customer is aware and takes positive action (such as paying for the software), then they can subscribe on the customer’s behalf.
A common example is any click-through terms of service that people sign up for in a day for a client or an employer.
You can also provide an End-User License Agreement (EULA) to the partner to include in the set of contracts they make their customer sign to initiate the project or authorize the purchase. Anyone who has bought life insurance has experienced this as the insurance broker is not the carrier, but presents the carrier’s contract to you to sign.
- Note on sales incentives: If you provide any benefits that may induce the service partner (not just including commissions), where it could be said they are creating benefit on your behalf, you need a Master Services Agreement or Partner Terms that again holds them keep customer data private, confidential, and they are liable for account access, data exports, breaches, and password protection.
Case 1. Customers buy from a Value Added Reseller (VAR)
In a resale model, where the partner takes a contract with you, and then sells a new contract to the customer to deliver the software or services. This model is very popular in telephony for instance.
This model is popular because it’s analogous to installed, license software. A value added reseller makes money up front for the installation and delivery. The data is hosted on the customer’s computers, so it’s safe.
Unfortunately, the analogy isn’t correct because the cloud software is never “installed” in the customer’s control. The data is hosted elsewhere, controlled by you. If the customer isn’t directly contracted with the VAR, the VAR is directly on the hook for data protection.
It’s better to give the VAR an End-User License Agreement (EULA) that contracts the customer directly with you, but the VAR is the point of sale. Have them enter in a Master Services Agreement with you to oblige them to be data compliant so they can provide support and maintenance as well.
Case 2. Whitelabel reseller
Similar to the reseller model, but the customer doesn’t know who you are. The reseller acts as if they are the software provider.
You’re still fully liable for the data in your control. The only thing that changes is that your notification obligations are to the reseller. The reseller is fully liable to the customer for all the data under management. This may cause problems because they are less likely to provide adequate data protection to the customer, such as reasonable notification, data officers, data compliance. If there was a breach, the customer would sue them, and the reseller would sue you.
Note, under GDPR rules, true whitelabel is impossible. The reseller has to name you to the customer explicitly in the contract because data is being transferred to you.
Case 3. Customers own their accounts, but hire service partners to implement and/or operate
Here the customers have a direct contract with you. However, they have used a service partner to do the work to set up and operate the software on their behalf.
The analogy is a general contractor (GC) installing a furnace that exploded and burnt down your house. If the GC installed it wrong, it would be their liability. If the furnace had a manufacturer defect, the manufacturer is liable. The GC is indemnified.
They are legally “data controllers”, but they are more like “data subcontrollers”. They really are an aspect of the customer.
Case 4. Implementation partners hired by you
In this case, a customer buys from the software company directly, and you subcontract implementation or other services to a service partner to deliver the software.
In this, the contract is with the software company, and the service partner is effectively your staff, and must be obliged to protect the data in a Statement of Work and contract the same way as any of your staff or vendor services.
Case 5. Agencies buy master accounts and create subaccounts for customers
Quite often software companies provide master accounts to agencies. Agencies create subaccounts under their master account for their customers.
The key distinction is what is the deliverable to the customer? If the agency is using the software to make a work product like a PDF report or a spreadsheet (e.g. an SEO keyword report) that is delivered to the customer, the software is really more like a carpenter’s workbench. It’s an internal tool for the agency.
If on the other hand, the account is being actively used by the customer, it has customer data, or becomes part of the operational stack of the customer’s business, then you have to be much more careful.
A simple test: Does it make sense for the customer to transfer control of their subaccount directly into their own hands? For instance, if you are a website hosting platform, customers will want to gain control of their own website.
If the customer can gain control, you should set up your account management system to separate each customer’s account, and give the customer the ability to take control of their own data, and provide data rights to anyone whose personal data is in their account.
Even if the customers never can gain control of the subaccount, if personal data (e.g. the customer’s own customer records) is being transferred into the agency’s account, the agency’s customer must have the ability to seize control and manage the subaccount.
A word on horizontal liability. A common mistake is to mix or manage data from several customers in one master account. If there is a legal proceeding against any one single customer, every single customer whose data is in that account may be exposed. That is not going to be a good day for anyone.
Partners often share leads with one another to help grow existing customers or close prospects in the pipeline. While an aggressive sales strategy would be to share openly and often with your partners, this is not legal. Data subjects (your customers and prospects) have the right to control and limit dissemination of their contact information.
- Customer referrals. If a company refers a customer to a partner, as long as any introduction is done through a positive action from the customer, you are ok. For instance, you can simply direct a customer to the website or contact form of your partner to start a sales conversation themselves. Or you can ask your customer if you can introduce them to your partner first, and only make an introduction once they say yes.
You should set this consent-based introduction expectation for your partners as well because angry customers are no fun.
- Implementation partners. If you farm out inbound customer leads to a database of reseller or service partners to manage the sale or implementation on your behalf, you must explicitly name each and every partner to the customer when you collect their contact information, where such list cannot be onerously long. You cannot simply link to a partner directory.
You could provide a list of 10 potential partners to the customer explicitly.
Also channel partners working under a subcontract from a vendor, may only contact customers on behalf of the vendor, and only about the vendor’s products because they are aspects of the vendor. They must ask for separate permission to contact the customer directly.
- Partner directories. A different and perhaps better solution is to have the customer opt-in to the partner marketplace as a separate action similar to how signing up for LinkedIn or UpWork allows contact from anyone on the social network. This allows you to use the legitimate interest basis for partners to contact your customers directly.
- Account mapping. You can proactively share any non-individuating data with your partners, such publicly sourced information like company, industry, organizational size, vertical, website to find customers of mutual interest. You have to take care that the company name cannot individuate a person, such as a sole proprietorship.
Once you identify a customer, use the double opt-in consent-based introduction to make the connection.
- Account mapping with sales reps. If you are making an introduction to sales reps who will then make an introduction to customers, the sales reps also need to provide consent to be on the system, including under the CCPA.
Partners are people too! Your marketing tools like your Partner Relationship Manager or Email Marketing that collect and manage partner contact information must also demonstrate partners have opted-in to communications.
For Through Channel Marketing Automation, your partners and their customers must both have opted-in to communications.
CROWNPEAK CASE STUDY
Crownpeak is a US-based content management system with customers in the EU that through the course of normal operation of the software tracks visitor data and collects prospect and customer data. William Littman, Head of Legal Affairs, was kind enough to sit down and explain their excellent response to the lose of the Privacy Shield.
What happened as regards international data flows?
On July 16, 2020, the CJEU invalidated the Privacy Shield mechanism for transferring Personal Data from the EU to the US as the US was deemed to not have “adequate” safeguards.
What does this mean for our customers & prospects?
- Data will not stop at the border! EU data will still flow to the US as before. No services are being shut off.
- Use of SCCs - We will have to migrate over from Privacy Shield to Standard Contractual Clauses (SCCs) as the basis for handling cross-border transfers of Personal Data from the EU to the US.
- For existing EU customers, I expect that we will receive emails and questions in the coming weeks regarding the basis under which we plan to handle Personal Data moving forward. To this end, we have revised our existing Data Protection Addendum to modify the proper basis reference from Privacy Shield to SCCs. For further assurances, we will continue to maintain our SOC2, Type II certification and undergo annual penetration tests to assure best in class administrative and technical safeguards.
- For new EU sales prospects, your teams should advise that we process under SCCs and this is incorporated into our template DPA. No references to Privacy Shield anymore. As SCC does not involve a self-certification process, expect that there might be more friction from enterprise legal teams as they wonder if we are “truly truly” compliant. Based on our undergoing a comprehensive self-certification for Privacy Shield, I hope we should be fine, but do not be surprised if there is even more emphasis placed on compliance questionnaires. We may have to undertake additional measures to assure prospects that our security and privacy standards are best-in-class.
- For channel partners, you can continue to assure them that their liability is limited as we contract directly with partners, and the liability is ultimately borne by Crownpeak through indemnification. In keeping with our ethos of intentionally limiting access to our customers’ Personal Data, the risk does not change in light of the Schrems II decision. As such, we will remain at “arms length” in managing data while continuing to safeguard the Crownpeak platform, access and workflows.
- Data Centers – we process EU data in the US, but to future-proof us against the whims of the EU, should strongly consider storing all EU data in the EU. In furtherance of this goal, we plan to put together a roadmap to show customers/prospects that we are working on moving our data and timelines to which we can be held accountable.
- Can we rely on customer consent? While this is possible, in order for consent to be a legally valid basis in every instance, it must be explicit, specific for the particular data transfer or set of transfers, and informed as to the possible risks of such transfers (including, in light of Schrems II, that if data is transferred to the US, that there are no adequate safeguards in certain instances). Given the large number of customers and users that avail themselves of our services, this would be virtually impossible to achieve.
- Can we forego SCCs on the basis that certain data transfers are necessary for the performance of our contract? This would not be tenable as personal data can only be transferred under this provision when the transfer is “occasional” and “objectively necessary” for the performance of the contract. Ultimately, it is a legal determination made on a case-by-case basis, so not an efficient means to transfer data.
Expect lots more to come over the next few months. The European Data Protection Board issued guidance on July 23, 2020, and thus far, has only led to more questions. We will likely have to update SCCs again and make continuous adjustments to stay ahead of and at minimum meet requirements as they evolve. We might see additional frameworks come into existence, but until the US and EU can come to agreement on the geopolitical level, this will continue to be a major issue for businesses.