Central to data protection in the EU is the GDPR and its data processing regulation. One of the most challenging aspects of GDPR is adjudicating the relationships between different parties handling data for various purposes–namely, relationships between managed service providers and the various, nebulous groups of organizations that use data for their daily operations. 

In this scenario, the Data Processing Agreement (DPA) concept is central to protecting data – a crucial contract that governs the relationship between data controllers and data processors. This article delves into the intricacies of GDPR-compliant DPAs, highlighting their significance and critical components.

What Is a Data Processing Agreement?

A Data Processing Agreement (DPA) is a legally binding agreement between a data controller and a processor maintained as part of their working relationship. GDPR mandates this agreement to ensure that the processing of personal data is done in a lawful, fair, and transparent manner, safeguarding the rights of the data subjects under regulations.

In the context of the GDPR, a “controller” and a “processor” are as follows:

• Controller: The controller is an organization that determines the purposes and means of processing personal data. It decides how and why data will be processed and for what purpose. If the controller is based in the EU or processes the data of EU citizens, it is subject to the GDPR’s regulations.
• Processor: The processor is an organization that processes data on behalf of the controller. For example, cloud service providers can be considered processors. While the processor processes the data as the controller instructs, it also has specific obligations under the GDPR. 

In cases of DPAs, there is only one controller and one processor, even if the controller also acts as a processor in other situations. Additionally, a processor may subcontract to additional processors, with ramifications to the current and future DPAs (more on that later). 

This contract should also specify other obligations and rights, such as ensuring data confidentiality, assisting the controller in providing data subjects’ rights and implementing appropriate security measures required under EU regulations.

What Should a DPA Accomplish?

While a DPA is a legal agreement between two parties, it is expected to carry the weight of regulation and law about the parties within the contract. As such, the DPA is less a simple form of paperwork that companies need on records and more a clear delineation of responsibilities and obligations (similar to a Business Associate Agreement under HIPAA).

Generally, a DPA should spell out the following aspects of the working relationship between a controller and processor:

• Purpose: The DPA outlines the scope, purpose, and duration of the data processing, the types of personal data processed, and the categories of data subjects (duration is a critical part of EU regulations).
• Obligations of the Processor: The data processor must process personal data only based on documented instructions from the controller. They must also ensure the confidentiality of the personal data they process.
• Security: The DPA mandates that the processor implements appropriate technical and organizational measures to ensure the security of personal data as required by the controller based on the purposes outlined in the agreement.

While these are broad categories overall, they have more significant ramifications for the specific tasks and processes a processor will engage in on behalf of a controller. 

What Is Required As Part of a Data Processing Agreement

It’s important to note that “processing” in these agreements means storing, manipulating, or transferring user information on behalf of the controller who engages with data subjects as customers or users. Much of the DPA stems from GDPR rules as they apply to these practices.

Under Article 28, when processing is to be carried out on behalf of a controller, the following requirements are imposed on controllers and processors as part of a data processing agreement:

• Use of Processors: The controller should only use processors that guarantee appropriate technical and organizational measures. This ensures that processing meets the GDPR requirements and protects the data subject’s rights.
• Contracting with other Processors: The processor can only engage another processor with prior specific or general written authorization from the controller. If there’s a general written authorization, the processor must inform the controller of any intended changes, such as adding or replacing other processors.
• Contractual Obligations: Processing must be governed by the DPA that binds the processor to the controller. This contract should outline the nature and duration of the processing, the type of data and categories of data subjects, and the obligations and rights of the controller.
• Specific Stipulations: The contract should stipulate that the processor only processes data based on instructions from the controller, implements required security measures from Article 32 and Article 36 (see below), supports the controller in their compliance where relevant, and demonstrates compliance with Article 28 (see below).
• Sub-processors: If a processor engages another processor for specific processing activities, the initial processor remains fully liable for performing the sub-processor’s obligations.
• Processor as Controller: If a processor determines the purposes and means of processing, thereby infringing the GDPR, it shall be considered a controller for that processing.

Throughout these requirements, there are extensive mentions of other parts of GDPR, specifically articles 32 and 36:

Article 32, “Security of Processing”

Article 32 of GDPR addresses the technical and organizational measures that data controllers and data processors must implement to ensure the security of their personal data.

The main requirements highlighted under Article 32 include:

• State-of-the-Art Technology: Both the data controller and the data processor must implement appropriate technical and organizational measures to ensure security appropriate to the risk. This should consider the latest technology available and the costs of implementation.
• Assessment of Risks: The measures should consider the risks presented by the processing, especially accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data transmitted, stored, or otherwise processed.
  
• Security Measures: The article provides examples of security measures organizations should implement, including encryption, protection of the CIA triad, backup and data recovery, and ongoing testing.
  
• Involvement of Processors: Where a data processor is involved, the controller should ensure that the processor provides sufficient guarantees to implement appropriate technical and organizational measures so that the processing meets the requirements of the GDPR.

Article 36, “Prior Consultation”

Article 36 deals with situations where a data controller anticipates that a type of processing, especially using new technologies, will result in a high risk to the rights and freedoms of individuals. In such cases, the data controller must consult with the relevant supervisory authority before commencing the processing.

The main ideas in Article 36 include:

• When to Consult: The data controller should consult the supervisory authority before processing if a data protection impact assessment may introduce significant security risks.
• Information Provided: When consulting the supervisory authority, the controller should provide the intent and purposes of processing, assessment of data subject rights and risks, and measures proposed to mitigate risk.
• Duration of Consultation: The supervisory authority should provide advice within up to eight weeks from the consultation request. The supervisory authority must inform the controller and, where applicable, the data processor of any such extension.
• Other Consultations: If the supervisory authority has been consulted on the same subject matter, further consultation may only be required if there have been changes in the processing or other reasons that necessitate another consultation.

Make Sure You Meet Your Requirements as a Processor or Controller with Continuum GRC

Continuum GRC is a cloud platform that can take something as routine and necessary as regular vulnerability scanning and reporting under FedRAMP and make it an easy and timely part of business in the public sector. We provide risk management and compliance support for every major regulation and compliance framework on the market, including:

• FedRAMP
• StateRAMP
• GDPR
• NIST 800-53
• FARS NIST 800-171
• CMMC
• SOC 1, SOC 2
• HIPAA
• PCI DSS 4.0
• IRS 1075
• COSO SOX
• ISO 27000 Series
• ISO 9000 Series
  
• ISO Assessment and Audit Standards

And more. We are the only FedRAMP and StateRAMP-authorized compliance and risk management solution worldwide.

Continuum GRC is a proactive cyber security® and the only FedRAMP and StateRAMP-authorized cybersecurity audit platform worldwide. Call 1-888-896-6207 to discuss your organization’s cybersecurity needs and find out how we can help your organization protect its systems and ensure compliance.