In practice, the server infrastructure required to operate the software (hosting) is very often provided by American companies that act as subcontractors to the platform provider. The leading international companies all come from the USA (e.g. Amazon Web Services, Google Cloud Platform, Microsoft Azure) and usually offer their services via subsidiaries in Europe. So far, I am not aware of any European hosting providers that could compete with the major American hosting providers in terms of price or technology.

European companies using the said U.S. hosting providers are often confronted with the question vis-à-vis customers and authorities as to whether their services can be used in a GDPR-compliant manner. 

This is because it is sometimes assumed that such use is always accompanied by a third-country transfer of personal data (to the US). As a reminder, according to the so-called Schrems II ruling of the European Court of Justice ("ECJ"), a transfer of personal data is only possible under strict conditions that take into account any access rights by U.S. intelligence agencies, which are considered to be incompatible with European data protection law by the ECJ.

In fact, even the transfer of data to the European entity (e.g., "Amazon Web Services EMEA SARL, Avenue John F. Kennedy 38, 1855 Luxembourg") of a U.S. parent company (e.g., "Amazon.com, Inc., 410 Terry Ave N, Seattle 98109, WA, USA"), was considered to be a data transfer to the United States by some authorities.

This is because the U.S. parent company that controls the European entity could (or would have to) oblige the European entity to hand over data under applicable U.S. laws. Such potential access alone was already considered a transfer to the US.

This in turn would mean that the strict requirements for third country transfers under the GDPR would apply. According to the ruling of the ECJ (Schrems II) and the implementation guidelines of the European Data Protection Board, a transfer impact assessment would have to be carried out in addition to the conclusion of standard contractual clauses (often with the result that a transfer would have been impermissible under data protection law). 

As a result, this often meant that an avoidable data transfer to the USA could only be carried out with difficulty in compliance with data protection law. The uncertain legal situation caused considerable uncertainty among potential customers, some of whom assumed that a data transfer to a large U.S. tech company was always illegal under data protection law. 

The result of this strict interpretation often led to the de facto compulsion to resort to a European hosting provider in order to act in a data protection-compliant manner. As a consequence, however, this put EU companies at a competitive disadvantage vis-à-vis their international competitors.


Previous view: Theoretical access = Data transfer

However, European companies can now breathe a sigh of relief. **If data is transferred to an EU subsidiary (be it "Google Ireland", "Amazon Luxembourg", or "Microsoft Ireland"), this alone does not constitute a third country transfer to the USA.** The quintessence of the legal opinion is that a purely hypothetical access does not constitute a "transfer by disclosure" according to the wording of Art. 44 et seq. GDPR.

This is the view of the Conference of Independent Data Protection Authorities of Germany "DSK" (Datenschutzkonferenz) in its decision of January 31, 2023 (available [here](https://www.datenschutzkonferenz-online.de/media/dskb/20230206_DSK_Beschluss_Extraterritoriale_Zugriffe.pdf)) and also of the Procurement Chamber of the Federal Cartel Office (available [here](https://www.bundeskartellamt.de/SharedDocs/Entscheidung/DE/Entscheidungen/Vergaberecht/2023/VK2-114-22.pdf?__blob=publicationFile&v=2)). [But note: Both the Procurement Chamber and the Data Protection Conference are not courts, so their decisions do not have the force of law].

Both the DSK and the Federal Cartel Office are now of the opinion that control by an American parent company alone does not lead to a third country transfer pursuant to Art. 44 et seq. GDPR. This means that no transfer impact assessment has to be carried out and the data transfer is regularly to be classified as purely intra-European and thus "secure".

European companies that use such subcontractors can now confidently refer to the decision of the Data Protection Conference and the Procurement Chamber of the German Federal Cartel Office.

Current view: Hypothetical access = no third country transfer

For the sake of completeness, it should be mentioned that in the opinion of the Data Protection Conference, however, the possibility of access by public authorities must be taken into account in the context of the general reliability check pursuant to Article 28 (1) of the GDPR. 

In this context, the abstract risk of possible access must be assessed and (among other things) the extraterritorial applicability of third-country law, the risk of instructions from third-country parent companies, and suitable technical and organizational measures to prevent access must also be taken into account. As long as the EU Commission has not yet issued an adequacy decision, companies must place particularly high demands on the diligence of the reliability check.

However, the current opinion (Opinion 5/2023) of the European Data Protection Board (EDPB) has brought an adequacy decision by the European Commission on the EU-U.S. Data Privacy Framework closer again. The EDPB had generally expressed positive views on the EU Commission's draft adequacy decision, but at the same time expressed concerns and asked for clarification on several points. If the adequacy decision would be issued, companies would be allowed to transfer personal data to the U.S. without any special restrictions, as the level of data protection in the U.S. would thus correspond to that of the EU. 

It should also be noted that when data is transferred to EU subsidiaries, there may also be a third country transfer if the subsidiary in turn uses subcontractors from third countries (in some cases, however, this can be ruled out if only "regional services" limited to EMEA are used). A precise legal examination of the respective processing situation is therefore advisable.

We also recommend checking whether the Data Processing Agreement (DPA) concluded with the hosting provider is up to date. Here, it is important to ensure that the DPA also refers to the correct service.

In most cases, this can be verified by a simple Google search ("Microsoft current Data Processing Agreement") and should otherwise be requested from the hosting service provider. Typically, this is done via the data protection email address, for example, which can usually be found in the data protection statements. 

The Data Processing Agreement should be independently reviewed for effectiveness and accuracy of fit and - at least in connection with other parts of the contract - include an EU company as a contractual partner. Several providers make the most recent DPAs available for download via their admin console.

What to watch out for

Data processing by US cloud providers in Europe is possible under data protection law

ChatGPT is a so-called chatbot. A chatbot is a text-based application that allows people to chat with technical systems via a technical interface (API). This is of particular relevance for companies and a significant factor for increased efficiency and quality.

What makes ChatGPT special is that it works on the basis of artificial intelligence, i.e. it uses machine learning to independently generate answers to user questions. This takes it to a whole new level of usability compared to, for example, rule-based chatbots.

What is ChatGPT and what explains the hype about it?

Since personal data can be processed in the context of the use of chatbots, the requirements of the General Data Protection Regulation (GDPR) must be observed.

The obligation to ensure that personal data is processed in compliance with the GDPR primarily applies to the controller. The controller in terms of the GDPR is the natural or legal person who decides on the purposes and means of processing. Specifically, this means that a company has the authority to decide why and how ChatGPT is used for its interests.

###### Purpose limitation
Regarding the principle of purpose limitation, it is problematic that ChatGPT usually wants to use the personal data not only for the purpose determined by the controller, but also for other purposes of its own, such as for artificial intelligence training.

This is currently a difficult challenge for the controller when entering a data processing agreement, as the data may only be processed for its own purposes in accordance with its instructions. 

If the data is also to be processed for other purposes, a suitable legal basis must legitimize this processing.

###### Separation of data
In this context, technical and organizational measures should be used to prevent data from different sources from being merged. This risk could theoretically exist if a controller’s customer uses ChatGPT and receives information from another customer as a result of his request.

###### Storage limitation
OpenAI states in its FAQ that it is not able to delete certain prompts (input to retrieve information) from the use of ChatGPT. Especially if these prompts contain personal data, this circumstance is not GDPR-compliant. The deletion of personal data is not only a right of the data subject, but also a principle of the GDPR to delete personal data as soon as the purpose of the data processing has been achieved. Therefore, if there is no guarantee that the data processed by ChatGPT is no longer related to a person, it should be used with caution.

###### Privacy Impact Assessment
Since AI-based chatbots such as ChatGPT are considererd to be a new technology, their use is likely to make a privacy impact assessment necessary pursuant to Art. 35 GDPR. 

In addition, the federal and state supervisory authorities have already defined certain areas of application in a so-called positive list for which a privacy impact assessment is mandatory. This concerns, for example, the use of AI in the context of customer support. 

How a privacy impact assessment is to be carried out is not regulated in the GDPR. However, there are guidelines and online tools from German and European data protection bodies that the controller can use.

###### For processors
If companies use ChatGPT as a processor and thus process personal data for their customers, the above-mentioned problem areas are equally relevant. The processor is bound by instructions from the controller and ultimately obligated to support him in complying with the GDPR.

Data protection issues in the use of ChatGPT

The planned AI Act will regulate the marketing and use of artificial intelligence within Europe. Aside from the opportunities offered by the use of artificial intelligence, the new EU law will address the associated risks. It is therefore to be expected that, when the AI Act comes into force, providers and users of AI systems such as ChatGPT, among others, will be subject to more specific obligations regarding the above-mentioned aspects.

If you have any questions around data protection and the integration of ChatGPT or similar applications, please feel free to contact us.

(This post was not created with the use of ChatGPT 😉)


Impact of the upcoming AI Act on the use of ChatGPT

GDPR and ChatGPT

When using your service, your customers will entrust personal data of their employees and/or their customers ("data") to you that, generally (we will talk about exception in Part 3) you must only process according to instructions of the controller and under a data processing agreement (DPA).

A bit simplified, your customers primary interest vis-à-vis your organization is to make sure that there is a DPA in place that meets legal requirements and that you have "adequate" security measures in place to make sure their data is sufficiently safe with you. Most companies will (rightly) want to make their own picture in this regard.

Saying that you are GDPR compliant and/or putting a fancy fantasy badge on your landing page may be really cute for marketing, but in essence it means absolutely nothing to most of your potential customers. It bears no significance whatsoever, in particular, if you sell to enterprise or larger organizations. There are certifications (similar to ISO 27001) that are vouched for by independent accreditation bodies, which would provide more clout, however, certifications for GDPR are mostly still in the process of being developed. Bottom line, you probably won't have them (now) and neither will your subprocessors. 

The sooner you understand that in many cases your customers will want more substantial answers, and the sooner you can provide meaningful documentation, the faster you'll close that deal.

Understand why Leads are asking Questions and forget "GDPR Compliant" Tags

Legally speaking DPAs are pretty "stupid" contracts (this does not apply for the important description of processing carried out under it). Quite literally everything that is supposed to be stipulated in them is spelled out by Art. 28 GDPR. Therefore, any minute spent on negotiating DPAs is wasted time in our view. 

Based on our experience there is a very effective fix, being the use of EU Standard Contractual Clauses (EU SCCs). EU SCCs are a template contract that has been approved by the European Commission. There is a prohibition to modify the core text (there is a bit wiggle room regarding the annexes). Therefore, none of your customers should have anything to nag about regarding the contract. 

Important: do not confuse EU-SCCs with SCCs for third country transfers. They are two different things.

You can download the template here:

[https://commission.europa.eu/publications/standard-contractual-clauses-controllers-and-processors-eueea_en](https://commission.europa.eu/publications/standard-contractual-clauses-controllers-and-processors-eueea_en)


Simplify your DPA

If you do not want to use the EU SCCs or your customer wants to use their own DPA then give your sales team some useful information to be independent, rather than having to run to legal with every comment in the DPA.

The starting point of the FAQ should contain a list of legal requirements of Art 28. In our opinion, for the sake of simplicity and speed you should kick everything out of a DPA that is not required by law. In particular this refers to provisions for liability and damages or jurisdiction (both can perfectly well be dealt with in ToS or other commercial agreements).

In addition, focus on providing information where it really matters. Based on our experience there are two areas that are frequently (and most fervently) subject of debate and negotiations.

###### Addition or Replacement of Subprocessors

Art. 28 mentions two options when adding or replacing subprocessors: a prior specific authorization or a general written authorization. The latter must include a prior notification and the right to object to the addition or replacement. Now, it is absolutely critical to understand that both options equally put your customer in the position to effectively object to adding or replacing, while the option to require prior authorization can wreak havoc on your operations. You would basically need to get prior approval from every customer before you can make any infrastructure switches, and only one customer that does not get back to you can block the entire process. Even if you customer says that it's their standard procedure to demand prior authorization, give them push back. If you explain the above to them, in a very high percentage they understand. 

###### Audit Rights

Art. 28 requires the processor to provide all information necessary to demonstrate compliance with [Art. 28] and allow for and contribute to audits, including inspections. Because these things have the potential to eat up a lot of time and resources, a lot of processors will try to limit or exclude them. Sure, if a significant number of your customers starts wanting to do on-site inspections this can jam up your operations. However (and unfortunately for you), you are legally required to contribute to and allow them. If you try to limit or exclude them, in many cases this will lead to pushback from your leads and DPA negotiations and it is legally more than doubtful that such limitations or exclusions would stand in front of a court. If you boil it down you have the choice of creating more negotiations thus prolonging your sales cycle (which also uses resources) or biting the bullet and answer questionnaires or participate in on-site audits. IMHO, I would rather opt for the latter. On-site audits for cloud-heavy operating companies are quite rare in our experience (I mean what is there really to see?) and resources for questionnaires can be preserved with better security documentation.

The next parts of this series will deal with international data transfers, separating between being a processor and a controller, and security documentation, known as "technical and organizational measures" or "TOM". Make sure to add relevant information regarding all of those topics to your sales FAQ. 


Stay tuned for Part 2 


Set up a strong FAQ for your Sales Team

Empowering Sales to deal with GDPR Questions

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.


Controllers vs. processors

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.

The "usual" scenario

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.

![B2B SaaS Integrations & GDPR](https://a.storyblok.com/f/183108/2460x1686/f844776923/b2b-saas-integrations-en-simpliant-insights.jpg "The integrated service is just a different processor for the same controller with independent contracts in place that issue instructions to share data.")


Do additional contracts need to be in place?

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! 


Insights

Data processing by US cloud providers in Europe is possible under data protection law

GDPR and ChatGPT

Empowering Sales to deal with GDPR Questions