I’ll start this post in the same way every blog post about GDPR starts: by saying, in capital letters, that I AM NOT A LAWYER. No seriously, I hope this post will be helpful to those who are trying to figure out what they need to do about GDPR. But you should definitely, absolutely, talk to a lawyer. There is simply no way you can do this yourself.

With that disclaimer out of the way… We’ve been working on getting ready for the EU General Data Protection Regulation (GDPR) for the past few months, and have made significant progress in advance of when the law goes into effect on May 25, 2018. We had to make some interesting decisions and trade-offs along the way, especially since we’re a small company without legal counsel on staff. I wanted to share a few thoughts on what we learned along the way to becoming GDPR compliant, with the hope that it will help streamline the process for your business.

Side note: if you're a US company with no EU presence and you're wondering if you should care about this, the answer is YES. Even if you don’t care about it, your EU customers do, and it will affect whether they use your product. From a purely legal perspective, if you process EU citizen data, which will be [checks clipboard] pretty much every company, this law applies to you.

If you're a US company with no EU presence and you're wondering if you should care about GDPR, the answer is YES.

First, it’s important to note that this is not just another obscure privacy law that you can ignore. TechCrunch accurately describes the law as “Data protection + teeth”. Karen Cohen wrote a very succinct summary of what this means for you:

Businesses that are not compliant may get sanctioned up to 4% of the annual worldwide turnover or fined up to € 20M (the higher of the two), per infringement. If your company processes any information of EU citizens you should start paying attention.

TLDR; When you collect data linked to a citizen of the EU, they are entitled to know what data is kept, for what purpose, and for how long. Users are entitled to access (“Right To Access”), export (“Right to Data Portability”), change, and permanently delete (“Right To Be Forgotten”) all their data from your systems (read more here). They should be able to access their data as easily as they entered it in the first place.

Changes every company will need to make to become compliant with GDPR include (but are not limited to):

• Updates to your Privacy Policy to indicate what information you store about your customers, and how you’re using it.
• Changes to your sign-up process to ensure explicit consent is given to collect this data (no more “by clicking on this button you agree to blah blah blah” shenanigans).
• Have a process in place to respond to DSR (Data Subject Rights) requests such as exporting or deleting customer data.
• Make sure that appropriate data security is in place to prevent unauthorized access to customer data (GDPR calls this “Data protection by design and by default”), and make these security measures abundantly explicit. This includes binding commitments on what you’ll do if a data breach occurs. In most cases this will require you to have a Data Processing Addendum (DPA) in place with your customers. (Spoiler: you might find this to be the most time-consuming and expensive part of the process.)

In our case we put together a dedicated EU Privacy Page to address each of these issues, as well as answer the most common questions our customers have been asking us. Let’s step through some of the most important aspects you’ll need to address.

Privacy Policy and explicit consent #

The GDPR Alliance posted a nice overview that explains exactly what the new law requires with regard to personal information:

• Requires that consent is given or there is a good reason to process or store personal information.
• Gives a person a right to know what information is held about them.
• Allows a person to request information about them is erased and that they are ‘forgotten’ — unless there is a reason not to do this — e.g. a loan account.
• Makes sure that personal information is properly protected. New systems must have protection designed into them (“Privacy by Design”). Access to data is strictly controlled and only given when required (“Privacy by Default”).
• If data is lost, stolen or is accessed without authority, the authorities must be notified and possibly the people whose data has been accessed may need to be notified also.
• Data cannot be used for anything other than the reason given at the time of collection.
• Data is securely deleted after it is no longer needed.

This will most likely result in two fairly major changes for most companies.

Privacy policy #

First, you will need to adapt your Privacy Policy to explicitly indicate what data you collect about users, what you use it for, and who is allowed to access it. You also need to indicate how the data is secured, and what the process will be if a breach happens. You can see our version of these changes in our Privacy Policy here.

I want to stress this again: you will need a lawyer for this part. There is no way you can just wing these changes. The penalties for getting it wrong (or providing misinformation) are huge.

Explicit consent #

Second, no more of this:

Going forward, you will have to get explicit agreement to your Terms of Service and Privacy Policy from customers. To be more specific and way more wonky… You will need to:

• Place an unchecked check box next to the call-out line regarding the Terms of Use and Privacy Policy. Customers will need to check this box before they sign up for an account. Companies (including us) have been using just a button without an explicit checkbox. This was even recently accepted in a case involving Uber. However, that approach carries with it a lot of risk. The Uber case is an appeal and the same presentation was rejected in the previous iteration of the case.
• Have each of "Terms of Use" and "Privacy Policy" be a hyperlink to the relevant page. Make sure the relevant page opens up in readable format and can be saved / downloaded if the customer wants.
• Put the "Register" button right underneath the call-out line so that it is not possible to miss (see our example below).
• Retain the following information in connection with each clickthrough so you can prove you acquired consent properly: who consented, when they consented, what they were told at the time (terms and policies they agreed to), how they consented, and whether they have withdrawn consent (and if so, when).

In short, this is the new normal for your app:

Data protection and cross-border transfers #

Like many companies, we put a lot of our hope in the EU-U.S. and Swiss-U.S. Privacy Shield Frameworks. Certification through this framework was supposed to solve all our cross-border data transfer problems. And in theory, it does. Privacy Shield is a mechanism jointly implemented by the European Commission and the US to enable companies to lawfully transfer personal data of EU residents to the US. The problem is that Privacy Shield is subject to legal challenge, with critics claiming that it does not fully protect the fundamental rights of individuals provided under EU privacy law.

So I'll tell you this. It might be the law, but I have spoken to very few EU companies who equate the legality of Privacy Shield with the “enoughness” of Privacy Shield. To put it another way: nobody trusts this thing. So even though we are certified under Privacy Shield, we realized pretty early on that we were going to lose a lot of customers if we didn’t also put something more rigorous in place.

Enter Data Processing Addendums (DPAs) and Model Clauses. The DPA offers contractual terms that meet GDPR requirements and that reflect a company’s data privacy and security commitments to their clients. And since Privacy Shield is not considered “enough” by many companies, the EU Model Clauses add standardized contractual clauses to the DPA to ensure that any personal data leaving the EEA will be transferred in compliance with EU data-protection law.

Here’s the hard truth about DPAs: they’re expensive. Right now every company is scrambling to create DPAs and be the first out of the gate to get them signed with all their customers. If you’re on the receiving end of this, you’re going to have to spend a lot of legal fees to get each DPA reviewed as it comes your way.

For a small company like ours, that is simply not possible. So we made a tough call on this one. We don’t sign other companies’ DPAs, and we don’t allow companies to make any changes to the DPA we created. We understand that we might lose a few customers because of this. But the cost of a lost customer is way less than the cost of passing every change to our lawyer and having a back-and-forth about it with the client (not to mention the cost of maintaining multiple versions of this thing). Here is how we explain this to our customers:

To ensure no inconsistent or additional terms are imposed on us beyond that reflected in our standard DPA and model clauses, we cannot agree to sign customers’ DPAs. As a small team we also can’t make individual changes to our DPA since we don't have a legal team on staff. Any changes to the standard DPA would require legal counsel and a lot of back and forth discussion that would be cost prohibitive for our team.

In short: our DPA sets out our privacy and security practices (which are geared toward satisfying GDPR requirements). We are therefore not going to make any changes to it, because we’d be promising things we don’t do (which, you know, you definitely shouldn’t do in a legally binding contract).

So here’s my advice for small companies: Spend a lot of money upfront on a good lawyer to get a really good DPA in place. And then stick with it.

We went a step further with this. On our EU Privacy page, we allow customers to sign our DPA electronically. This has been another huge time saver for us. But not just that, it shows our commitment to Privacy, Security, Customer Success, and GDPR in particular. It might be a boring page, but it’s my favorite Postmark “feature” in a long time.

Data Subject Rights #

Data Subject Rights (DSR) is a big topic in GDPR, but for most SaaS apps it will be related to two main things: the right to be forgotten (delete) and the right of data portability (export). For delete requests, all personal data must be deleted within thirty days of receipt of the request. For export requests, customers require all personal information that is held for more that forty-eight hours to be easily accessible upon request.

Since our customers typically have customers of their own, some of our customers have asked us for a new API endpoint to service delete and export requests so that they can easily fulfill DSR requests with multiple vendors. This is obviously a big investment, and for the moment we have opted not to do that. The truth is we simply don’t know how many of these request we will receive.

GDPR law states that DSR requests have to be fulfilled within 30 days of the request being received. So we are committing to our customers that we will respond to their DSR requests without undue delay, thus enabling them to respond to their customers who have made this request within the 30 days required by GDPR. That should give our customers plenty of time to respond to their customers if/when they receive such requests.

Whatever way you choose to go, this is another important aspect to thing through for GDPR.

We’re in this together #

The other day I tweeted that this appears to be every company trying to get ready for GDPR right now:

It’s true that we’re all stumbling around a little bit. But it’s also great to see so many companies take this law seriously — as they should. My sincere hope is that this post contributes a little bit to the discussion, and helps some of you figure out what you need to do to prepare for this law to go into effect.