Data Breach Accountability for Software-as-a-Service Vendors

Published on
room filled with servers

So, you have the next big thing in SaaS platforms, or you’re thinking of becoming the next SaaS unicorn with your unique idea. You’ve found a business need that your amazing SaaS is resolving, better (or cheaper) than the competition is doing today. So, you start to design your platform, together with a talented team of engineers, in order to get an MVP on the market as soon as possible. You also contract some legal support, to draft some customer agreements, terms of service and the infamous Data Protection Agreements.

And this is where most SaaS platforms up: understanding the accountability game

Let’s make a step back and take a bird's-eye view on the SaaS platform itself. Since it offers digital services to its customers, it processes data. Most of the data is personal data. So, it is regulated by UK GDPR, EU GDPR, and other personal data processing laws from the countries where your customers are located. This means that you, as a SaaS vendor, you are a personal data controller, a joint data controller or a personal data processor.

Usually, for different processing operations you have different roles. For example, when you process personal data of your employees, you are a personal data controller. When you process personal data of your customers as part of the customer journey – lead generation, lead nurturing, sales, post-sale (upgrades, consultancy and support), testimonials – you are a personal data controller. But what happens when you process personal data on behalf of your customers, as part of SaaS platform operations?

Recommended role: Data Processor

As a SaaS platform vendor, the best advice is to position yourself as a Data Processor, processing personal data on behalf of your customers. Thus, you limit your liabilities as Data Controllers are accountable for how they process personal data (Article 5 UK/EU GDPR – Principles relating to processing of personal data; Article 24 UK/EU GDPR - Responsibility of the controller). However, you must renounce at your autonomy – you must cease capturing telemetry data, monitoring customer behaviour, etc. This is something that came out pretty clear in the Data Protection Impact Assessment done for Office 365 in 2019 and repeated in 2022, in Netherlands. Microsoft had to make significant changes to its Office SaaS platform in order to be able to operate in the Public Sector space.

If you want to retain your telemetry and monitoring technologies (like Google), you might be Data Controller or Joint Data Controller and you would need to clearly establish accountability for the personal data you process. In every step of the processing operations, you must determine who is accountable – the SaaS company or the customer? Your liabilities increase exponentially, but you have better control. However, good luck selling something like this to customers who want to retain control of the data.

A personal data breach occurs; who does what?

So, let’s say you experience your worst data breach scenario: full capture of all customer and internal data, with complete exposure on the internet. In parallel with the efforts to contain the breach, you must notify the data controllers (for the personal data for which you act as a Data Processor). Yes, all of them. “Without undue delay” – this is a quote from GDPR (Article 33 - Notification of a personal data breach to the supervisory authority). Also, “without undue delay”, you must determine whether you should inform the relevant supervisory authority (if there are risks towards the liberties and rights of the affected data subjects), for the personal data for which you act as a data controller. Within 72hrs from the data breach detection, you should inform the supervisory authority, if you make this decision.

Now this is where things become interesting. First, you must understand for which personal data you are acting as a processor and for which personal data you are acting as a controller. This means having documented the Records of Processing Activities (ROPA), per Article 30 in GDPR. You must understand all the personal data flows and have a complete understanding of your personal data maps. Based on this, you must understand what personal data has been exposed from each one of your customers.

And yes, you must inform them even if you decide (for the data for which you are accountable, as a personal data controller) that you won’t inform the relevant supervisory authority. It is their decision, as data controllers, to inform or not their relevant supervisory authorities.

Who pays what?

A data breach is very expensive. I cannot stress enough how important is to choose the best technical and organisational measures (including the vendors you are working with) in order to reduce the data breach risks to a minimum. The moment you cut corners, your business is set to fail.

Each Data Protection Agreement between a customer and a SaaS vendor acting as Processor should have a dedicated Data Breach chapter. This chapter should detail the deadline in which a breach should be reported to the customer, assistance provided by the SaaS vendor and indemnification. As every legal agreement, the content of this chapter is subject to business negotiations, depending on the sensitivity of the personal data processed in the SaaS platform. And the content of this chapter can help a SaaS survive or die, in case of a personal data breach.

As I previously said, as a SaaS vendor acting as a personal data processor for its customers, you should inform all of them in case of a data breach affecting all of them. They might have to inform the relevant supervisory authorities, which in turn might order corrective measures and apply significant fines. Moreover, affected data subjects might sue your customers in order to get financial compensation.

Although you might receive a smaller GDPR fine (if you are a data processor), the burden of indemnification might kill your business if it is not carefully handled. And this is where the Data Protection Agreements come in.

Tips to handle indemnification in Data Protection Agreements

First of all, you will not be able to avoid indemnification if you act as a Data Processor for your customers. You might try to, but you will end up losing your biggest customers who understand the value of indemnification. However, here is what you can do (and should do):

·         Purchase a cybersecurity insurance to cover your data breach risks. Of course, the insurance will require you to take some drastic cybersecurity technical and organisational measures (and if you don’t take them, the underwriters will kill any claim), but you will be covered for most risks.

·         Negotiate a financial compensation calendar as part of the indemnification requirement. Thus, in case of a data breach, you might not end-up paying hundreds of thousands of pounds in one payment, but spread it in several payments for a longer period of time.

·         Make your employees accountable by enforcing policies, procedures and having them sign data processing addendums to their labour contracts. Train them regularly in order to reduce data breach risks.

·         Train your customers on how to use your platform, in order to reduce data breach risks coming from the customers.

·         Delete or return customer data once the customer leaves. You have no idea how many data breaches occurred on old, undeleted personal data coming from former customers.

Join 34,209 IT professionals who already have a head start

Network with the biggest names in IT and gain instant access to all of our exclusive content for free.

Get Started Now