If your business offers a B2B-SaaS platform chances are high that you offer integrations with other services to your customers (usually via ‘API’). In our experience offering integrations can sometimes lead to awkward data protection discussions with customers about what your responsibilities are and what contracts need to be in place. However, in our view there is a (somewhat) easy solution.
Controllers vs. processors
Before we get started with the nitty gritty, we need to sort out some GDPR basics: figuring out who is a controller and a processor. Spoiler alert: it's quite tricky.
Controllers are organizations that (quote GDPR) "determine the purposes and means of the processing". In simpler words, they decide which data gets used for what reason. The determine the "how" and the "if" of data processing if you will.
Processors only handle data on behalf of and subject to controllers' instructions (as per the data protection agreement "DPA").
That said a B2B SaaS provider will usually assume the role of a processor as the customer decides how to use your tool to process their (customer) data.
In reality, these definitions are not always that easy to apply. If you offer a standard application you pretty much determine a lot of the "how"... For that reason, the "if" part generally holds more weight when figuring out the respective roles. To make matters a bit more complicated the role of a processor needs to be assessed per processing activity (def: processing personal data for a specific business purpose). In many cases I have encountered B2B-SaaS providers will be both a controller and processor regarding their product.
In our experience it really helps to think in terms of outsourced business processes When making that determination. If a customer outsources a business process to your platform, in all likelihood you will be considered a processor for all data that is associated with this process. In turn, such data will usually be the center of focus when it comes to integrations.
The "usual" scenario
Let's start by taking a look at the most common scenario. Your company is a processor for a controller, and you offer an integration to another service ("integrated service"). For example, you offer a fintech tool and you can integrate with the API of several banks to sync financial data to your SaaS Platform.
At the end of the day the solution is to understand that the integrated service is just a different processor for the same controller (namely the customer of your platform). This means that the same controller has two respective processors. Both services are based on independent service contracts and a respectively two DPAs in place. And that's it: no additional contracts or safeguards are needed to provide the integration in conformity with GDPR to your customers.
Do additional contracts need to be in place?
Yes and no.
From a data protection point of view, no additional contracts are required. However, it would make sense to have your DPA reflect the instruction of the controller to send and/or receive data via an integration. Note that your DPA may also refer to your terms of service, which could address this point.
From a commercial and cybersecurity standpoint, however, it definitely makes sense to have an agreement in place with the integrated service in terms of IP rights and security documentation regarding the APIs that are used.
The integrated service is just a different processor for the same controller with independent contracts in place that issue instructions to share data.
The other scenario
From my experience, I can think of only one scenario that might deviate a bit from the above: the integration does not occur directly between two processors that are contractually bound by the same controller. Rather, another third-party service is used to facilitate the integration (think of Zapier, Make "the tool formerly known as Integromat"). For our purposes, let's call it an "integration provider".
In that scenario the main difference is that the controller does not have a direct contractual relationship and no DPA with the integration provider. This means, that no instructions could be issued accordingly. In order to ensure this, the only viable solution is to add to integration provider as a subprocessor to the DPA of that processor that has a contractual relationship (and DPA) with the integration provider and that initiates data transfers via the latter. In practice, this could apply to both processors (you or the integrated service) respectively.
If I haven't lost you by now, and you think I've missed something or still have open questions, please feel free to reach out!