GDPR in the age of SaaS: One SaaS vendor’s journey to compliance

In an effort to expand the privacy rights of EU individuals, the EU General Data Protection Regulation (GDPR) places new obligations on any organization, no matter where it is based, that markets to, tracks or handles EU personal data. As you can imagine, the GDPR is the compliance talk-of-the-town for any company doing business in the European Union (EU) or, in fact, any organization that might have EU personal data within its databases.   

About GDPR 

GDPR is clearly the biggest compliance-related regulation to come along in years, replacing the Data Protection Directive 95/46/EC (“Directive”) and substantially increasing data subject rights and privileges. The GDPR was finalized on April 14, 2016 and goes into enforcement in less than a year, on May 25, 2018. GDPR will have a global reach. Even if a single SaaS subscriber is based in a non-EU location and the SaaS application is based in a non-EU location, there could still be data-subjects that patronize the subscriber that are located in the EU and therefore cause the subscriber to become beholden to the regulation. 

GDPR Advice for SaaS Companies   

As a company who provides SaaS data protection for Office 365, G Suite, and Salesforce; we knew we needed to be GDPR compliant to maintain that leadership. Our journey to GDPR compliance is highlighted by key requirements and concepts - but before we delve into our specific journey, let’s take a deeper dive into the use cases and implications of GDPR for IT teams running SaaS applications. 

As more and more companies adopt SaaS applications for business/enterprise use, the world of regulatory compliance becomes a lot harder to achieve. End-users of these new, versatile and highly-scalable applications no longer maintain responsibility of these applications in their entirety. In the past, administrators had to configure almost the entire application and manage ancillary components like storage and transmission systems; now this responsibility rests with the SaaS vendor.   

Enter GDPR. With the spectre of the deadline looming, the major articles of concern are either going to have to be met with a technical or procedural solution. Complicating the challenge for SaaS companies is the lack of case law to refer to for guidance. These companies need to make sure they are working within the confines of the regulation to meet intent, and make sure that scope is clear about what we can or should do to meet compliance. Without any case law, companies are not easily able to navigate the complexities of how far data-subject rights should/could impact their business models. This will be something to consider when constructing solutions for SaaS applications and the data they control/process. 

GDPR presents some open questions that could impact every facet of IT. Specifically, questions surrounding how data is received, processed and stored. IT organizations need to start by doing a detailed mapping evolution that identifies all types of data that could be relatable back to a data-subject. On top of that mapping process, it’s equally important to understand how that data comes into an organization (encryption, 3rd parties, etc.) and how that data is stored. 

SaaS subscribers (single user/domain admins) need to understand who is responsible for compliance. An interesting concept of GDPR is that it is no longer just the data controller (primary data holders/managers/subscribers) applications that are responsible for adhering to these requirements. Data processors are now accountable as well for partial compliance, as well as coordination with the controller in their efforts to comply with GDPR. 

Subscribers and their data-subjects will have to start evaluating where their data resides as well, and I’d recommend they make sure that backup SaaS applications are at the top of the list. Integration with their primary SaaS application, while convenient, will present situations where consent of the data-subject is key. Can the data-subject consent to the controller using a 3rd party processor, or does the data-subject have to consent to the entire “stack” of processing individually? These are questions that have not been answered yet and, as stated before, no case law exists for guidance. 

Here are a few key requirements for any company who may be impacted by GDPR:

  1. Data Protection by Design and by Default - Your security and engineering teams should be working together to ensure that design processes are in place to meet compliance with this requirement of the GDPR.  
  2. Right to Erasure (“Right to be Forgotten”) – Perhaps the most well-known component of the new GDPR laws, companies need to evaluate technical and/or procedural solutions to satisfy this requirement of the GDPR.  
  3. Designation of a Data Protection Officer – Based on the type of data your company processes, you may be required to fill this role.    
  4. Contractual Agreements/Consent – Your company may need to update your Master Subscription Agreements (MSA) and/or create addenda to existing agreements in place to comply with the GDPR.  
  5. Data Security Policy – All Data Security Policies should comply with the GDPR.  
  6. Incident Response Plan – Companies should maintain an incident response plan that is reviewed annually.  
  7. Data Transfers – Companies should verify that they are EU-U.S. Privacy Shield certified and should they have the ability, can utilize the EU Model Contractual Clauses where appropriate to meet compliance to this requirement.    
  8. Privacy Policy – Your current privacy policy should be modified/updated to comply with the GDPR.  
  9. Coordination with Data Controllers – Partnering with your customers and data controllers to meet coordination compliance to the GDPR is essential. This could be a technical or procedural solution and is under current review.  
  10. Sensitive Data and Sensitive Data Processing - With respect to marketing and first contact data, companies should determine how to create agreements with controllers/customers to get “opt-in” consent from data subjects for processing.  
  11. Data Retention - Your Master Subscription Agreements should state data retention policy with respect to when it begins and what happens to data when the contractual relationship is terminated. 

As a SaaS company, we will initially be looking at the following items: 

  • Continue mapping our incoming and outgoing data flows, and granularly account for specific data types.  
  • Determine what data is solely meeting a processing function, and where Spanning is considered a controller of data.  
  • Coordinate with platform partners Google, Salesforce, and Office 365.  Work with our subscriber customers via surveys and/or focus groups to get a better understanding and acceptance of what compliance means to them.  
  • Develop an internal process and solution to meet our customers’ needs while complying with the intent of the regulation. 

We thus begin our journey by formulating a compliance solution that makes sense for our customers and our business model. In this way, in partnership with our customers and our platform providers, we will be GDPR compliant by May 2018. 

Brian Rutledge, Principal Security Engineer for Spanning 

Image Credit: Wright Studio / Shutterstock