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.


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.

When your U.S. based SaaS has a Privacy Shield certificate and a matching Privacy Policy, the businesses in EU can be sure that they are not breaking the law when they use your service.


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.

The businesses in EU have reasons to comply and they pull the U.S. based B2B businesses along. The consumers don’t have any incentive - they just have new rights that EU claim to be world-wide no matter what your Privacy Policy is.

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.


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.

Unless you add some kind of a statement about Privacy Shield to your Privacy Policy, the U.S. businesses looking for Privacy Shield information will assume you’re not certified and thus unsafe. The GDPR prefers readable language, so it’s fine to add a section where you explain how compliant you are.

Here’s what I added to’s Privacy Policy. It’s far from perfect, but it states the current situation. The rest of my Privacy Policy is not yet updated to be GDPR compliant, so I’ll give you other examples later in this guide.

Here’s how Stripe explains their missing Privacy Shield and their usage of standard clauses.

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.


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.

Just make sure to use the words “Privacy Shield” in your Privacy Policy chapter where you explain the situation. People will be searching for that string.


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.


In the EU, businesses face high fines for breaking the GDPR - up to €20 million, or 4% of their global annual turnover. That means that European businesses will actually be reading your Privacy Policy pages carefully. This law is something European businesses cannot opt out.

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.


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.


If you can, don’t collect personal data. Collect only the data you need to provide your service. Get rid of the data as soon as possible. If possible, encrypt the data. Be transparent in your Privacy Policy. Allow people to “become invisible” and access their data. Use partners and service providers that have the Privacy Shield certificate or check out their standard contract clauses.


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.


Here’s what I do in 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.


The new law also requires that we state in the Privacy Policy what data we are going to collect and how long are we going to keep it. To get an idea what kind of a level of transparency we are talking about, here’s an example from Thinglink’s Cookie Policy.

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 to cookies, you should similarly report all personal data you collect in your Privacy Policy. The Privacy Policy must also contain your business name and identification. It must be intelligible and easily accessible, using clear and plain language that is tailored to the appropriate audience - people will actually read your privacy policies.

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.


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.


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.

So what are people doing in practise? Most people are adding instructions on how people can ask for their data to their Privacy Policy. It’s usually done by asking people to email the company. However, some SaaS owners who expect a lot of inquiries are building an user interface that allows people to claim their data and make changes themselves.


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:

  1. They have the Privacy Shield certificate

  2. They have signed and valid standard contract clauses agreement

  3. 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.


Search their Privacy Policy page for “Privacy Shield”. They will have a standard format reference to their Privacy Shield certificate if they have one.

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.


After you fulfil the requirements and have your new Privacy Policy page up, you can self-certify at the Government Privacy Shield pages. It’s a 9-part online wizard where you select the official who will make sure you follow the rules, give link to your Privacy Policy and pay the annual fee.

Feel free to discuss in the comments and please let me know if any new information arrives that conflicts this guide.

Start saving today and get the latest finance tools

Start saving today and get the latest finance tools

Start saving today and get the latest finance tools