T025590N6-U48JV4JQ3-c1e97676ac13-512 avatar

T025590N6-U48JV4JQ3-c1e97676ac13-512

General Counsel

Jeremy Freeland



## Schrems 2 Ruling 
The European Court of Justice (ECJ) ruled on July 16, 2020, that the EU-US Privacy Shield framework is no longer valid as a means of ensuring adequate protection for transfers of personal data from the European Union to the United States, on the basis that US national security requirements do not meet EU privacy standards.
 
Importantly, the ECJ also decided that the Standard Contract Contractual Clauses (SCCs) are a valid transfer mechanism.
 
The ECJ deferred to national EU data protection supervisory authorities to determine the lawfulness of transfers to countries such as the US where the ECJ has determined there is a conflict between national laws and EU data protection laws.
 
This post advises Auth0 customers who process EU personal data of the likely immediate effects of the Schrems 2 decision on their use of the Auth0 Platform.
  
## European Customer Data is Stored in the EU 
Unless a European customer has opted to establish its Auth0 tenant(s) in an AWS region outside the EU, the data of Auth0's European customers is stored on AWS infrastructure located in the AWS EU region (Germany, with failover to the Republic of Ireland). This means that this data is not transferred out of the EU – in other words, the Schrems 2 decision has no effect on this data, and customers will not need to make any changes. This applies both to Auth0's public cloud customers and private cloud customers.
 
As disclosed in our contracts with our customers, Auth0 conducts some limited processing of personal data outside the EU. This involves:

* _Management dashboard:_ For public cloud customers, Auth0 may temporarily process tenant data in the US for display on the Auth0 Management Dashboard. Dashboard web servers are located in the US. This data is not automatically transferred but is only served up when a tenant dashboard administrator requests it for viewing. When this occurs, the data itself is ephemeral, is not permanently stored on these systems, is fully encrypted during transit, and is only used to display information on the dashboard to the requesting administrator. This data can include any information that can be viewed through the Auth0 Management Dashboard, which typically includes the user's e-mail address or other UID and basic metadata about that user, such as creation date, last login time, user agent, and the identity provider used. Note that this dashboard processing occurs within the AWS region the customer has selected for its tenant for private cloud customers.
 
* _Support tickets and logs:_ If a customer includes personal data in a support ticket, then this may be viewed by Auth0 support personnel outside the EU. In order to resolve the ticket, Auth0 personnel may review activity logs to help understand the underlying error. Personal data in those logs typically consists of a user ID (e.g., e-mail) and IP addresses. 
 
## Auth0's DPA has Triggered the SCCs 
For transfers of personal data from the EU to the US, the SCCs will now apply.

Auth0's form of Data Processing Addendum (DPA) anticipates the invalidation of the EU-US Privacy Shield framework as a transfer mechanism. Under Section 6.1 of the Auth0 DPA, Auth0 and customers who are a party to the DPA have agreed that the SCCs will apply in these circumstances. Thus, although Privacy Shield has been invalidated, transfers by Auth0 of European customer personal data are now subject to the SCCs.

Although the DPA contemplates that no further action should be required for the SCCs to apply, we expect to post a pre-signed set of SCCs for customers to countersign early next week. Auth0 customers looking for additional assurance beyond the DPA may use this method to apply the SCCs to transfer their data.

## Next Steps
This is an evolving situation, and we will be monitoring developments closely. In particular, we expect the cloud service provider sector to consolidate on an approach to the invalidation of the EU-US Privacy Shield framework over the coming weeks. We expect national EU data protection supervisory authorities to begin to communicate their position on determining the lawfulness of transfers to countries such as the US, where the ECJ has determined there is a conflict between national laws and EU data protection laws.
 
We will update this blog to reflect key developments – please check in regularly.

<include src="asides/AboutAuth0" />


Schrems 2 – EU-US Privacy Shield Ruled Invalid

adam-nunn

I'm a security and compliance professional with a passion for emerging cloud technologies. I specialize in risk, privacy regulations, and industry-standard security frameworks.

Sr. Director of Governance, Risk, and Compliance

Adam Nunn

Privacy and security are partners joined by an IAM



_**Disclaimer:** This article is for general information purposes only and not a substitute for legal advice. Please consult with your legal counsel to obtain specific advice for any legal manner._

Any pre-teen with a journal understands the difference between data privacy and data security. If you secretly read your friend’s journal to find out their secrets, you’ve violated the principles of data privacy. But if your friend tells you their secrets, and you write it in your own journal, and then leave that journal out where anyone can read it, you’ve violated good data security.

As a pre-teen, a failure on either front can cost you your friendship. In today’s business world — in which cybersecurity threats are rampant, and data privacy laws like the EU's General Data Protection Regulation (GDPR) and California Consumer Privacy Act ([CCPA](https://auth0.com/ccpa/)) are cropping up around the world — failure can be even more costly. Knowing the difference between data privacy and data security, and the tools you must employ to protect both can help prevent breaches and achieve legal compliance. Unfortunately, too many executives think that their data security policy covers data privacy, and vice versa.

In this climate, it’s crucial for executives to understand how these concepts differ, how they overlap, and how to incorporate both into a sound data governance strategy.

## What's the Difference Between Data Privacy and Data Security?

You can imagine data privacy and data security as a Venn diagram with significant points of overlap, but businesses should have a distinct set of strategies for managing each. 

That doesn’t mean you can have one without the other, necessarily -- you can hardly protect privacy without security. But it does mean that sometimes it’s important to look at each concept separately to make sure both sides of the security/privacy coin are being properly addressed. 

### Data Privacy

Data privacy is about defining what personal information you should and shouldn’t ask for (or gather) from your users.

It concerns how and why an entity collects, stores, shares, and controls access to sensitive data. Data privacy is about the kind of information you ask from your users (or collect via cookies or from third parties), why you ask for that information in the first place, and how you plan to use the information you’ve gathered.

**Data privacy applies to the personal information of an individual.** GDPR and [CCPA](https://auth0.com/ccpa/) have [broadly similar definitions of personal data](https://fpf.org/wp-content/uploads/2018/11/GDPR_CCPA_Comparison-Guide.pdf). An individual’s full name and mailing address will typically be considered as personal data, while in some cases, browsing history could also be seen as personal data. GDPR goes further in defining special categories of data, such as health information, political affiliation, biometric data, and sexual orientation, which are all subject to stricter requirements for processing. The personal data of minors is also subject to stricter regulation under many international laws.

**Data privacy laws address both the "how" and the "why" of data collection.** These laws require companies to transparently communicate their policies with users and give users greater control over how their data is used, which may require providing users with the ability to opt in or out — that’s the “how.” But they also require companies to disclose what purpose they’re collecting data for — that’s the “why.” In other words, what is the reason for the intrusion.

For instance, prior to GDPR’s passage, the [UK fined Facebook](https://www.bbc.com/news/world-us-canada-48972327) for giving Cambridge Analytica access to user data without user consent, violating their privacy. There wasn’t a data breach or a malicious hacker involved — the company just wasn’t respecting user privacy, and that data was then used to [manipulate elections potentially](https://www.theguardian.com/news/2018/mar/17/cambridge-analytica-facebook-influence-us-election).

There are, of course, totally legitimate ways for a company to collect personal information without prior consent that doesn’t inherently violate the principles of data privacy. Most companies who do business online collect things like usernames, password hashes, bank or credit card information, and other data directly related to business operations.

If you’re a home insurance company, you may need the address of the customer’s home, the size of the home, the year it was built, etc. It may be perfectly fine to have that information, but if your insurance company shares this data with an unauthorized third party without your customers' knowledge or consent, you may be trodding into non-compliance territory.

Personal information as defined by the laws is a bit of an ever-changing and refining property, but there are [methods for keeping up with the changes](https://auth0.com/resources/whitepapers/evolving-definition-of-personal-Information). 

**Some data privacy laws, including GDPR, specifically enshrine the "[purpose limitation principle](https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/),**" mandating that personal data can’t be used for a new purpose without specific permission. GDPR also requires “data minimization:” that entities don’t [collect more data than is needed for a particular purpose](https://auth0.com/blog/avoid-sinking-your-code-by-treating-data-as-a-liability/) for a specific purpose.

### Data Security

If data privacy concerns the personal data of individuals, data security concerns how a company protects that data from unauthorized access or corruption. Data security is what you do with the data you’ve gathered from your users — where you store the data, whether or not you encrypt it, who has access to it, and how you determine who is an authorized user.

It’s possible to have good data privacy standards while still failing on data security. Even if your data collection policies are strictly in accordance with the law, if you’re not protecting that data with adequate security measures such as authentication and access management, you still may not be in legal compliance.

![dataprivacy_vs_datasecurity-sep-1](https://images.ctfassets.net/23aumh6u8s0i/74v3Z31GvHeWlHw69QRUck/f46dcb7bc08161945d39d0f6bfa54283/dataprivacy_vs_datasecurity-sep-1)

## How the Law Regulates Data Privacy and Data Security

The [GDPR and the CCPA](https://auth0.com/resources/whitepapers/GDPR-vs-CCPA) came into being largely in response to unscrupulous data collection policies that failed to respect users’ privacy. Data privacy laws may require companies who deal in personal data to have well-maintained records of how user data was acquired, why, who had access to it, and where it was sold or shared and with whom. You may need to have all that information ready at all times, and be able to share it with users and regulators upon request.

The current crop of data privacy laws also specify, to varying degrees, the security measures that companies are obligated to adopt to protect data.

### Protecting Access and Anonymity

There are tools to help you build a stronger data privacy and security program.

**Access management is all about ensuring the user is who they say they are, that you have access to what you should have access to, and having a way to manage that access**. [Implementing multi-factor authentication (MFA)](https://auth0.com/blog/why-nist-recommends-mfa-to-fight-ecommerce-fraud/) is a major element to data security; otherwise, it would be easy for intruders to impersonate users and expose records through credential stuffing. MFA identifies users by checking who they are (a username), that they know something the user ought to know (a password), and that they have something only the user would have (a USB key, a mobile phone, etc).

Depending on which law you’re trying to comply with, **anonymization and de-identification are all about scrambling user data so it is no longer identified or identifiable**. There are varying legal and technical standards for what constitutes de-identification and anonymization, but as more laws develop, and the ones on the books have time to mature, we can expect some clarity and convergence on this front. IAM’s management can aid compliance even with ever-changing legal definitions. 

## Creating a Data Privacy Plan
A strong data privacy plan is all about knowing what data you have on the customer/client/user and why you have it.

You’ll need both an internal and external policy. Where an external privacy policy lets clients, customers, and shareholders know what kind of data your collecting and why, the internal privacy policy outlines what team members and the company can do with that information.

### Hash Out the Internal Policy

Sit down with your development team and hash out the bare minimum data you need to ask for.

A mapping app needs GPS locations, an online order needs an address, etc. Do not ask your customers (and do not _collect_ from your customers) any non-essential data. Even if it might “come in handy” due to future planned features of your business, GDPR and other laws stipulate that you cannot use data for anything beyond what it was originally gathered for. There’s no saving it “for later.”

The next step is to create a comprehensive policy for everyone that outlines what kind of data you’re collecting for your business, the related bits [of the actual regulation text](https://gdpr-info.eu/) to keep everyone on the same page, and detail who’s responsible for executing each leg of the policy.

Next, take stock of all the data you have and create a comprehensive inventory.  

An identity and access management (IAM) system can help you find and manage this kind of data. Take inventory of where the data has gone - to other businesses or people - and track how it got there and for what purpose.

### Drafting the External Policy

What do you need in your privacy policy to put customers at ease and meet compliance? 

First, find the relevant laws you’re working on in your location and business. A corporate lawyer who specializes in your industry may be a smart first investment, or at the very least seek out the advice of an expert in your field. 

Draft a privacy message that communicates what data you’re collecting and why, matching the legal requirements. Cribbing from boilerplate privacy permission forms from other companies in your industry could be a good starting point, but always work with your legal counsel to make sure your privacy statement accurately reflects your organization’s practices.

### Execute the Plan

The broadcast and execution of the internal and external privacy policy will need a multi-pronged approach. 

The internal privacy policy needs to be located in a knowledge base that all relevant team members have access too, and team members will have to be trained on the new policy. And, of course, developers will have to deploy these changes throughout the system, overhauling or tweaking how you collect customer data (and what data you collect). 

The external privacy policy will need to be broadcast wherever clients and customers will see it when giving the company data of any kind -- on a website, a mobile app, paper forms, whatever method your company uses.

## Create a Data Security Plan
Data security tackles two kinds of data: structured data and unstructured data.

**Structured data is the kind you'll find in your IAM** &mdash who is accessing what, and where, while logged into your system. Modern IAM platforms like Auth0 make handling structured data relatively easy. 

**Unstructured data is anything from emails to PowerPoint decks to paper notes on an employee's desk**: sensitive or valuable data that is outside of your IAM, that cannot be easily tracked and collated. Are employees emailing files to each other instead of sharing them via an encrypted cloud service? Are they taking data home in the form of print-outs or USB dongles?

### Make Someone Responsible for Data Security

The person in charge of these plans should be your CDO (Chief Data Officer) or an equivalent, dedicated position depending on your company’s size and resources. 

They should be in charge of compliance, data handling, and employee instruction on up-to-date data policies. 

###  Identify Your Vulnerabilities
Where are your data security vulnerabilities?

The more sensitive data you collect, the greater your security should be. If you have an online store, your IAM needs to help you manage and encrypt user names, addresses, and financial information.

For a company that controls medical information and has a greater responsibility to protect data in the eyes of the law, authorization and security must be airtight. Methods like multi-factor authentication and data scrambling become non-negotiable. Choosing a security solution with HIPAA experience that can offer BAAs is paramount.

If your organization stores messages, chat, or email from customers and clients, those messages need to be encrypted -- data pulled from seemingly innocuous communication could contain user information useful to breach financial accounts. If you offer a reward or loyalty program, those are frequent targets of fraud and require strong authentication and identification.

### Secure Every Form of Data

Your plan to secure data is going to depend on what sort of data you’re dealing with. Most, if not all, organizations deal with both structured and unstructured data. 

**In the case of structured data, your security plan should be tightly controlled permissions, multi-factor authentication, and single-sign-on policies for all sensitive data**. All passwords need to be hashed and salted in your database, as do all usernames.

**The primary weapon against unstructured data breaches is training**. To tackle unstructured data, start with a strong DLP (data loss prevention) plan to identify your most sensitive data and your most likely avenues of breach. 

Again, whoever is in charge of data security is also responsible for training team members about the danger of USB drives, sensitive information written on slips of paper, mobile phone photos and videos.

Create regular reminders and in-person training, showing all employees how to keep their communication private, and how to properly share files while keeping them in your secured Cloud. 

Detail policies of what data can go home if any, and consider tagging that data with a kind of check-out system to increase accountability.

**And don’t neglect machine-generated unstructured data**. Does your workplace have security cameras? Are those security cameras, either the live feeds or backed-up recordings, accessible online in anyway? Cameras and video storage can be hacked, and it's very easy for hackers to glean a huge amount of sensitive data from visible computer screens and conversations.

If you have a fleet of vehicles, their GPS data can be hacked. Your logistical routes for both cargo and personnel isn’t something you want a bad actor to have, but it’s the kind of unstructured data that’s easily forgotten.

![dataprivacy_vs_datasecurity-sep-2](https://images.ctfassets.net/23aumh6u8s0i/717Ex47kQdyZ5d40k3dM24/bd043d7ddbc62e50247db9b1f3399cb8/dataprivacy_vs_datasecurity-sep-2)

## How to Address Data Privacy and Security With IAM

Good data privacy and security means controlling permissions and dictating who has authorized access to user information. It means ensuring that the only people with access to user data have adequate training and are doing so for legitimate purposes. It means defining authorized access and prohibiting unauthorized access. It means knowing, at all times, who is doing what in your system and why.

One major point of overlap between data privacy and security (and subsequently the best place to address both) is IAM. With your IAM platform, you can authenticate users, protect their data from unlawful access, and create user profiles from which administrators can access and manage all the data you have on everyone in your system.

When formulating your company’s [data governance strategy](https://segment.com/resources/cdp/customer-data-management/), the right IAM solution will help you get a picture of where your data is being stored and control who accesses it. A good IAM system keeps your finger on the pulse of what’s actually happening in your system and provides up-to-date information on your user-base's data.

![IAM](https://images.ctfassets.net/23aumh6u8s0i/60gvj9w6NoByMHhxSq0wQM/95c8e6319ed6f269aee6e02a891ecf0f/dashboard)

Auth0’s IAM system creates granularity of access — you can define which users have permissions and at what level of security. It doesn’t have to be a binary choice between admins (who can access everything at all times) and users who are completely blocked. You can define different permissions for different needs: helpdesk, accounting, marketing, and your CTO would all have vastly different levels of trust and access. This not only tracks accountability better, but ensures that a breach of one account won’t necessarily expose all the data in the system.

Sophisticated IAMs also enable features like [multi-factor authentication](https://auth0.com/blog/different-ways-to-implement-multifactor/) and single sign-on, both of which [act as safeguards against breaches](https://auth0.com/blog/credential-stuffing-is-a-persistent-threat-to-your-users/) in the first place.

## Data Privacy Plus Data Security Equals Compliance

While data privacy and data security aren’t the same, they are complementary concepts, and executives must take both into account when approaching data.

Your users, your partners, and international regulators all expect you to be able to explain what data your company possesses, what you do with it, and how you protect it. They also want assurance that the data collected is only for the stated purpose, not to be sold, shuffled around, or exploited when new features or services are created.

The right IAM platform can help you find the answers to those questions, and help you design data privacy and data security policies that work together to form a cohesive whole.

<include src="asides/AboutAuth0" />


"personal-data"