Data Processing Agreement (DPA) Review and Negotiation Considerations
Disclaimer The information provided in this post is for general informational purposes only and does not constitute legal advice. Laws and regulations vary by jurisdiction, and the application of legal principles depends on specific facts and circumstances. You should consult a qualified lawyer for advice regarding your individual situation. No lwayer-client relationship is created by your use of this material.
Materiality Considerations
When assessing a Data Processing Agreement (DPA), consider the materiality of the data processing activities by evaluating:
Data Sensitivity: Determine the level of sensitivity of the personal data being processed (e.g., minimal employee information versus financial or health data).
Potential Impact: Assess the risks and consequences of data breaches or misuse on both individuals and the organization, including reputational, financial, and regulatory risks.
Key Drafting Considerations
Role of the Parties
The roles of the parties should be clearly defined. As background, keep in mind that the key roles are:
Data Controller: the entity (typically the customer in SaaS contracts) that determines the purposes and means of processing personal data. Note: The Data Controller’s key responsibilities include:
Defining the lawful basis for processing personal data.
Informing data subjects about how their data will be processed.
Ensuring that processing activities comply with relevant data protection laws.
Providing instructions to the Data Processor regarding data processing activities.
Managing and responding to data subject rights requests (e.g., access, deletion, correction).
Data Processor: the entity (typically the vendor is SaaS contracts) that processes personal data on behalf of the Data Controller under its instructions. Note: The Data Controller’s key responsibilities include:
Processing personal data only as instructed by the Data Controller.
Implementing and maintaining appropriate technical and organizational measures to ensure data security.
Assisting the Data Controller in fulfilling obligations related to data subject rights.
Notifying the Data Controller of any data breaches within the agreed timeframe.
Ensuring that sub-processors (if any) comply with the same data protection obligations.
In some cases, the vendor may act in dual capacities. For example, the vendor may be a Data Processor of data provided by the customer but a Data Controller of data that is provided directly by end users (e.g., in a SaaS context—usage data; in an HR context—benefit claims).
Amendments to the DPA
Some vendors include clauses that allow them to unilaterally modify the DPA. Either:
Any changes should require mutual agreement, especially those affecting data use, security, and liability; OR
[preferred] There should be a commitment that changes will comply with applicable laws and not reduce the protections afforded to the data or the Data Controller’s rights and the Data Processor’s obligations.
Scope of Processing
The DPA should clearly define the data covered by the agreement (often detailed in an appendix).
Data Types: Identify the categories of personal data involved (e.g., names, contact details, financial data, health records). Ensure the listed data types are specific and complete.
Consider what is excluded, as this often indicates the Data Processor’s view on what data it controls outside the DPA’s protections.
If data is a mix of personal and non-personal data, it may benefit the Data Controller to redefine the scope to cover all data, not just personal data.
Processing Activities: Define the specific actions the Data Processor will perform, such as collection, storage, access, sharing, analysis, or deletion. Ensure comprehensiveness while maintaining precision.
Duration of Processing
Timeframe: Ensure the agreement specifies how long the Data Processor will process the data. Confirm alignment with the Data Controller’s retention schedule.
Termination Conditions: Define the circumstances under which processing must cease and outline obligations data return or secure deletion.
Avoid open-ended retention with the Data Controller having to ask for deletion.
Ensure that “delete” means to render permanently incapable of reconstruction. Be cautious about retention of “anonymized” or “de-identified” data, as vendors may retain underlying datasets.
Purpose of Processing
The DPA will usually require the Data Controller to represent or warrant that it has or will have all the rights necessary for the Data Processor to process the data in accordance with the DPA.
Consistency: Ensure stated purposes align with privacy policies and notices, considering whether explicit or verifiable consent is required.
Data Processor Usage Rights: Review provisions to prevent the Data Processor from using the data for its own purposes.
Be careful of provisions that say data can be processed for any of the purposes in the main agreement.
Review to ensure that the Data Processor hasn’t given itself rights to process the data for its own purposes in places hidden in the agreement (there is a trend to stick in a right in the Miscellaneous provisions that survive termination).
Obligations of the Processor
Data Security Measures: The DPA should specify the technical and organizational measures (TOMs) in place to protect data.
Note: The Data Controller is ultimately responsible for ensuring that the TOMs are adequate to the risk.
Note: The Data Processor typically is only liable if they breach the DPA by failing to implement and maintain these TOMs. Therefore, the TOMs should be extensive and detailed and include requirements to improve to meet new challenges.
Scope: Consider whether the TOMs only apply to personal data, or all data processed by the Data Processor. Ideally, we care about all the data.
Changes: The Data Processor should be able to change the TOMs to adapt to new technologies and risks. However, changes should not diminish the overall confidentiality, integrity or availability of the data or the security of the services.
Sub-Processing: The Data Processor may try to word the TOM commitment to exclude subprocessors such as AWS, Google, Microsoft or others. To the greatest extent possible, the Data Processor needs to be responsible for its own subprocessors.
Rights of Data Subjects
Ensure that Data Processor provides assistance (which might be through tools made available to Data Controller) to action data subject requests:
Access and Correction: Processes for data subjects to access and correct their data.
Erasure and Objection: Provide mechanisms for individuals to request deletion of their data or object to processing.
Data Portability: Ensure individuals can transfer their data to another controller if required by law.
Breach Notification
Notification Timeline: Require the Data processor to notify the controller of a data breach within 72 hours or sooner.
Consider assigning an email address for notifications (rather than by mail).
- Required Details: The breach notification must include:
Nature and scope of the breach (e.g., unauthorized access, data loss, or ransomware attack).
Categories and volume of affected data (e.g., personal data types, number of impacted records).
Steps taken to mitigate risks and prevent further unauthorized access or damage.
Contact details for an escalation path within the Data Processor’s incident response team.
- Individual and Regulator Notifications:
Typically ensure Data Controller has control over the content of notices to affected individuals and the decision on whether to notify (unless otherwise required by law).
Require cooperation in regulatory investigations and compliance actions.
Costs and Expenses:
Ideally make Data Processor responsible for the costs associated with breach response, including forensic investigations, legal fees, individual notifications, and remediation efforts. Typically, this will be rejected.
However, ensure the Data Processor assumes financial responsibility if the breach results from their negligence or failure to follow security obligations.
International Data Transfers
Transfer Conditions: Ensure commitment that transfers outside the jurisdiction comply with data protection laws. Ideally require the Data Processor to ensure it completes transfer impact assessments (TIAs) and to share summaries of those TIAs upon request.
EU/UK: Ensure a lawful basis for transfer from EU/UK is specified. Either:
Adequacy Decisions: Recognition of adequate protection levels by the receiving country.
Standard Contractual Clauses (SCCs): Use of SCCs for lawful data transfers from the EU / UK.
Note: Typically, both are specified, and the SCCs will be incorporated by reference. If incorporated by reference, ensure that there are provisions selecting which of the options for certain clauses apply.
Note: The U.S. continues to be a problematic destination and so include a provision that the transfer conditions can be amended if required to comply with applicable law.
Audits and Inspections
Audit Rights: Data Controller should have the right to audit the Data Processor’s data protection practices.
Ideally this right is absolute. However, it is often preconditioned by other steps and a last resort only if required by law.
If physical audits are not permitted, ensure the Data Processor provides detailed security reports, including penetration testing results.
Third Party Audits and Certifications: Ideally the Data Processor has SOC 2 Type 2 Reports or ISO Certifications since the Data Controller is unlikely to conduct an audit.
Ensure commitments to remediate any deficiencies noted in audits and obtain a timeline for implementation.
Note: Ensure that the reports and certifications cover the services. E.g., a SOC report for AWS will cover the infrastructure only and not the Data Processor who is using AWS to run its app. So, the AWS report is necessary but not sufficient.
Note: The Data Processor may object to providing the SOC report for its infrastructure provider on the basis that it is confidential. E.g., for AWS, the end client needs to enter into an NDA with AWS via the AWS services. That’s ok and, if the Data Processor agrees to facilitate that, it is not an issue.
Subprocessor Considerations
Subprocessors are third parties engaged by the Data Processor to process personal data on its behalf. Careful scrutiny of subprocessor provisions is necessary to ensure that the Data Controller's data is protected throughout the processing chain. Key considerations include:
List of Approved Subprocessors: Request a list of all subprocessors and ensure it is regularly updated. The Data Controller should have the right to review and object to any changes. Typically, want at least 30 days. Notice may be given via a service the Data Processor signs up for.
Pre-Approval vs. Notice of Use: The DPA should specify whether Data Controller approval is required before the Data Processor engages a subprocessor. If prior approval is not feasible, at a minimum, require advance notice and an opportunity to object before new subprocessors are engaged.
Flow-Down Obligations: The Data Processor must ensure that subprocessors are contractually bound to the same data protection obligations as the primary Data Processor. Ensure no dilution of commitments on security, compliance, or breach notification.
Liability for Subprocessors: The Data Processor should remain fully responsible for the actions of its subprocessors. Avoid clauses that limit the Data Processor’s liability for subprocessors' failures. Very common to see this in smaller vendors who are trying to limit liability for AWS/Google etc.
Termination and Consequences
Return of Data: Identify how data will be returned (if it is to be returned).
Survival Clauses: Many Data Processors will try to terminate the DPA immediately on termination of the agreement. Ensure DPA provisions (other than permitted processing for the services) continue until the data is deleted (permanently incapable of reconstruction).
Liability and Indemnification
Liability Limits: Typically, caps on the Data Processor’s liability should be in the main agreement (not DPA)
Indemnification: Attempt to obtain an indemnity for breach of the DPA. Typically, should be in the main agreement.
Insurance Requirements: Ensure appropriate cyber liability insurance. Typically, should be in the main agreement.