What is EU-U.S. Privacy Shield? What does it have to do with EU General Data Protection Regulation (GDPR) and Directive? Do I need to certify my SaaS? Why and when should I certify? What practical actions do I need to take? What happens if I certify and break the rules?
This is a practical guide to Privacy Shield for SaaS owners in U.S. and in EU, with real examples of actions that SaaS owners are taking.
If you sell to consumers (B2C) then you’re not in a hurry yet. If you sell to businesses (B2B) then you need to take action, no matter where your business is located. It’ll take about 15 minutes to read this guide.
This article hopefully saves you hours, but it is not legal advice. While I do my best to cover the major points, I’m not a lawyer and these directives and regulations are huge – the responsibility is all yours. So please do your own investigations too.
Updated 6th March 2017: The Privacy Shield Team confirmed by email that you can only apply for U.S. Privacy Shield certificate if you’re under the jurisdiction of the U.S. FTC.
What is EU-U.S. Privacy Shield?
Privacy Shield is a framework between European Union and United States.
Privacy Shield makes it legal to move personal data from Europe to U.S. It replaces Safe Harbor that became invalid in 2015. In the meantime, U.S. businesses have used European Commission’s Standard Contractual Clauses or just been plain confused about what to do.
Addition of Privacy Shield does not make standard contractual clauses invalid so you can still use them.
The source of all of this is EU General Data Protection Regulation (GDPR) and Data Protection Directive. The directive is already active, but each EU country will have to create their own privacy protection laws based on it and they have until May 2018 to do so. The regulation is an EU-wide law, which will become enforceable in May 2018.
Now businesses in Europe are proactively preparing for the upcoming law.
One of the requirements is that EU citizen’s personal data can not be moved to U.S. unless the service provider is safe enough – and Privacy Shield certificate is a sign of safe providers.
I’m in the U.S., do I need to worry about GDPR?
No. When you have a Privacy Shield certificate you are GDPR compliant and the businesses in EU can use your service.
However, if you have no proof that you’re safe then European businesses will stop using your service. They face heavy penalties for not complying with GDPR. You will also lose U.S. businesses who need to deal with European data.
Like what we saw with VAT, EU claims that GDPR should be followed when you operate EU citizens’ data from any part of the world.
However, they need some local authority to actually enforce the law and that’s what Privacy Shield offers.
I’m in the EU, do I need to worry about Privacy Shield certificates?
Yes, but don’t get one.
Your U.S. business customers will apply for their Privacy Shield certificates. To be certified, they must ensure that all services that store their customers’ personal data are either under the Privacy Shield or GDPR.
Here lies a problem – even though the directive is active, the transition period is still on.
If your U.S. customers require more proof you too can use standard clauses, as explained in next chapter.
Even though the government form for applying Privacy Shield in U.S. has country fields, you cannot get the certificate as you’re not under the jurisdiction of the U.S. FTC.
I’m in Australia/Russia, what should I do?
Like EU businesses, you aren’t able to apply for a Privacy Shield certificate from the U.S.
As your U.S. business customers apply for their Privacy Shield certificates, they’ll want to ensure you have the privacy protection in place. Your European business customers will also want to make sure you’re GDPR compliant.
The European Commission’s Standard Contractual Clauses are still valid after the introduction of Privacy Shield and you can use them. Lexology explains how to use the contract templates.
I’m in the U.S., Should I get the Privacy Shield certificate?
If you’re selling to European businesses or businesses who have European customers, Privacy Shield certificate makes things easier and prevents you from losing those customers as they prepare for the GDPR. The certificate pricing is based on your revenue. For most of you reading this it’s either $250/year or $650/year.
Some businesses are still standing by, waiting to see whether or not the Privacy Shield will hold on. It could be invalidated like Safe Harbor was.
The European Commission formally approved the “adequacy” of the Privacy Shield on 12 July 2016. On a more recent meeting on the 7-8th of February 2017, the European Commission validated Privacy Shield again. Whether or not it will hold in court, we don’t know yet.
But as others are getting certified, you’ll need some way to proof that you’re safe. Even though it’s possible with standard contractual clauses, getting the Privacy Shield certificate is a clear cut and cheap solution.
What happens if I break the rules?
In the U.S. the fines are considerable too, with $40,000 per violation, or per day if the violations continue. Also, I found some mentions about publishing a list of certificate violations into a “Federal Trade Commission wall of shame”. So only apply for Privacy Shield certificate if you actually plan on following the rules, as you still have the option to wait.
So what are the rules?
The GDPR and Privacy Shield are designed for the era where security breaches are not just possible, but inevitable. Breaches can happen no matter how we prepare and the attacker can be anyone from our own employee to government agencies.
Because of this, the rules require “data protection by design” and fast reporting (in 72h) in case of breaches.
Data protection by design is based on seven high-level foundational principles:
- Proactive not reactive, preventative not remedial
- Privacy as the ‘default’ setting, not as opt-out
- Privacy embedded into design
- Full functionality: positive-sum, not zero-sum
- End-to-end security: full lifecycle protection
- Visibility and transparency: keep it open
- Respect for user privacy: keep it user-centric
In addition to this, the old recommendations are still valid:
- Notice: people should be given notice when their data is being collected
- Purpose: data should only be used for the purpose stated and not for any other purposes
- Consent: data should not be disclosed without the person’s consent
- Security: collected data should be kept secure from any potential abuses
- Disclosure: people should be informed as to who is collecting their data
- Access: people should be allowed to access their data and make corrections to any inaccurate data
- Accountability: people should have a method available to them to hold data collectors accountable for not following the above principles
This means that we not only need to update and improve our practises and Privacy Policies, we need to change our actual design and implementation to protect data. While it’s still a bit unclear what all will be required, I’ll go through some examples of what actions SaaS owners are taking based on what we already know.
What does this mean in practise?
Don’t collect personal data at all, or collect just what you need
Personal data does not mean just identification data like emails. Also e.g. IP address of the user is considered personal data. A collection of otherwise non-personal details can become personal data if there’s enough of it. It’s out of the scope of this guide, but there are also special rules for handling genetic and biometric data, like person’s gene sequence, fingerprints and retinal scans.
I’ve had the privilege to work with Envoy, a SaaS that keeps track of who visits your office. Obviously, this data is personal and it’s important enough to interest government agencies. So Larry, the founder, decided to get rid of their customers’ data altogether. When someone comes asking for it, they can just say “we don’t have it”. This is a perfect example of data protection by design.
Clean up and remove all the data you no longer need, encrypt what you can’t get rid of
Here’s what I do in FirstOfficer.io. When a customer leaves, an automatic process cleans up the data. It’s a best practise not to remove the whole Stripe customer, so the process removes the card tokens and everything else except two identification details that I need to collect for VAT reporting. It also cleans pretty much everything in FirstOfficer’s own DB, leaving behind just a crippled stump of a user record that the attacker would have no use for.
This does cause me troubles sometimes when a customer want to come back or cancelled by accident, but it’s a small price for what I gain in security. I just throw away everything I can, as soon as I can.
Encryption of the data is recommended, but it does not lower your obligations in any way at this point. It may be taken into consideration though, if you have to go to court for a violation.
FirstOfficer encrypts the dangerous data – not just the user passwords. This way, the attacker needs to get access to both DB and the encryption tokens. And even then all they can do is view the data, as FirstOfficer has only read-only access to my customers’ Stripe accounts.
Be transparent in your policy documents
It’s very human-readable and it goes through everything, cookie by cookie. It explains what cookies get installed and what data gets collected by Thinglink and what the 3rd party apps are collecting. It also describes how long each cookie will live.
In addition, users should not have to opt-out of their data being used, they must opt-in to your systems. So we should use the cookie and personal data collection notifications (popups), but even in Europe this is considered as a major annoyance. Hopefully something else will replace that before May 2018.
When attacked, report fast
If your system is attacked and data gets compromised, you have 72 hours to tell your customers and everyone who needs to know. This is one of the focal points in the new law, enforced with massive fines.
The law says there should also be some automatic mitigation of the attack, but what that actually means it yet to be seen.
I warmly recommend Heroku, especially for business owners in non-U.S. timezones. When Heartbleed vulnerability was found, I was already offline for the day and Heroku literally saved my ass. They pulled the plug from FirstOfficer. When I woke up in the morning, everything was down and I was safe. That really earned my respect by doing that and the cost savings from moving away are not worth the loss in security.
Let people access what’s theirs
Transparency requirements give rights to the people whose data is stored in your system. If they want to see it, they have the right. If they want to change it because it’s inaccurate, they have the right. If they want to “be forgotten” and remove their data from your system, they have the right. They even have the right to request you to give their personal data to your competitor.
When such a request or complaint arrives, you have 45 days to solve it.
Don’t give data to untrusted partners
You’re responsible both for the data you store and the data you give forward to the tools and services you use.
I know fellow European SaaS owners who have already been limiting their use of U.S. Services, thinking that they will have less headache with these regulations when the data physically stays in EU. However, I found references that even just accessing your systems through API or user interface could be in some cases (like in HR systems) considered moving data to U.S.
We should not let these directives and regulations bully us from using services around the globe. What we must do is to check that our partners take action to protect the data.
There are 3 ways to make sure it’s safe to give data to someone:
- They have the Privacy Shield certificate
- They have signed and valid standard contract clauses agreement
- They are a corporation with adequate corporation rules in place
Here you can see the benefit of the Privacy Shield – it makes so much more easier to check that someone should be trustworthy. No reading and writing contracts.
When businesses will start checking for Privacy Shield certificates, it’ll be a cascade of the larger ones going first. At that point it’s a clear benefit to have the certificate. And if you’re in EU, you still might want to add a mention about it, just to make it clear you’re compatible without the certificate.
How do I check that someone has a Privacy Shield certificate?
That reference includes a link to Privacy Shield certificate owner list. Use the search on the top of that page to find the actual certificate.
The companies are registered with their business name and the search isn’t very intelligent. For example, you’ll have to search for Rocket Science to find MailChimp’s certificate:
Yes, they do have “MailChimp” in the certificate name, but at the time of the writing the search just doesn’t work properly.
How do I get certified?
Feel free to discuss in the comments and please let me know if any new information arrives that conflicts this guide.