Processor (Article 28 GDPR)

A processor processes personal data for a controller on that controller's instructions, without determining the purposes or the essential means. It is, in effect, the controller's outsourced IT function or back office. Its handling of the data is attributed to the controller, and disclosure to the processor enjoys privileged treatment. In return, a data processing agreement must be concluded.

1 Existence of processing on behalf of a controller

1.1 Basic concept and significance

The processor acts strictly in accordance with the controller's specifications. It may handle the data only as the controller prescribes, must comply with the controller's instructions and must ensure the security of the data. It does not decide on the what for and the why, nor on the essential means.

Two central effects follow from this. First, the processor's handling of the data is attributed to the controller: if the contractor stores data for too long or loses them, the consequences (fines, obligation to notify, communication to data subjects) fall on the principal. Second, disclosure to the processor is privileged: it does not require a legal basis of its own, because the processor is regarded not as a third party but as part of the controller's sphere (Article 4(9) and (10) GDPR). The concept is explained in full in a reference entry (1.2.8 Processor).

This privileged treatment extends far. It also applies to special categories of personal data under Article 9 GDPR, whose disclosure could not be based on a legitimate interest, and it applies regardless of whether the processor is established in the EU or in a third country. Where the processor is located in a third country, however, the requirements governing international data transfers apply in addition (see the section on third-country aspects below).

In practice, the controller is referred to as the principal and the processor as the contractor. The lean nature of the role does not mean, however, that the processor has no obligations of its own. It is the direct addressee of the obligations under numerous provisions:

1.2 Assessment by categories of cases

For the frequent constellations, the classification can be made by reference to categories of cases, without having to work through the abstract assessment.

Three rules of thumb assist in assigning cases to the right-hand column:

• Pursuit of one's own purposes. Anyone who uses the data received for its own, self-determined purposes is not a processor but a controller in its own right.
• Incidental-processing rule. Where the data processing is merely ancillary to another principal service, there is no processing on behalf of a controller. Postal services (core: transport), printing companies (core: printing), translators (core: language), reception staff (core: greeting visitors) and cleaning services (core: cleaning) are therefore not processors. The position is different where the data processing itself becomes the subject-matter of the service, for example where a printing company itself merges address lists and texts into form letters.
• Special statutory cases. Telecommunications providers are not processors in respect of the mere transmission of signals; the position is different for additional services such as storing voice messages in the cloud. Professionals bound by professional secrecy, such as tax advisors, lawyers, external company doctors and auditors, are regularly controllers in their own right because their activity is not subject to instructions and is governed by professional rules of conduct; the position is different for activities outside the core of their profession, for example a pure data analysis.

The supervisory authorities have classified numerous further activities in their interpretive guidance. The following overview summarizes the recurring cases:

Finally, there is no processing on behalf of a controller where the focus of the commissioned service does not lie on the data processing at all, meaning that the service provider comes into contact with personal data only incidentally. This applies, for example, to tradespeople engaged by a landlord who receive tenant data for that purpose, to experts appraising damage, to passenger transport, security and cleaning services, to the printing of documents containing employee photographs, and to courier and freight forwarding services. This is the incidental-processing rule already mentioned.

1.3 Assessment framework in doubtful cases

If the case cannot be resolved by reference to the categories of cases, the core question applies: who actually determines the purposes and the essential means?

Only the principal may decide on the purposes (the what for and the why). As soon as the contractor co-determines the purpose, it becomes a controller in its own right for that processing operation (Article 28(10) GDPR). If, for example, a parent company initially stores employee data solely for the purpose of data backup for its subsidiary (processing on behalf of a controller), but then decides on its own to use those data for group-wide reporting, it is a controller in its own right in that respect.

As regards the means, a distinction must be drawn according to whether they are essential:

Discretion as to the non-essential means is therefore harmless. Where doubts remain, the following indicators point towards processing on behalf of a controller; the more of them apply, the more likely it is to exist:

• The principal remains responsible for lawfulness and does not shift that responsibility.
• The principal is in a practical position to issue instructions.
• The contractor has little substantive scope for assessment and discretion.
• The principal actually exercises rights of control.
• The contractor has no legal relationship of its own with the data subjects.
• The contractor obtains no rights of its own to use the data.

For the purposes of this distinction, the supervisory authorities additionally rely on the following criteria (EDPB, Guidelines 07/2020 on the concepts of controller and processor): the level of detail of the instructions given, the monitoring of the processing by the principal, the way the arrangement appears externally to data subjects (does the service provider act in the principal's name or in its own name?), the expertise and traditional role of the parties involved, and the scope for decision-making left to the service provider. The more detailed the instructions, the closer the monitoring and the narrower the scope for decision-making, the more likely it is that processing on behalf of a controller exists.

How narrow that scope may be is illustrated by the example of a call center engaged to obtain contact data: if the principal leaves the contact strategy, the questions and the assessment to the call center, the call center is not a processor because it has a free hand. If, by contrast, the principal specifies the contact list, the questions to be asked and the assessment criteria and requires the data to be returned without further use, processing on behalf of a controller exists.

The supervisory authorities illustrate the distinction by reference to further constellations. If an undertaking engages a market research institute to conduct a survey and gives it precise specifications regarding respondents, questions and methodology, without leaving the institute any scope for decision-making of its own, the institute is a processor; if, by contrast, the institute itself determines the means to be used (sample, methodology, evaluation), it acts as a controller in its own right. The case of an IT service provider that is able to access systems containing personal data in order to remedy a malfunction is also instructive: if access to the data is not the subject-matter of the service but merely an unavoidable side effect of the maintenance service, and is contractually limited to what is necessary, the service provider nonetheless remains a processor, because it processes the data for the externally determined purpose of system maintenance; if, however, it uses the accessible data for its own purposes, it becomes a controller in that respect.

1.4 Function transfer and outsourcing

Where it is not a specific processing operation but an entire business function that is outsourced (business process outsourcing), this is referred to as function transfer. If the contractor receives hardly any specific instructions in this context and decides on its approach itself, it is not a processor but a controller in its own right. Typical examples are facility management, a shared service company for human resources, finance and accounting or procurement, and the outsourcing of a legal, compliance or data protection department.

The concept of function transfer is outdated; here too, the only decisive factor is the determination of purposes and essential means. Many outsourcing arrangements can therefore be structured as processing on behalf of a controller if the principal specifies the purposes and the contractor decides only on the implementation.

1.5 Multiple roles in relation to the same data

A body may be both a processor and a controller in its own right in relation to the same data, depending on the purpose of the specific processing operation. The point of reference is always the individual processing operation, not the service provider as a whole.

The reason lies in the determination of the purpose: in so far as the service provider uses the data for its own purposes, not specified by the principal, it becomes a controller in its own right for that processing operation, with all the obligations that follow from this.

1.6 Borderline cases and strategic considerations

In borderline cases, the outcome depends on how broadly or narrowly the service under assessment is defined. An overall service may have to be classified differently from an individual component service. Two control questions assist in determining the correct subject-matter of the assessment:

• Does one service make sense only in conjunction with the other? Then both must be assessed together.
• Are the services also offered separately on the market? Then they must be assessed separately.

Comprehensive fleet management (contracts, logistics, claims management), for example, may have to be assessed differently from an online platform for vehicle selection considered in isolation, which on its own may constitute processing on behalf of a controller.

Because the distinction is not always clear-cut, it is also worth looking at the practical consequences. The advantages and disadvantages differ depending on the party's position:

1.7 Risks of an incorrect classification

Whether processing on behalf of a controller exists is determined by the factual reality, not by the contract. A data processing agreement that has been concluded, or omitted, may nonetheless produce a prima facie effect that supervisory authorities and courts take as a point of reference. Both errors have consequences:

2 Data processing agreement (DPA)

2.1 Obligation, legal nature and form

Processing by a processor is governed by a contract or another legal act that is binding on the processor with regard to the controller (Article 28(3) GDPR). The contract does not constitute the role, which follows from the actual circumstances, but its conclusion is a separate obligation of both parties; its absence is subject to fines (Article 83(4)(a) GDPR).

The contract must be in writing, including in electronic form (Article 28(9) GDPR). A qualified electronic signature is not required; as a rule, text form is sufficient, for example the exchange of signed documents by email. If the contract is missing or its content is inadequate, the processing on behalf of a controller may be invalid, above all where the binding effect of instructions is not clearly regulated. A processor that itself determines the purposes and means of the processing is in any event deemed to be a controller in respect of that processing (Article 28(10) GDPR). If it considers an instruction to be unlawful, it must inform the controller accordingly (Article 28(3), second subparagraph, GDPR).

2.2 Selection, guarantees and control (Article 28(1) and (5) GDPR)

The controller may use only processors providing sufficient guarantees to implement appropriate technical and organizational measures in such a manner that the processing meets the requirements of the GDPR (Article 28(1) GDPR). What matters above all in this context is the processor's expert knowledge, reliability and resources (Recital 81 GDPR). The controller must select the processor carefully, have the measures taken demonstrated to it and accompany the cooperation. Where there is no genuine choice, for example because a processing arrangement is imposed, an essential factual precondition of processing on behalf of a controller is absent, and the service provider moves into the role of controller.

Adherence to approved codes of conduct (Article 40 GDPR) or a certification (Article 42 GDPR) may facilitate the demonstration of the guarantees (Article 28(5) GDPR). Both are, however, only one factor and do not replace the overall assessment by the controller. Article 28(1) GDPR does not prescribe a rigid, periodic obligation to carry out controls; it does follow from the accountability principle (Article 5(2) and Article 24 GDPR), however, that the controller must keep continued compliance in view and must terminate the cooperation as soon as the guarantees are no longer ensured.

2.3 Mandatory content under Article 28(3)(a) to (h) GDPR

The contract must govern at least the following eight matters:

Some items of mandatory content deserve particular attention in practice:

• point (a) (instructions): The binding effect of documented instructions expressly extends to the question whether data may be processed outside the EU. An exception applies only in so far as the processor is required to carry out different processing by Union or Member State law; in that case it must inform the controller in advance, unless that law prohibits such information (for example in the case of official orders subject to a duty of secrecy).
• point (c) (security): It is sufficient to undertake to take appropriate measures under Article 32 GDPR; the specific measures need not be listed in full in the contract. In practice, it is advisable to attach the security concept as an annex or to refer to it and to provide for a mechanism for informing the other party of changes.
• point (f) (assistance): This obligation interlocks the contract with further obligations of the controller. The processor notifies the controller without undue delay of security incidents that it becomes aware of (Article 33(2) GDPR) and assists with the data protection impact assessment (Article 35(8) GDPR).
• point (g) (termination): It must be clarified in advance whether the data are to be erased or returned at the end of the project. An exception applies in so far as statutory retention obligations preclude this.
• point (h) (control): An on-site inspection by the controller itself is not mandatory; it is sufficient for the processor to submit meaningful evidence, for example reports of independent auditors or certificates. An on-site inspection must, however, remain possible where it is necessary in the individual case in order to protect the data.

2.4 Sub-processors (Article 28(2) and (4) GDPR)

The processor may not engage further processors (sub-processors) without the controller's prior authorization. There are two ways of doing this:

The sub-processor must be subject to the same data protection obligations as the processor (Article 28(4), first sentence, GDPR). Where the sub-processor fails to fulfill its obligations, the initial processor remains fully liable to the controller for the performance of those obligations (Article 28(4), second sentence, GDPR).

2.5 Liability and fines

The processor is directly liable to data subjects under Article 82 GDPR, jointly and severally with the controller, although only in respect of the breach of the obligations imposed on it specifically (Article 82(2), second sentence, GDPR). It is also an addressee of fines in its own right and may be subject to fines of up to EUR 10 million or 2% of the total worldwide annual turnover of the preceding financial year (Article 83(4)(a) GDPR). Where it exceeds its role and itself determines the purposes and means (exceeding the scope of the assignment, Article 28(10) GDPR), it is deemed to be a controller for that processing operation and is subject to the higher range of fines as well as to the more far-reaching grounds for fines. Because of this direct external liability, it is advisable to provide for an apportionment of liability in the internal relationship, for example by means of indemnity and recourse clauses in the contract.

2.6 Third-country aspects

Where the processor processes data in a third country or engages a sub-processor there (for example servers outside the EU), the data processing agreement alone is not sufficient. In addition, the requirements governing international data transfers under Articles 44 et seq. GDPR must be met, regularly by means of standard contractual clauses and, where applicable, additional safeguards. These requirements are dealt with separately under transfers to third countries (data exports) and must be distinguished from the standard contractual clauses for processing on behalf of a controller referred to below.

2.7 EU model contract and implementation

Under Article 28(7) GDPR, the European Commission has adopted standard contractual clauses for the relationship between controller and processor (Implementing Decision (EU) 2021/915 of 4 June 2021). This model has been examined by the data protection authorities, is drafted neither one-sidedly in favor of the principal nor of the contractor, is available in all EU languages and is increasingly accepted on the market. It is not to be confused with the standard contractual clauses for transfers to third countries (Implementing Decision (EU) 2021/914). Where the processor is established in a third country, those third-country standard contractual clauses (Module 2 or Module 3, depending on the constellation) also cover the requirements of Article 28 GDPR, so that no second contract is needed. The case-specific detail (which data, for which purposes, with which technical measures) remains necessary in every case.

A detailed, practice-oriented account with guidance on completing the contract can be found in the guide to processing on behalf of a controller.

2.8 Internal organization and DPA playbook

Anyone who regularly concludes data processing agreements should not reinvent the process each time, but should set it out in an internal playbook. Such a playbook is a written set of instructions that determines who within the undertaking has to examine what and when, and which contractual clauses are acceptable in which form. It creates uniform standards, speeds up negotiations and makes the decisions taken traceable for the purposes of accountability (Article 5(2) GDPR).

It makes sense first to set out in the playbook the process to be followed before every engagement:

The depth of review should be based on the risk, rather than treating every service provider alike. For simple processing operations involving little sensitivity, a plausibility check of the guarantees and of the contract may suffice; for extensive processing operations or special categories of data, meaningful evidence, where applicable certificates, and shorter follow-up intervals are appropriate. It is advisable to lay down risk-based review intervals in the playbook (for example an annual review for sensitive processing and an event-driven review for simple processing), so that continued compliance with the guarantees is in fact kept in view.

The core of the playbook is a list of the critical clauses in which service providers' models experience shows tend to operate to the principal's detriment, together with the countermeasure available in each case:

Such a playbook can be adapted to one's own size and risk profile: every level of sophistication is conceivable, from a short review grid for small undertakings to an extensive clause library with fallback wording for heavily regulated sectors. What is decisive is that the standards are consciously laid down once and then applied consistently.

2.9 Frequently asked questions