Some of our customers started asking us about GDPR, so we created a GDPR Compliance FAQ page to answer most questions. To those of you who haven’t heard about it, GDPR is the new European privacy regulation that will take affect on 25th of May 2018. The new set of rules is causing many companies to lose sleep also due to the recent Disney lawsuit and the lawsuit against Kiloo, maker of Subway Surfer. The first suit includes not just the company itself but also tech providers such as Kochava, Upsight and Unity.
This means that while the app companies are on the front, the technology companies behind them should also learn GDPR carefully. In the rest of the post, I’ll try to describe some of the key differences and explain what actions companies should consider. So lets jump into what’s new with the GDRP:
The price tag difference
One of the new aspects of GDPR is that it names a price for non-compliance – fines can reach up to €20M Or 4% of annual gross revenues – the greatest of the two. What this means for app companies is that they have a strong business case to invest money and effort in complying. For tech companies, it means that the level of liability will be pushed up. If tech companies were able to get a way with capping their liability at a $0.5M or $1M dollar, that will no longer be acceptable by the app companies.
US companies also on the hook
Another key difference is that GDPR makes it clear that as long as companies have users in EU, the rules apply to them regardless of their location. For US companies, this is a major difference as privacy rules in the US are less restrictive.
Everything is personal
One thing that the GDPR makes very clear is that all device identifiers including IDFA (Apple devices’ ID for advertising), GAID (Google’s advertising ID) and IP address are now considered personal data and any data stored with it in the same record should also be considered personal. This have been a gray area a few years ago but was getting less and less gray in recent years. With GDPR there is zero doubt about this. For app companies and, advertising companies and analytics companies this means that all data becomes personal and should be treated as such.
Encrypting and protecting and documenting data transactions
Another requirement that GDPR makes more clear is the need to encrypt and protect personal data as well as document any transaction in which encryption was not possible. This is not a new requirement but since all data is considered personal now it becomes a requirement for each company and each piece of data. Here is an example of one process that is likely to change for App companies and has already affected some of the tech providers. In the past, companies used Facebook’s highly effective lookalike modeling service by creating custom audiences based on divide identifiers. The practice of exporting a CSV file from you analytics or attribution platform, storing it in your personal computer and uploading it to Facebook is now considered a non-encrypted transaction that has to be documented. Not many app companies will want to cumbersome their process with the documentation requirement and so some of the attribution companies have responded with audience builder tools that make this transaction encrypted.
Is your data coming to US for business or pleasure
Another area that app companies and tech companies serving them should be aware of is the transfer of information outside the EU and specifically to US. This has been a key topic for previous legislation but the requirements became stricter with GDPR. This topic is known as cross border transfer. In a nut shell, EU knows that US is more liberal when it comes to privacy and specifically in the Federal’s government ability to force companies hand in providing private data. One example of the FBI power over companies was last year when Apple confronted the FBI and refused to help them crack an iPhone. While Apple stood up to the FBI, very few companies will risk disobeying a court order.
To adapt to the new regulations, companies can no longer rely on gaining the user consent for transferring their data. This practice is required but not sufficient anymore. Instead companies should do one of the following:
- Keep data about EU users in Europe and comply all tech providers to do so
- Make sure all providers are part of the Privacy Shield initiative
- Execute model clauses to document each data export from EU to US
Keeping data in EU
This may sound easier than it is. If you are an app company, you are probably using at least a dozen services to help you monetize users, analyze them and improve your app. Most likely, you also have homegrown analytics tech that reads and writes data to a database stored by a cloud provider. Keeping the data in EU means you need to go to your cloud provider and each one of the other tech provider and make sure they also keep the data in EU. In turn, the tech providers will have to go to their tech providers and cloud providers and do the same. While the major cloud providers: AWS, Google and Azure have data centers in Europe it’s unlikely to ensure 100% of the data staying in EU given the number of providers involved especially when the app is serving ads.
This is essentially a certification that companies can get if they do store their data in the US. Being listed in the Privacy Shield list of certified companies is an alternative requirement to keeping data in EU. It means that tech providers who don’t keep EU user data in EU can get a Privacy Shield certification and help the app companies comply with GDPR. In the list below, you can find popular SDK providers that already obtained Privacy Shield certifications and the ones who didn’t. The extensive list can be found here – https://www.privacyshield.gov/list . Note that:
- Providers that store data in EU don’t need the Privacy Shield (e.g. Adjust)
- Providers can give an EU model clause document to app companies as an alternative to Privacy Shield and still comply with GDPR.
SOOMLA is already in compliance with the regulations and has started a process to obtain a Privacy Shield certification. Ask us about the current status by emailing – email@example.com.
EU Model Clause
As mentioned before, providers who don’t keep their data in EU and don’t have a privacy shield certification can still help app companies comply with GDPR by providing an EU model clause document explaining exactly how and what personal data flows from EU to US.
The right to be forgotten
Another key requirement by GDPR is that every user has the right to be forgotten. This means that a user can request an app publisher to delete all his data including data about him that is stored by 3rd party providers.
What you should ask from your providers
While there are a few changes app developers might have to implement in how they handle their users’ data most of the work will probably be with ensuring their providers’ compliance and more specifically their advertising related ones. The decision to treat IDFA, GAID and IP addresses as personal data puts all the advertising industry in the spotlight as most of it was operating under the assumption that IDFA will not be considered personal data.
Here is quick compliance checklist for your providers.
- Do you protect and encrypt any record that contains IDFA or IP address?
- Can lists of IDFAs or IP addresses be exported? Do you send such lists over email?
- Do you keep the data in EU or US? If in US – are certified under privacy shield? Can you provide model clause explaining all data transactions?
- Forgetting users – Make sure you know all instances of the user record (log, backup, main DB, …) and what’s the mechanism to delete.
Providers Not Certified with Privacy Shield [updated Nov-2017]
- Adjust (But already has a stricter certification)
- Media Brix
- AOL / Millenial
- Unity / Unity Analytics / Unity ads
Providers Certified with Privacy Shield
- Google – including Cloud, Admob, Analytics and Firebase services
- Amazon – including AWS and Amazon Ads
- Microsoft – including Azure