Article 28 GDPR: Difference between revisions

From GDPRhub
Line 230: Line 230:
==Commentary==
==Commentary==


'''''Is Data Processing Agreement a silver bullet under GDPR?'''''  
== Overview ==
Complex processing often requires outsourcing of a part of the activities to specialised service providers with whom personal data are then shared. Under the common data protection framework, such disclosure is acceptable provided that both controller and third parties – in this case, ''processors'' – put in place appropriate safeguards to protect the personal data and ensure general compliance with the Regulation.


''This article is about practice of use of Data Processing Agreements under GDPR over the past two years and about common mistakes data controllers usually make herein.''
== Article 28 (1) ==


''To be on the same page with the readers I suggest to consider, that data processing is a bilateral obligation, which consists of controller’s right to demand a performance of processing and of corresponding processor’s obligation to perform processing in accordance with controller’s instructions, which were preliminary accepted by the processor. In other words, processing is a controller’s offer, accepted by the processor.''
=== On behalf of the controller ===
The processor does not determine the purposes and means of the processing and entirely depends on the controller’s instructions. If the processor violates the instruction or processes the data for any other different purpose, then it ceases to qualify as processor.


'''''i. When is access a processing?'''''
=== Sufficient guarantees ===
The controller may use “''only processors providing sufficient guarantees to implement appropriate technical and organisational measures''. Processors should also meet the requirements of the GDPR as a whole and proactively ensure the protection of data subject rights (Art. 28 (1) GDPR).


''An interesting fact: “access to data” was not listed in Article 4 (2) of GDPR as a processing activity. Precisely speaking: “provision of access” is a processing activity, because this is a “disclosure by transmission, dissemination or otherwise making available”, but getting access is not necessarily “an operation performed on data”.''
The controller is responsible for assessing and selecting the appropriate processor. In doing so, the controller must take into “''serious consideration''” different elements, including processor’s privacy policies, terms of service, records of processing activities, management and information security policies, reports of external audits, recognised international certifications, like ISO 27000series. [[Article 28 GDPR#%20ftn1|[1]]]


''Actually, access to data may be obtained unintentionally or even against the will of the data recipient. It means, when someone provides access to personal data – it processes personal data by performing an active action: operation on personal data by '''making this data available''' to third parties. Whereas, when someone gets access to personal data – it is not always a performance  of an operation on personal data, not always an action or even a voluntary action of data recipient.''
The controller should also assess the processor’s expert knowledge and technical expertise (with regard to security measures and data breaches), reliability and resources. The reputation of the processor in the market may also be a relevant factor for consideration. [[Article 28 GDPR#%20ftn2|[2]]]


''Getting access to data is always a consequence of data controller’s behavior: action (e.g. provision  of authorized access) or inaction (lack of security, negligence, etc.).''
According to the EDPB, the obligation to use only processors “providing sufficient guarantees” is a continuous obligation which does not end with the conclusion of the contract. Rather, the controller should, at appropriate intervals, verify the processor’s guarantees through audits and inspections where appropriate.


''In software development while coding, we usually deal with unintentional and accidental access to controller’s data, which might happen someday or might never happen. We often don’t (?) know when exactly the software developer will have access to controller’s data, which means, that access here is not a contractual obligation or processor’s will, but an independent event.''
== Article 28 (2) ==


''Software itself is a PLACE to store and process data. Likewise a bag, an envelope, a folder, a box or a safe. It is usually empty while produced, until it is filled with content. So creation of paper box is not similar to analysis  of documents inside of this box. Creation doesn’t require access to the content. And for modification of the box, you usually take everything  out before fixing the container, don’t you?''
=== Contract ===
A controller and a processor who enter into a data protection agreement are obliged to sign a written contract (including in electronic form, Article 28 (9) GDPR) to document and specify the scope of the processor’s action, powers and obligations of the parties.


''So why should actions be different in a digital world if they have the same meaning and legal nature as similar actions in material world? If some service or work doesn’t require particular personal data inside— don’t provide access to it. Take data out or anonymise it. This is critically important for data subjects.''
Such a contract shall set out at least “''the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller''” (Article 28 (3) GDPR).


'''''ii. Example of popular non-processing'''''
The controller and processor can also manage the requirements of Article 28(3) and (4) via standard contractual clauses that the European Commission has issued or a supervisory authority has adopted under Article 28(8) GDPR. [[Article 28 GDPR#%20ftn3|[3]]]


''Let’s take a closer look at phases of software development to deepen our understanding and identify the reason of common misunderstanding of the role of personal data processing in software development.''
==== Documented instructions ====
Article 28 (3)(a) GDPR requires the processor to treat personal data only on documented instructions from the controller.


''There are six phases in software development: 1) requirements gathering and analysis, 2) design, 3) implementation or coding, 4) testing, 5) deployment, 6) maintenance. The first three stages are not related to access or processing of controller’s personal data. This is a creation of an empty box. Testing might sometimes require some personal data, but it could be anonymized or pseudonymized – test data. The deployment, maintenance, support and further modifications are usually conducted when the product is deployed in the controller’s production environment. This means, that developer’s team shall have access to controller’s team production environment to perform the services. However, it is a very rare case when a  developer needs controller’s data to perform their services: e.g. when a developer needs to contact data subjects for direct support or processing of user’s requests or for other related to communications with data subjects.''
According to the EDPB, the instructions shall refer to each processing activity and can include “''permissible and unacceptable handling of personal data, more detailed procedures, ways of securing data, etc. The processor shall not go beyond what is instructed by the controller''”. [[Article 28 GDPR#%20ftn4|[4]]]


''In all other cases, developer does not care about data subjects’ identity. So personal data in the controller’s production environment could and must be anonymized or pseudonymized in 90% of cases, because '''developers do not need this data for service provision'''.''
The contract can provide the parties with procedures and templates to communicate “documented” instructions. Instructions, however, can be given by different means (e.g. e-mail), as long as it is possible to keep records of them.


''If so, what is the motivation of data controllers to enter into Data Processing Agreement with as much vendors as possible? Usually the explanation comes down to the following argument: “vendor '''may''' access to our production environment, which '''may''' entail '''some'''processing of controller’s personal data”.''
The rule “''no action without instruction''” also applies to transfers of personal data to a third country or international organisation, as expressly provided for by Article 28 (3)(a) GDPR. The contract should specify the requirements for transfers to third countries or international organisations, taking into account the provisions of Chapter V of the GDPR.


''The key words here are: “may” access and “some” processing. Does “may process” sound like data processing instruction? Is this processing obligatory for the vendor? Does controller have the right to oblige their  vendor to access the controller’s data? It seems, that the answer is “no”. If the vendor “may” access the data, but is not obliged to do it, this means that the moment of access depends on the vendor solely and the controller does not control the data or its processing. This case demonstrates, how controller discloses personal data to a party, which is not even a data processor.''
==== Unless required to do so by Union or Member State law ====
A processor can also process data without, against or above controller’s instructions if required to do so by EU law or other applicable Member State law. For this reason, it seems important to carefully negotiate data processing agreements, also with regard to the existence of any such legal requirement.


''“Some” processing also does not seem like data processing instruction, which is an obligation by its legal nature. And an obligation should have a definite subject matter. It could not be something vague, random or at vendor’s discretion. And the controller loses the control on data again in this case.''
==== Authorised persons ====
Persons authorised to process the personal data are employees and temporary workers involved in the processing activities. Under Article 28 (3)(b) GDPR, authorised persons are committed to strict confidentiality. This may occur either via a specific contractual agreement or statutory obligations already in place.


''Such “potential access” arises as a '''side effect''' of the provision of services in controller’s unprotected environment. But it is not a service of processing itself.''
==== Security measures ====
The contract should list the technical and organisational measures adopted by the processor to ensure the security of the processing.  


''Also the difference between actual processing and potential processing is in the final result of data processing: actual processing influences the  data somehow and has an effect  expected by the parties, while potential processing has zero influence as it does not exist.''
The controller can interact with the processor while choosing the security measures. However, the level of such interaction depends on the specific circumstances of the processing. These measures, which the parties initially agree on, cannot be changed without the controller’s approval. [[Article 28 GDPR#%20ftn5|[5]]]


'''''iii. Let’s brainstorm the case'''''
In accordance with Article 31(1)(d) GDPR, the contract should also describe which type of process is in place to assess appropriateness and effectiveness of the existing security measures.  


''By ensuring the proper level of security,  controller may avoid any unnecessary disclosure of data via “potential access” and exclude the related confusion between an actual processing of data (result of legal obligation) and unreasonable disclosure (result of controller’s negligence).''
==== Sub-processing ====
The data processing agreement must regulate the case of sub-processing which takes place when a processor engages another entity to carry out a part of the operations.  


''When granting access to software developers, the controller usually does not expect or require any particular processing from the vendor, on the contrary, they  seek to limit the risks of data alteration or leakage by long lists of prohibitions and security requirements. Therefore, the controller does not actually need the processing services, which it imposes on the vendor, but is trying to protect themselves  from the risks.''
In principle, such choice is not possible unless the controller gives a prior written authorization. The authorization can be general or specific (Article 28(2) GDPR). In case of general 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.  


''Does this approach really protect from risks so well, or vice versa - increases them?''
If the processor obtains the controller’s authorization, then Article 28(4) GDPR becomes relevant. It follows that, where a processor engages another processor for carrying out specific activities, the same data protection obligations as set out in the “main” data processing agreement (between controller and processor) shall be imposed on that other processor by way of (another) contract (or other legal act). [[Article 28 GDPR#%20ftn6|[6]]]


''After all, the GDPR does not impose any responsibility on  the recipient, but imposes responsibility on  the processor. But what if software developer is not a processor?''
The EDPB also clarified that “''This includes the obligation under Article28(3)(h) to allow for and contribute to audits by the controller or another auditor mandated by the controller''”. [[Article 28 GDPR#%20ftn7|[7]]]


''It means that getting access from data controller does not necessarily entail a processor’s status on recipient’s side and hence does not turn this recipient into a data processor. What is more interesting— an accidental access to personal data is considered as data breach according to Article 4 (12) of GDPR.''
==== Cooperation in addressing rights exercise requests ====
Dealing with data subjects rights requests is a precise duty of the controller under Article 12 – 22 GDPR. However, under Article 28(3)(e) GDPR, processors are not exempted from providing the controller with adequate assistance in that regard.


''The ICO provides a very representative example in its Guide to GDPR Controllers and processors: a mail delivery service is contracted by a local hospital to deliver envelopes containing patients’ medical records to other health service institutions.''
Typically, the assistance consists in promptly forwarding any request received from data subjects. However, in some circumstances, the processor will be given more specific, technical duties, especially when it is in the position of extracting and managing the personal data.


''The delivery service is in physical possession of the envelopes but may not open them to access any of the personal data or other content they contain. The delivery service will not process the personal data in the envelopes and packages it handles. It is in possession of the envelopes and packages but, as it cannot access their content, it cannot be said to be processing (it is not even ‘holding’) the personal data they contain. Indeed, the delivery service will have no idea as to whether the items they deliver contain personal data or simply other information. This means that, regarding the content of the envelopes and packages it delivers, the delivery service is neither a controller in its own right nor a processor for the clients that use its services, because:''
==== Further assistance (Articles 32 - 36) ====
Under Article 28(3)(f) GDPR, the agreement between the parties provides further details as to how the processor assist the controller in ensuring compliance with Articles 32 to 36.


*''it does not exercise any control over the purpose for which the personal data enclosed in the items of mail entrusted to it is used;''
Reference to Article 32 means that the processor shall provide assistance on how to best implement effective security measures. This provision seems to create a sort of consultancy role on the processor who not only has to respect Article 32 in its own structure, but also has to provide assistance to improve the controller’s systems, where necessary.
*''it has no control over the content of the personal data entrusted to it;''
*''it has no instructions from controller to process personal data inside envelopes and packages.''


''However, the delivery service will be a controller of the name & address information on the items to be delivered.''
In case of data breach (Article 33 - 34 GDPR), the processor shall notify the controller without undue delay. [[Article 28 GDPR#%20ftn8|[8]]] The EDPB also recommends “''that there is a specific timeframe of notification (e.g. number of hours) and the point of contact for such notifications be provided in the contract. The contracts should finally specify how the processor shall notify the controller in case of a breach''”. [[Article 28 GDPR#%20ftn9|[9]]]


''The question is: what if this hospital will provide the delivery company with open envelopes, but enter into DPA with the provider to protect the disclosed data? Will this DPA be a sufficient measure of protection patient’s medical records? Obviously no.''
The processor must provide assistance in case the controller carries out a Data Protection Impact Assessment (Article 35) or if a prior consultation before a DPA is needed under Article 36 GDPR.


''Then why data controllers simply disclose personal data to software developers instead of “closing the envelopes”? Why they are forcing their suppliers to have access to confidential data instead of keeping it closed and secure?''
==== Deletion of data ====
The controller can decide whether personal data shall be deleted or returned by specifying it in the contract. If the controller chooses that the personal data be deleted, the processor should ensure that the deletion is performed in a secure manner, also in order to comply with Article 32 GDPR. The processor should confirm to the controller that the deletion has been completed within an agreed timescale and manner.[[Article 28 GDPR#%20ftn10|[10]]]


''Is there a clear purpose and legal basis for such data processing as “potential disclosure  to suppliers”, communicated t in privacy notice to all data subjects? If not — it is against the spirit and letter of GDPR: when data controller discloses personal data without informing data subjects in comprehensive way about it,  to enable them to make rational decision about secondary use or disclosure of their data in controller’s interest – this '''controller denies individual’s right to control dissemination of its personal data'''. Such disclosure of individual’s data will not be GDPR compliant.''
==== Demonstrate compliance and allow for audits ====
The controller can (and should), at appropriate intervals, verify the processor’s GDPR compliance through audits and inspections (Article 28 (3)(h) GDPR). However, in practice, it seems not clear what the real scope of such audit rights is.  


'''''iv. Is there a legitimate interest for disclosure to all vendors?'''''
In assessing the first version of the draft controller/processor clauses submitted by the Danish Authority[[Article 28 GDPR#%20ftn11|[11]]], the EDPB showed a certain criticism towards the excessive restriction of the controller’s audit rights. In particular, the Board criticises the drafting of clause 12.3, which, in its original version, seemed to “''limit this right of the data controller vis-a-vis the sub-processor'' (“''if applicable''” ''and'' ''performed through the Data processor''”)”.


''Data subject trusts the  controller and expects that controller takes rational decisions about disclosure of the  data, not some spontaneous ones, and that each of these decisions is weighted and individuals’ data is properly protected.''
The Board therefore requests “''that the Danish SA redrafts clause 12.3 in order to be in full compliance with the GDPR. This can be done by merging clauses 12.2 and 12.3 as follows'': “''Procedures applicable to the data controller’s audits, including inspections of the data processor and the data sub-processor are specified in appendices C6 and C7 to the standard contractual clauses''” (para 44).


''DPA doesn’t address these expectations when data is shared without a real need or purpose, instead of being anonymized, blurred or hidden. If data subject has even provided a consent for data sharing with an open list of third parties, this sharing should always be limited by the principle of purpose limitation and principle of confidentiality.''
The Danish Authority accepted the EDPB suggestion and, in line with such guidance, modified the wording of Appendix C7, which now seems to afford full protection of the controller’s audit rights:


''Imagine you are trying to apply a legitimate interest as legal basis for disclosure of personal data during software development or modification of system. How will you explain the necessity for keeping personal data open and freely accessible during these services? Let’s try to conduct a legitimate interest assessment test (three-part test) for this case:''  
''The data controller or the data controller’s representative shall [STATE TIME PERIOD] perform a physical inspection of the places, where the processing of personal data is carried out by the data processor, including physical facilities as well as systems used for and related to the processing to ascertain the data processor’s compliance with the GDPR, the applicable EU or Member State data protection provisions and the Clauses. In addition to the planned inspection, the data controller may perform an inspection of the data processor when the data controller deems it required''”.


''1) purpose test: the interest of data controller to develop and modify software is real and present, it corresponds with current activities or benefits that are expected in the very near future—true;''
Since the above-mentioned version of the Danish Standard Contractual Clauses has been approved by the EDPB, it is not unreasonable to conclude that the Board has accepted such broad interpretation of the audit rights.


''2) necessity test: the disclosure of personal data to supplier is necessary for development and modification of software, such disclosure is less intrusive for the rights of individuals compared to other options for achieving the same goal —false. This means that any data item that is not necessary to disclose for development and modification of software '''is processed unlawfully''';''  
=== Unlawful instructions ===
According to Article28(3), the processor must immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other Union or Member State data protection provisions.
----[[Article 28 GDPR#%20ftnref1|[1]]] EDPB, ''Guidelines 07/2020 on the concepts of controller and processor in the GDPR'', p. 29.


''3) balancing test: there is a balance between controller’s purpose on one hand, and the impact on the rights of the data subjects on the other hand: organization's interests override an individual’s —false. Together with the balancing exercise we also should take into account the reasonable expectations of data subjects.''
[[Article 28 GDPR#%20ftnref2|[2]]] EDPB, ''Guidelines 07/2020 […]'', p. 30.


''I suggest to data controllers even an easier one-step LIA: if hiding of personal data from your vendor will not anyhow affect the services, than disclosure of data is unnecessary and hence – unlawful.''
[[Article 28 GDPR#%20ftnref3|[3]]] Rücker, D., & In Kugler, T. (2018). ''New European General Data Protection Regulation, a practitioner's guide: Ensuring compliant corporate practice''.


''Imagine a data breach happened on supplier’s side when an initial disclosure by controller was unlawful: is there a chance that Data Protection Authority will ignore this aggravating circumstance?''  
[[Article 28 GDPR#%20ftnref4|[4]]] EDPB, ''Guidelines 07/2020 […]'', p. 34.


'''''v. When is Data Processing Agreement  a risk for data controller?'''''
[[Article 28 GDPR#%20ftnref5|[5]]] The EDPB clarified that in “''some cases, the controller may provide a clear a detailed description of the security measures to be implemented. In other cases, the controller may describe the minimum security objectives to be achieved, while requesting the process or to propose implementation of specific security measures''” (EDPB, ''Guidelines 07/2020 […]'', p. 35).


''Classic examples of DPA being inapplicable or not necessary:''
[[Article 28 GDPR#%20ftnref6|[6]]] According to Rücker, D., & In Kugler, T. […], p. 227, (cit.) “''To ensure lawful sub-processing, the data protection obligations and responsibilities of all actors involved must, however, be clearly allocated. Chains of (sub-)processors that would dilute or even prevent effective control and clear responsibility for processing activities, must be avoided.''


#''For processing of contact details of teams, sales, signatures and other administrative data both parties usually exchange to enter, perform, control and close the contract (actually, both parties are data controllers here and DPA is inapplicable). A mutual data disclosure/sharing agreement might be an additional option here.''
[[Article 28 GDPR#%20ftnref7|[7]]] EDPB, ''Guidelines 07/2020'' […], p. 36.
#''When instead of processing activities, the controller specifies the “services and works under Master service agreement” (actually, DPA should specify the processing activities, e.g. those, which are listed in Article 4 of GDPR as types of “processing”).''
#''When the only subject of DPA is obligation to have access to controller’s personal data (access should always be for some purpose, legal basis and should be inextricably linked to specific actions that the processor must perform in addition to access).''


''So DPA is a controller’s solution to mitigate risks of data breach on vendor’s side, kind of “legal security measure”. Does this measure protect controller’s data properly? This is a good question, the answer to which depends on legal nature and wording of DPA.''
[[Article 28 GDPR#%20ftnref8|[8]]] EDPB, ''Guidelines on Personal data breach notification under Regulation 2016/679'', WP250rev.01, 6 February 2018, p.13-14


''Of course, sometimes at some stages of software development, the developer might process personal data in a processor’s role, e.g. autonomous driving development (when video is processed); maintenance, support and modification of systems in production. But this is far from 100% of all services IT companies usually provide.''
[[Article 28 GDPR#%20ftnref9|[9]]] EDPB, ''Guidelines 07/2020'' […], p. 37.


''At the first glance DPA looks like an excellent measure of data protection. But, in fact, it often does not contain a subject matter and is often fictitious , since it does not have a particular processing obligations that would actually be fulfilled by the vendor.''
[[Article 28 GDPR#%20ftnref10|[10]]] In these exact terms, EDPB, ''Guidelines 07/2020'' […], p. 38.


''Once the data processing agreement is fictitious  – it might easily be contested in court by either party. After all, any vendor-not-actual-processor is a potential source of a  risk. Having contested the DPA in court or by  Data Protection Authority, such vendor will leave the controller’s disclosure without any legal basis and moreover, will show that DPA as a “legal security measure” was nominal and ineffective.''
[[Article 28 GDPR#%20ftnref11|[11]]] EDPB, ''Opinion 14/2019 on the draft Standard Contractual Clauses submitted by the DKSA'', 9 July 2019
 
''No matter that disclosure in our case above was regulated by signed DPA, since  this agreement has no subject, it may be declared as invalid by court. It means that vendors have no liability under this DPA and no obligations to perform it – from the date of signing.''
 
''In addition, considering that in civil law the DPA is classified as a real contract (not consensual), the rights and obligations of which begin from the moment of the actual providing of data for processing — the suppliers cannot apply security measures until personal data and documented instructions are actually received. And, while the moment of potential access and start of processing is not clear and may be determined solely by the vendor (as discussed above) — the controller may miss the moment of providing instructions, which leads to a complete lack of security for  this period.''
 
''The assumption that DPA is a real contract is most likely correct also because it is impossible for the vendor to start processing or protect the  data it doesn’t actually process, but theoretically may access someday. If the vendor doesn’t perform the processing activities, they are  not able to implement security measures to nothing.''
 
''We can also assume that DPA might be a deal under a suspensive condition. Then there is a problem: who should control the moment of the start of actual processing? How do parties become aware, that processing has  started? We know that usually the DPO is not involved in production and development itself. Nobody informs their  and counterparty’s DPOs about the start of data processing. It might just happen or not happen ever for years. Only data controller should decide when it is ready to disclose the data to a recipient, and this is what data subjects expect.''
 
'''''vi. Conclusions  '''''
 
''A.               Do not enter into DPAs with each vendor without necessity. Controllers may continue to rely on Non-disclosure agreements, amended with all kinds of obligations and security measures they need.''
 
''B.               Remember, that '''receiving access''' is not always a processing. Ensure that each DPA covers real processing activities not the potential or imaginary ones. Otherwise you increase your workload exponentially.''
 
''C.              Controllers shall take maximum security measures to avoid provision  of access without legal basis (Article 6 of GDPR) and especially without necessity (when vendor's contractual obligations could be performed without data processing). Hash, blurr, anonymise, exclude, hide, limit access rights, etc.''
 
''D.              The market needs an official position and clarifications from Data Protection Authorities about the risks of formal entering into “empty” DPAs.''
 
''E.               The privacy community should elaborate on compliant templates of documented instructions; should answer some  questions, such as: who is entitled to issue/accept documented instructions on behalf of the parties; are there necessary terms and conditions to be specified: frequency of processing, term of processing, necessity if processing; has the processor the right to object against instructions, negotiate, decline, withdraw them? It is also desirable to clarify the place of “consent”, “privacy policy” and “controller’s instructions”— in the theory of law: what are they: offer/accept, unilateral deals, singular rights, something else?''
 
First published here: https://www.cpomagazine.com/data-protection/is-data-processing-agreement-a-silver-bullet-under-gdpr/


==Decisions==
==Decisions==

Revision as of 14:49, 1 October 2020

Article 28 - Processor
Gdpricon.png
Chapter 10: Delegated and implementing acts

Legal Text


Article 28 - Processor


1. Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.

2. 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.

3. Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller. That contract or other legal act shall stipulate, in particular, that the processor:

(a) processes the personal data only on documented instructions from the controller, including with regard to transfers of personal data to a third country or an international organisation, unless required to do so by Union or Member State law to which the processor is subject; in such a case, the processor shall inform the controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest;
(b) ensures that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality;
(c) takes all measures required pursuant to Article 32;
(d) respects the conditions referred to in paragraphs 2 and 4 for engaging another processor;
(e) taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller's obligation to respond to requests for exercising the data subject's rights laid down inCHAPTER III;
(f) assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor;
(g) at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data;
(h) 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.

With regard to point (h) of the first subparagraph, the processor shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other Union or Member State data protection provisions.

4. Where a processor engages another processor for carrying out specific processing activities on behalf of the controller, the same data protection obligations as set out in the contract or other legal act between the controller and the processor as referred to in paragraph 3 shall be imposed on that other processor by way of a contract or other legal act under Union or Member State law, in particular providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that the processing will meet the requirements of this Regulation. Where that other processor fails to fulfil its data protection obligations, the initial processor shall remain fully liable to the controller for the performance of that other processor's obligations.

5. Adherence of a processor to an approved code of conduct as referred to in Article 40 or an approved certification mechanism as referred to in Article 42 may be used as an element by which to demonstrate sufficient guarantees as referred to in paragraphs 1 and 4 of this Article.

6. Without prejudice to an individual contract between the controller and the processor, the contract or the other legal act referred to in paragraphs 3 and 4 of this Article may be based, in whole or in part, on standard contractual clauses referred to in paragraphs 7 and 8 of this Article, including when they are part of a certification granted to the controller or processor pursuant to Articles 42 and 43.

7. The Commission may lay down standard contractual clauses for the matters referred to in paragraph 3 and 4 of this Article and in accordance with the examination procedure referred to in Article 93(2).

8. A supervisory authority may adopt standard contractual clauses for the matters referred to in paragraph 3 and 4 of this Article and in accordance with the consistency mechanism referred to in Article 63.

9. The contract or the other legal act referred to in paragraphs 3 and 4 shall be in writing, including in electronic form.

10. Without prejudice to Articles 82, 83 and 84, if a processor infringes this Regulation by determining the purposes and means of processing, the processor shall be considered to be a controller in respect of that processing.

Relevant Recitals

You can help us fill this section!

Commentary

Overview

Complex processing often requires outsourcing of a part of the activities to specialised service providers with whom personal data are then shared. Under the common data protection framework, such disclosure is acceptable provided that both controller and third parties – in this case, processors – put in place appropriate safeguards to protect the personal data and ensure general compliance with the Regulation.

Article 28 (1)

On behalf of the controller

The processor does not determine the purposes and means of the processing and entirely depends on the controller’s instructions. If the processor violates the instruction or processes the data for any other different purpose, then it ceases to qualify as processor.

Sufficient guarantees

The controller may use “only processors providing sufficient guarantees to implement appropriate technical and organisational measures”. Processors should also meet the requirements of the GDPR as a whole and proactively ensure the protection of data subject rights (Art. 28 (1) GDPR).

The controller is responsible for assessing and selecting the appropriate processor. In doing so, the controller must take into “serious consideration” different elements, including processor’s privacy policies, terms of service, records of processing activities, management and information security policies, reports of external audits, recognised international certifications, like ISO 27000series. [1]

The controller should also assess the processor’s expert knowledge and technical expertise (with regard to security measures and data breaches), reliability and resources. The reputation of the processor in the market may also be a relevant factor for consideration. [2]

According to the EDPB, the obligation to use only processors “providing sufficient guarantees” is a continuous obligation which does not end with the conclusion of the contract. Rather, the controller should, at appropriate intervals, verify the processor’s guarantees through audits and inspections where appropriate.

Article 28 (2)

Contract

A controller and a processor who enter into a data protection agreement are obliged to sign a written contract (including in electronic form, Article 28 (9) GDPR) to document and specify the scope of the processor’s action, powers and obligations of the parties.

Such a contract shall set out at least “the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller” (Article 28 (3) GDPR).

The controller and processor can also manage the requirements of Article 28(3) and (4) via standard contractual clauses that the European Commission has issued or a supervisory authority has adopted under Article 28(8) GDPR. [3]

Documented instructions

Article 28 (3)(a) GDPR requires the processor to treat personal data only on documented instructions from the controller.

According to the EDPB, the instructions shall refer to each processing activity and can include “permissible and unacceptable handling of personal data, more detailed procedures, ways of securing data, etc. The processor shall not go beyond what is instructed by the controller”. [4]

The contract can provide the parties with procedures and templates to communicate “documented” instructions. Instructions, however, can be given by different means (e.g. e-mail), as long as it is possible to keep records of them.

The rule “no action without instruction” also applies to transfers of personal data to a third country or international organisation, as expressly provided for by Article 28 (3)(a) GDPR. The contract should specify the requirements for transfers to third countries or international organisations, taking into account the provisions of Chapter V of the GDPR.

Unless required to do so by Union or Member State law

A processor can also process data without, against or above controller’s instructions if required to do so by EU law or other applicable Member State law. For this reason, it seems important to carefully negotiate data processing agreements, also with regard to the existence of any such legal requirement.

Authorised persons

Persons authorised to process the personal data are employees and temporary workers involved in the processing activities. Under Article 28 (3)(b) GDPR, authorised persons are committed to strict confidentiality. This may occur either via a specific contractual agreement or statutory obligations already in place.

Security measures

The contract should list the technical and organisational measures adopted by the processor to ensure the security of the processing.

The controller can interact with the processor while choosing the security measures. However, the level of such interaction depends on the specific circumstances of the processing. These measures, which the parties initially agree on, cannot be changed without the controller’s approval. [5]

In accordance with Article 31(1)(d) GDPR, the contract should also describe which type of process is in place to assess appropriateness and effectiveness of the existing security measures.

Sub-processing

The data processing agreement must regulate the case of sub-processing which takes place when a processor engages another entity to carry out a part of the operations.

In principle, such choice is not possible unless the controller gives a prior written authorization. The authorization can be general or specific (Article 28(2) GDPR). In case of general 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.

If the processor obtains the controller’s authorization, then Article 28(4) GDPR becomes relevant. It follows that, where a processor engages another processor for carrying out specific activities, the same data protection obligations as set out in the “main” data processing agreement (between controller and processor) shall be imposed on that other processor by way of (another) contract (or other legal act). [6]

The EDPB also clarified that “This includes the obligation under Article28(3)(h) to allow for and contribute to audits by the controller or another auditor mandated by the controller”. [7]

Cooperation in addressing rights exercise requests

Dealing with data subjects rights requests is a precise duty of the controller under Article 12 – 22 GDPR. However, under Article 28(3)(e) GDPR, processors are not exempted from providing the controller with adequate assistance in that regard.

Typically, the assistance consists in promptly forwarding any request received from data subjects. However, in some circumstances, the processor will be given more specific, technical duties, especially when it is in the position of extracting and managing the personal data.

Further assistance (Articles 32 - 36)

Under Article 28(3)(f) GDPR, the agreement between the parties provides further details as to how the processor assist the controller in ensuring compliance with Articles 32 to 36.

Reference to Article 32 means that the processor shall provide assistance on how to best implement effective security measures. This provision seems to create a sort of consultancy role on the processor who not only has to respect Article 32 in its own structure, but also has to provide assistance to improve the controller’s systems, where necessary.

In case of data breach (Article 33 - 34 GDPR), the processor shall notify the controller without undue delay. [8] The EDPB also recommends “that there is a specific timeframe of notification (e.g. number of hours) and the point of contact for such notifications be provided in the contract. The contracts should finally specify how the processor shall notify the controller in case of a breach”. [9]

The processor must provide assistance in case the controller carries out a Data Protection Impact Assessment (Article 35) or if a prior consultation before a DPA is needed under Article 36 GDPR.

Deletion of data

The controller can decide whether personal data shall be deleted or returned by specifying it in the contract. If the controller chooses that the personal data be deleted, the processor should ensure that the deletion is performed in a secure manner, also in order to comply with Article 32 GDPR. The processor should confirm to the controller that the deletion has been completed within an agreed timescale and manner.[10]

Demonstrate compliance and allow for audits

The controller can (and should), at appropriate intervals, verify the processor’s GDPR compliance through audits and inspections (Article 28 (3)(h) GDPR). However, in practice, it seems not clear what the real scope of such audit rights is.

In assessing the first version of the draft controller/processor clauses submitted by the Danish Authority[11], the EDPB showed a certain criticism towards the excessive restriction of the controller’s audit rights. In particular, the Board criticises the drafting of clause 12.3, which, in its original version, seemed to “limit this right of the data controller vis-a-vis the sub-processor (“if applicableandperformed through the Data processor”)”.

The Board therefore requests “that the Danish SA redrafts clause 12.3 in order to be in full compliance with the GDPR. This can be done by merging clauses 12.2 and 12.3 as follows: “Procedures applicable to the data controller’s audits, including inspections of the data processor and the data sub-processor are specified in appendices C6 and C7 to the standard contractual clauses” (para 44).

The Danish Authority accepted the EDPB suggestion and, in line with such guidance, modified the wording of Appendix C7, which now seems to afford full protection of the controller’s audit rights:

The data controller or the data controller’s representative shall [STATE TIME PERIOD] perform a physical inspection of the places, where the processing of personal data is carried out by the data processor, including physical facilities as well as systems used for and related to the processing to ascertain the data processor’s compliance with the GDPR, the applicable EU or Member State data protection provisions and the Clauses. In addition to the planned inspection, the data controller may perform an inspection of the data processor when the data controller deems it required”.

Since the above-mentioned version of the Danish Standard Contractual Clauses has been approved by the EDPB, it is not unreasonable to conclude that the Board has accepted such broad interpretation of the audit rights.

Unlawful instructions

According to Article28(3), the processor must immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other Union or Member State data protection provisions.


[1] EDPB, Guidelines 07/2020 on the concepts of controller and processor in the GDPR, p. 29.

[2] EDPB, Guidelines 07/2020 […], p. 30.

[3] Rücker, D., & In Kugler, T. (2018). New European General Data Protection Regulation, a practitioner's guide: Ensuring compliant corporate practice.

[4] EDPB, Guidelines 07/2020 […], p. 34.

[5] The EDPB clarified that in “some cases, the controller may provide a clear a detailed description of the security measures to be implemented. In other cases, the controller may describe the minimum security objectives to be achieved, while requesting the process or to propose implementation of specific security measures” (EDPB, Guidelines 07/2020 […], p. 35).

[6] According to Rücker, D., & In Kugler, T. […], p. 227, (cit.) “To ensure lawful sub-processing, the data protection obligations and responsibilities of all actors involved must, however, be clearly allocated. Chains of (sub-)processors that would dilute or even prevent effective control and clear responsibility for processing activities, must be avoided.

[7] EDPB, Guidelines 07/2020 […], p. 36.

[8] EDPB, Guidelines on Personal data breach notification under Regulation 2016/679, WP250rev.01, 6 February 2018, p.13-14

[9] EDPB, Guidelines 07/2020 […], p. 37.

[10] In these exact terms, EDPB, Guidelines 07/2020 […], p. 38.

[11] EDPB, Opinion 14/2019 on the draft Standard Contractual Clauses submitted by the DKSA, 9 July 2019

Decisions

→ You can find all related decisions in Category:Article 28 GDPR

References