4. Processing by service providers

If service providers are deployed to send mailings or for the storage and/or processing of the email advertisement, their integration must also be designed in a data protection-compliant manner. This does not only apply to actively supporting service providers, but also to the provision of cloud services or Software as a Service by service providers.

4.1 Importance of processing according to the GDPR

A process that is data protection-compliant can be ensured by contractually agreeing on processing in accordance with Art. 28 of the GDPR. Art. 28 of the GDPR specifies the conditions which must be fulfilled in the case of processing. What this essentially entails is what can be termed as the “privilege” of processing. If such a contract has been effectively agreed upon, the requirements of Art. 6 of the GDPR do not have to be met in order for the service provider to have access to the personal data.

For those interested in the specific details: It has been a matter of debate as to whether such processing has the same “privilege” under the GDPR as it did under the former legal situation. In the meantime, the prevailing view is that it does have a similar effect. The main argument is that the processor is not a third party according to the definition in Art. 4(10) GDPR. Moreover, this was already the case under the Data Protection Directive 95/46/EC, which was implemented in the prior German Federal Data Protection Act (BDSG).

4.1.1 Conditions

Three elements are key for processing:

  • The processor is strictly bound by instructions (Art. 28(3)(a)(29) GDPR).
    In other words, the service provider is specifically instructed by the contract on what it has to undertake.
  • The controller concludes an agreement with the processor in accordance with Art. 28 GDPR.
    In other words: No agreement – no processing privilege granted.
  • The agreement must comply with the requirements of Art. 28 GDPR.
    In other words: No compliance with Art. 28 GDPR – no processing privilege granted.

Under data protection law, these strict conditions warrant processing by an external party or even access to personal data which an external party processes for the data controller.

Art. 28 of the GDPR contains comprehensive requirements for the content of the contract, all of which must be completely implemented in the contractual agreement, and not only in part. While not all aspects of the processing design can be dealt with below, particular aspects should nevertheless be highlighted:

Electronic form of contract – also facilitated by the GDPR!

With the recognition of the electronic form in Art. 28(9) of the GDPR, an online agreement contract is also possible. Nevertheless, the controller (but also the processor) must be able to provide evidence of the actual agreement contract and its concrete content in the event of a dispute, so careful documentation is also required here.

Right to on-site audits

One of the factors that the processing contract must provide (under Art. 28(3)(2)(h) GDPR), is that the processor “makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller”.

In other words, the controller must have the right to conduct on-site audits. The predominant opinion is that the controller does not necessarily have to carry out on-site audits, but must nevertheless have this right to carry out on-site audits or be able to exercise this right with the support of the processor. One frequent point of contention is whether the right to audit must also exist for subcontractors of the processor.

Subcontractors of the processor

The GDPR refers to the processor’s subcontractors as “other processors” and regulates their involvement in Art. 28(2) of the GDPR as follows: “The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes.”

In addition to the so-called consent requirement, the GDPR also recognises what can be termed as an opt-out solution. This means a considerable simplification in practice. The controller and the processor must have jointly addressed the following questions in advance: What is the consequence of an objection? How long is the preliminary time – is the time window sufficient to switch to another provider? In practice, various arrangements can be found that take this circumstance adequately into account.

In one aspect, the reality can clash against the legal situation, which is not always easy to resolve: the GDPR assumes that the processor involves its subcontractors in the same contractual arrangements as those agreed between it and the controller. The GDPR puts it this way: “the same data protection obligations as set out in the contract or other legal act between the controller and the processor (…) shall be imposed on that other processor by way of a contract (…).” In other words, the terms of the contract must be followed.

A challenge arises when the regulation is read verbatim, and “the same” conditions are required. Because in that case, no deviation is possible. In practice, the processor often does not specify the contracts with the responsible party and its subcontractors, but uses other cloud services (PaaS, IaaS, … ), and they specify their contractual conditions. Then they may find themselves in a “sandwich position” between the specifications of the responsible party and the specifications of their subcontractor. This must be taken into account at an early stage when drafting the contractual conditions.

Security of processing according to Art. 32 GDPR

According to Art. 28(3)(1)(c) GDPR, the agreement on processing must provide that the processor shall “take all measures required pursuant to Article 32”. In other words: The contract must regulate the technical and organisational measures for the security of the processing in accordance with Art. 32 GDPR.

This is a task that basically affects both the controller and the processor. A frequent “misunderstanding” of processors is that this is only a duty of the controller and can be “unloaded” on the controller by contract. Art. 32 of the GDPR (security of processing) explicitly requires the processor, in addition to the controller, to take appropriate protective measures. The breach of Art. 32 GDPR can lead to both claims for compensation (Art. 79, 82 GDPR) as well as fines (Art. 83(4)(a) GDPR) for both.

The dilemma is that often the controller does not have the competence to individually assess the necessary measures and therefore relies on the processor. However, the processor – at least the SaaS provider – does not know (and may not know for data protection reasons) what data is being processed in its systems, so it cannot assess the adequacy of the measures.

In short, this dilemma must be clearly addressed and regulated in the processing agreements. A service provider that not only provides a SaaS or cloud service will typically also know exactly what data is processed and how this is processed.

Risk of insufficient agreement

Who bears the risk of a processing agreement that does not comply with the legal requirements? The controller, of course, but also the processor.

If the agreement is not sufficiently drafted, there is no processing, and the data recipient is treated as a third party. For the processor, in particular, this brings on board a legal basis for data protection and means that, within the meaning of the GDPR, the processor is the party subject to all original GDPR obligations as a controller!

In other words, it is therefore very much in the vested interest of both parties to conclude a valid agreement.

4.1.2 Distinction from joint controllership

The GDPR also regulates so-called joint controllers. In this case, two traders also work together. The formalisation of joint controllership in Art. 26 of the GDPR has led to discussions about the distinction between this and processing.

The decisive difference is: In the case of processing, the controller alone decides on the purposes and means of the processing (Art. 28 of the GDPR). In the case of joint controllership, the cooperating parties decide jointly on these factors (Art. 4(7)(2) GDPR).

In typical circumstances, there is no such joint controllership. However, it can be different if the service provider engaged in email marketing is allowed to use the data collected, processed or otherwise generated for the data controller for the controller’s own purposes. This is not always or per se illegal. In this case, however, attention must be paid to the concrete design of the cooperation in order to avoid pitfalls.

4.2 Cross-border processing

The cross-border deployment of service providers or services (e.g., SaaS and cloud services) is regulated and set out in the GDPR in Art. 44 et seq. In simple terms, these requirements must be observed if the data is transferred to or accessed from a so-called third country. The discussion is still underway that had already begun under the former German Federal Data Protection Act (BDSG) as to whether the transfer to a third country should be based on the location of the data or the location of the cloud provider. The tendency is to focus on the location of the data. The details are still under debate.

The GDPR provides for a tiered scheme of permissibility in Articles 45 to 49 of the GDPR. The most important regulations are:

  • If the ECJ Commission has adopted a resolution for adequate level of data protection for a third country, then the transfer of data to this country is generally permissible until the ECJ or the EU Commission revokes this resolution. The so-called EU-US Privacy Shield has been declared invalid by the ECJ and therefore is no longer applicable. Negotiations for a new agreement are currently taking place at the political level. In October 2022, the USA issued an Executive Order paving the way for a new assessment by the EU Commission and – at the time of writing – possibly a new adequacy decision.
  • The EU Commission has adopted so-called standard data protection clauses (standard contractual clauses) that can justify a third-country transfer if they are concluded between the companies that transfer and receive the data. The wording of these clauses may only be changed or supplemented where the clauses explicitly allow for this to occur. However, as a result of the ECJ’s Schrems ruling, their conclusion alone is not sufficient. Rather, the company transferring the data must assess for itself whether an adequate level of data protection exists in the recipient country (Data Transfer Impact Assessment). In the case of data transfers between the EU and the USA, this is currently the only way to exchange data, which is thus legally insecure. Reminder: The EU Commission published new standard contractual clauses in June 2022. From 27.12.2022 onwards, the transition period for the old standard contractual clauses will have expired.
  • The data subject has consented to the transfer of the data to a third country. However, this requires in particular that the data subject has been clearly informed about the third-country transfer and the associated risks and expressly gives consent. The data subject can also revoke this consent at any time.

A third-country transfer creates additional requirements. These can be fulfilled in practice but must be taken into account from the beginning. This applies, in particular, to consent to the transfer, which must be obtained in addition to consent to advertising.

4.3 Responsibility of the controller

From the perspective of the GDPR, as the responsible party in terms of data protection law, the controller remains responsible for compliance with all requirements of data protection law, even on behalf of the processor. According to Art. 5 of the GDPR in particular, the controller has to review and document the admissibility in principle. Furthermore, according to Articles 24 and 32(4) of the GDPR, the controller must organise the compliance with data protection.

The involvement of a processor does not in any respect lead to a delegation of responsibility to a processor in the external relationship with the data subjects and with the data protection supervisory authorities, nor does it lead to a limitation of liability in any respect. The controller is liable under both German civil law and the GDPR for the conduct of the processor, including its subcontractors.

In contrast to the former German Federal Data Protection Act (BDSG), however, the processor is also independently liable vis-à-vis the data subjects and the data protection supervisory authority. This is a significant innovation of the GDPR compared to the former BDSG. To a certain extent, the GDPR provides for exculpation from liability in the event of claims for damages under the GDPR. However, this is not a “carte blanche”.

4.4 Summary

Processing is regulated in detail in Art. 28 of the GDPR and, in some respects, differs significantly from the previous regulations. Due to the considerable liability risks, it is imperative to ensure that these conditions are complied with. In instances where data processing was contracted under the former law, it must now be adapted to comply with the new conditions.

Authors

    Get in touch with us