Data Processing Agreements
Dear Enterprise Community,
I’m writing to you to explain the importance of the data processing agreement (DPA). Sometimes referred to as a data processing addendum, the DPA is a type of contract that governs the relationship between your business and another entity. The three key terms you’ll encounter in a DPA are as follows:
the data subject, defined as individuals whose personal and sensitive information needs safeguarding;
the data controller, the entity directly collecting the data subject’s information, providing a subscriber service to the data subject (for instance, Amazon.com would be a controller, and the subscribers would be the data subjects); and
the data processor, an entity hired by the controller to help fulfill delivery of a service (in the Amazon.com example, a processor may be FedEx with whom Amazon shares information so that shipping and delivery of an order can occur).
Part 1: How is My Business Tracking Customer Data?
As you read this, your organisation may be the data controller or the data processor.
If you operate a subscriber service, and sell the service directly to your customers without an intermediary, your organisation is likely the data controller.
If your organisation helps other data controllers deliver their service, like MailChimp or Salesforce or Dropbox etc., your organisation may be the data processor. See the processing ecosystem diagram below.
Here’s an example. Data subjects (as customers) may subscribe to the London Times newspaper (the data controller); email updates about the subscription may be sent out by MailChimp (the data processor) on behalf of the London Times.
In general, a DPA is established between the data controller and the data processor, and ensures the data processor only employs the information about each data subject according to the strict instructions of the data controller. In the example above, MailChimp would not be permitted to email data subjects associated with the London times, and could only use the information provided by the data controller according to the instructions written in the DPA.
There are many regulations that require a DPA to be established between a data controller and a data processor, and the GDPR is one of the regulations requiring this: “Processing by a processor shall be governed by a contract or other legal act…” (Article 28, GDPR).
It is usually the data processor that provides the DPA template. We can provide a generic template if that's helpful, but when working with a processor, you should request a copy of their DPA. An example DPA from Acme Services can be downloaded here.
Part 2: The Parties Involved in the DPA
If your organisation is the data controller, any entity with whom you share information about the data subject may be a data processor, and you’re responsible to solidify a DPA with that entity. This could include entities such as Google’s G-Suite, Microsoft Office 365, MailChimp, Google Analytics, Salesforce, etc. Failure to do so can results in a sizeable fine for your organisation and the data processor as well.
Part 3: The Purpose of the DPA
Generally, a DPA regulates the specificities of data processing, including these items:
defining the subject matter of the data being processed;
ensuring the data processor maintains confidentiality;
employing security measures to safeguard personal and sensitive information;
improving security over time as the industry evolves;
ensuring protective measures with data transfers;
practicing incident management when necessary;
employing safeguards and notification when using subcontractors;
returning or destroying data when necessary;
providing ongoing assistance to data controllers;
assuming liability and providing indemnity regarding data breaches;
describing a census of personal data processed; and
listing approved subprocessors.
Your business must be able to demonstrate your suppliers and subprocessors provide sufficient guarantees to protect the data entrusted to them. Executing a properly written Data Processing Agreement between the data controller and data processor is the starting point for ensuring both parties understand their legal obligations and flowdown terms.
Must the DPA Be Signed by the Controller and Processor?
Yes, the DPA must be signed by both the data controller and the data processor. The signatory can be electronic, but it must be signed.
Part 4: Your Responsibilities as a Data Controller to Vet the Data Processor
Read this carefully. If your organisation is the data controller, you are obligated by law “to use only processors providing sufficient guarantees to implement appropriate technical and organisational measures…” (Article 28, GDPR). Can you—the data controller—prove, in writing, that you have done this? Do you know how to do this?
The data processor must "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk" because if a data breach occurs, the data controller would be ultimately responsible for the breach. (The data processor would also be liable.) Data controllers must demonstrate how it took all appropriate measures to audit its suppliers (data processors) to ensure they implemented legal, administrative, technical, physical and organisation measures to protect the data subject's information.
This can be a complicated topic to work through, and whether your organisation is the data controller or the data processor, you can employ us at Allendevaux & Company for help. Furthermore, if you are the data controller and need help vetting your data processor, you can contact Allendevaux & Company to audit your data processor. Our IBITGQ auditors will write a report that vets the data processor regarding the presence or absence of administrative, technical and physical measures required to safeguard regulated information.
Part 5: The Importance of Becoming Certified
It’s helpful if the data processor is certified to an international framework for data protection, such as ISO/IEC 27001. When an entity is certified to that standard, they have undergone a rigorous onsite audit by third-party, independent IBITQG auditors like us that provide an independent attesting of findings summarized in a report. Short of that, you can at least practice due care by asking common sense questions such as these:
I request to review your asset registry of any systems supporting the Service.
I would like to review your processes and workflows that support the Services.
I would like to review your cybersecurity scanning practices and results for anything that supports the Service.
I would like to ask if you perform penetration tests, the date of the last test, and I would like to see the results of that test. Furthermore, if any issues were found, I would like to know the corrective action plan and the timeframe associated with those actions.
I would like to review your continuity of operations plans to ensure the ongoing availability of the Service.
I would like to review your seasonal fail-over test logs, the results, and any corrective actions noted that may need addressed.
I would like to review your disaster recovery plans, including your metrics to restore service.
I would like to review your resiliency architecture that supports the Service, or the resiliency architecture of any subprocessors you may employ.
I would like to review your risk management practices to ensure valid evidence of practice, including a review of your latest Risk Assessment report to ensure risks have been measured, to understand your risk tolerance level, and to understand your risk treatment plan.
When the questions above are issued to a data processor, it’s called an “Article 32 Security of Processing Request” and most data processors are becoming accustomed to receiving these. If your processor does not respond or does not know how to deal with these request, you should not transmit the personal information of your data subjects to the processor, because, by doing so, you will be violating the law. You could be subject to millions of euros in fines, regardless of where you are in the world.
Does This Topic Apply to
Many nations require a DPA to be implemented between the data controller and the data processor. Using the European Union as an example, the GDPR regulation is often a discussion topic because of its reach, and organisastions are always asking if the GDPR applies to them in other non-EU regions of the world.
If your business markets to EU data subjects and has the opportunity for EU data subjects (customers, employees, contractors from the EU) to have their information collected and stored by your organisation, then the GDPR applies to your organisation. If the law applies to your business as the data controller, then the data processor – whomever they are – is also bound to follow the regulations of the GDPR.
It is likely that your organisation will need to comply with multiple laws that protect individuals (Brazil, Switzerland, California, the United Kingdom, the European Union, just to name a few). Please see the section on regulatory compliance for more information about building a regulatory compliance compendium to understand the overall obligations your business must observe in the realm of data protection law.
Getting Further Help
If you need guidance understanding the information above, contact the Allendevaux & Company Service Desk. You will be assigned to a certified privacy professional accredited by ISO, IBITGQ or the IAPP with experience in privacy law and compliance. You’ll also find contact information at the bottom of this page for telephone, and email.
We need your consent to receive your information and contact you. By pressing the 'Send' button below, you are providing that consent. You have the right to withdraw your consent at any time. To withdraw your consent, please email us here. For more information about what we do with your personal data and how we protect it, see our privacy notice.