Last week we hosted a webinar covering everything a SaaS company needs to know about complying with GDPR. To be a bit more precise, we covered everything we could during a webinar running a little more than an hour. The GDPR is a complex and vast set of regulation that impacts much of how modern SaaS companies operate. Covering it all in a short webinar was tough.
That said, we’ve distilled the most salient notes in the blog post below. Don’t hesitate to skip ahead and watch the actual recording or grab the transcript and slides, all of which you’ll find in our resources section.
And if you still have questions, please join us in our GDPR Slack community, where 300 of us are discussing how to comply with GDPR.
Aptible has had the opportunity to help hundreds of SaaS companies build robust data protection programs that pass compliance audits, and we’ve worked with many of them to ensure they comply with GDPR.
Our team is made up of software developers, attorneys, and privacy experts who’ve achieved CIPP/E certification (that’s Certified Information Privacy Professional/Europe). In many ways, there’s a lot that’s “TBD” with GDPR, but we’ve done everything we can to ensure we’re ready to help SaaS companies comply.
GDPR stands for the General Data Protection Regulation. It is a federal law that regulates the personal data and privacy of European Union (EU) citizens.
GDPR consists of 99 Articles and 173 Recitals. The Articles are more prescriptive and the Recitals tend to provide more context to an issue and include examples.
The overarching goals of the GDPR are to:
Give control back to EU citizens and residents over their personal data, promote human rights such as the right to privacy
Simplify and harmonize the regulatory environment for international business by unifying regulation within the EU
Address the export of personal data outside the EU
GDPR applies to all member states in the European Union. Member states (or countries) cannot have laws that are less protective than GDPR. They can implement laws that are more protective. GDPR sets the baseline for privacy and data protection.
The foundation of viewing data protection as a component of human rights goes back at least 70 years, to just after WWII. GDPR is very similar to the EU’s 1995 Data Protection Directive, so there is a recent history of guidance to rely on that helps inform our understanding of GDPR. The regulatory environment will continue to evolve as the EU replaces the ePrivacy Directive with an EU Regulation, binding in all member states.
Under Articles 2 and 3, GDPR separates scope along two dimensions:
Material Scope - Article 2 states that GDPR applies to the processing of personal data, or individually identifiable data, broadly construed. Not just product or customer data, but also your HR processes, marketing/sales, etc.
Territorial Scope - Article 3 states that GDPR applies to any organization established in the EU, targeting the EU markets, or profiling/monitoring EU data subjects.
But in the broadest terms, if the “go to market” for your business has anything to do with processing personal data for natural people located in Europe, you should be thinking about GDPR. Of course, there are exceptions and nuances, so it’s always best to consult with your own lawyer to determine applicability.
During the webinar, we focused on four key areas of a SaaS business that GDPR impacts. We flagged key issues that SaaS companies will need to address in order to ensure compliance with GDPR. The key takeaways are summarized below.
Most US-based growth teams have never had a specific regulatory security/privacy regime to deal with, so GDPR is a game-changer. If you know you have EU customers (B2B or B2C) in your pipeline, GDPR and the ePrivacy Directive make direct marketing harder. Some of the fundamental tactics of modern growth marketing, like email capture, email marketing, analytics, and paid advertising are complicated by the need to obtain consent before you use an EU data subjects’ email or track them.
What this means is that you need to maintain a source of truth containing information about what you can and can’t do with your users’ data. For each user, have you obtained consent to send them marketing emails? How about consent to track them? When did you obtain this consent?
For most companies, this will likely take the form of a master suppression list, at least to start. But down the road, we suspect that tracking this information will be better accomplished with a fully customizable CRM-like software, or perhaps an integration with an existing CRM like Salesforce.
Marketing and sales teams are notorious for using scores of tools, enabling data flows between systems and vendors without so much as a second thought. But this mode of operation needs to stop, or at least slow down just a bit. Complying with GDPR means that every vendor who you work with—from chat apps such as Intercom and Drift to analytics tools such as Mixpanel—need to be vetted for GDPR compliance. In many cases, this will mean signing some sort of data protection agreement with the vendor. Without such an agreement, sending data across to a vendor may constitute a reportable breach!
(Side note: a formal vendor management process would help here, which is something that our product Gridiron can help you to implement. Get in touch if you’d like to know more.)
Engineering teams are generally used to thinking about customer data as potentially sensitive, which is a good start. However, under GDPR it’s up to engineering to ensure that you either provide the capability to respond to data subject requests (in other words, requests like “remove my data from your systems”) or the tools to allow your customers to handle these requests.
Whether you need to handle the requests yourself or provide the tools to your customers breaks down along the lines of data controller vs. data processor, an important distinction in GDPR. The distinction is decided based on how the company uses data:
Data controllers decide on what data should be collected and what to do with it
Data processors just provide tools to help data controllers make use of the data they collect
Many SaaS companies like Slack and GitHub are arguing they are purely processors. This makes sense, given that the requirements placed on processors are substantially less onerous than those placed on controllers.
Realistically, however, most SaaS companies are going to be both a processor and a controller, especially if they are B2B. B2B SaaS companies give their customers tools to process data (thus they are processors); they also collect and use data about their customers (thus they are also a controller). Accordingly, we expect to see pushback from the EU on large SaaS companies who argue that they are data processors, only.
Regardless of whether you are a data controller or data processor, engineering teams need to think broadly about how they will protect their customers’ data, in order to maintain GDPR compliance. There’s significant surface area to protect, and the best engineering teams will implement processes to allow them to consistently enhance security.
The tl;dr on data protection is to take control of the data your organization collects and uses, wherever it goes. Personal data can leak in unexpected ways, such as into logs (which can be sent to logging providers like Papertrail), events (which can be sent to monitoring tools such as New Relic), or errors (which can be sent to error tracking tools such as Sentry).
Some of the keys to compliance here are:
Being able to provide design specs and other requirements documentation that show that security and data protection were taken into account
Ensuring that all vendors are vetted for data protection capabilities and, in nearly all cases, data protection agreements are signed
(Here again, our product Gridiron can help, with both ensuring you are implementing appropriate security controls and, of course, maintaining a vendor management program. Get in touch to learn more.)
GDPR and the ePrivacy Directive restrict how support and success (upsell, expansion, retention, etc.) teams interact with customers. You can’t just send a user an NPS survey, for example. You still have to collect their consent—something that you may want to ask for at some point during onboarding or perhaps after they enter their credit card number.
You can of course email customers for anything that is critical to the functioning of your software (in other words, for the fulfilment of your contract with that customer). Billing emails, password resets, support requests and the like are all probably strictly necessary for you to fulfill your contract with them.
But as soon as emails trend towards marketing, such as a re-engagement, a cross-sell, or upsell, these will be treated as marketing and will be subjected to the same standards of consent. This probably goes for onboarding emails too, though the line is fuzzy. In any case, it’s important to let your customer know what to expect ahead of time and provide opt-out opportunities, both up front and within every email.
This also applies to product research emails, such as surveys or NPS scores. Sending these emails benefits you more than the customer, and so it is essentially treated as marketing and subject to the same constraints.
Certainly HR teams already worry about keeping certain employee data private, such as salary or performance reviews. Under GDPR, it’s important to protect all personal data about EU employees, prospects, and recruits. The entire vendor stack: your applicant tracking system and your productivity tools, must be vetted for GDPR compliance, meaning putting in place a data protection agreement. (Here again, a real vendor management process would help.)
Pre hire, some EU jurisdictions make it illegal to even request a background check. Make sure you’re clear on what you can and cannot ask from applicants before asking.
Post hire it’s critical to have an employment (or consulting) agreement in place, because that agreement allows you to process the employee’s personal data.
Any company that is subject to GDPR should be aware of the potential employee embarrassment that could arise from BYOD policies. If there’s a breach of any kind, there’s serious potential consequences for failing to respond appropriately. Responding appropriately means that all employee devices that have contained work-related data will be confiscated and reviewed, potentially disclosing embarrassing personal information.
Any workforce monitoring that happens can trigger serious consequences under GDPR. If you have super admin privileges, reading someone’s email “because you can” or flipping on web monitoring (intentionally or not) is looked upon particularly unfavorably.
There’s much more to learn by watching the webinar, so grab it in our resources section.
If you still have questions, please join us in our open GDPR Slack community.