DPA Checklist for SaaS: Data Processing Agreement Clauses to Review Before Signing

Overview

A DPA is typically used when one organization processes personal data on behalf of another. In common controller-processor arrangements, the customer determines the purposes and essential means of processing, while the SaaS provider performs defined processing activities under documented instructions. The exact roles can differ by service and applicable privacy law, so do not rely on the contract title alone. Read the main agreement, order form, privacy notice, security documentation, and DPA together.

The goal of a DPA review is to identify gaps between the contract and the way the product actually works. Start by mapping the service: what data enters the platform, who can access it, where it is stored, which integrations receive it, how long it remains available, and what the provider does after termination. This operational view is more useful than checking whether a document contains familiar headings.

A DPA should also align with your broader vendor risk assessment, privacy impact assessment, security requirements, and incident response process. If the vendor supports a regulated or high-risk workflow, involve privacy, security, procurement, and legal reviewers before approval. A DPA checklist supports review; it does not replace a legal assessment of the laws that apply to your organization or processing activities.

Checklist by scenario

1. Processing instructions and scope

• Identify the parties and describe their roles for each relevant processing activity.
• List the subject matter, duration, nature, and purpose of processing.
• Describe the categories of personal data, such as account details, contact information, usage data, support records, or other data your workflow may include.
• Identify the categories of data subjects, such as employees, customers, users, contractors, or applicants.
• State that the provider processes data only on documented instructions, subject to any clearly defined legal requirement to process otherwise.
• Explain how new processing features, optional integrations, analytics, or artificial intelligence functionality are authorized and documented.

Pay particular attention to broad wording such as “business purposes,” “service improvement,” or “as necessary.” Ask whether these terms permit uses beyond the service you purchased. If the provider wants to use customer data for product development, analytics, advertising, or model training, the contract should make the purpose, data involved, controls, and permissions clear.

2. Subprocessors and third-party services

• Request a current list of subprocessors, their functions, and relevant processing locations.
• Confirm that the provider remains responsible for subprocessors it appoints, to the extent required by the applicable arrangement and law.
• Check whether the provider must give advance notice of additions or replacements.
• Understand the objection process, including its deadline, acceptable grounds, and available alternatives if an objection cannot be resolved.
• Check whether the subprocessor list is incorporated into the agreement or merely published on a webpage that can change.

A subprocessor register should be usable for your own third-party risk management. Record each provider's service, data access, location, and criticality. If the SaaS product connects to your identity provider, help desk, payment platform, or cloud storage, determine whether those services are subprocessors, independent controllers, or part of your own environment.

3. International transfers and processing locations

• Document where personal data is stored, accessed, and supported.
• Identify the transfer mechanism or other legal basis relied on for each relevant cross-border transfer.
• Check whether remote administrative access from another country is treated as a transfer or otherwise addressed.
• Confirm who is responsible for transfer assessments, supplementary safeguards, and responding to changes in the transfer environment.
• Check whether the provider will notify you if a transfer mechanism becomes unavailable or requires replacement.

Do not assume that a data-hosting location answers every transfer question. Support personnel, subprocessors, backups, telemetry, and disaster recovery environments may create additional access or transfer paths. Align the DPA with your DPIA checklist and privacy impact assessment where international access is relevant.

4. Security measures and evidence

• Look for a technical and organizational measures schedule that addresses access control, authentication, encryption, resilience, logging, vulnerability management, secure development, backup, and recovery where relevant to the service.
• Confirm that security measures are appropriate to the data and the risks of processing, rather than accepting a generic security statement.
• Identify how the provider will notify you of material security changes.
• Specify the evidence available for review, such as independent assurance reports, certifications, testing summaries, or responses to security questionnaires.
• Check whether the security schedule is binding and whether it takes precedence over conflicting marketing or help-center descriptions.

Evidence should support your actual compliance obligations. A SOC 2 report, ISO 27001 certificate, or other assurance document may be useful, but it does not automatically prove that every requirement in your environment is satisfied. Define which controls matter to your risk assessment and how exceptions will be handled. For related evidence planning, see the SOC 2 audit readiness checklist.

5. Incidents, data subject requests, and regulatory assistance

• Define what constitutes a personal data breach or security incident for notification purposes.
• Check the notification method, required content, escalation contacts, and expected timing.
• Confirm that the provider will support investigation, containment, remediation, and legally required communications.
• Explain how the provider will assist with access, correction, deletion, restriction, portability, objection, or other data subject requests that apply to your processing.
• Address support for privacy impact assessments, regulator inquiries, and records needed to demonstrate compliance.

A vague promise to provide “reasonable assistance” may leave important details unresolved. Ask what assistance is included, what information can be provided, who coordinates the response, and whether urgent requests follow a different channel. Connect these provisions to your incident response plan so the contract can be used during a real event.

6. Retention, return, and deletion

• Set out what happens to customer data when the service ends, an account is closed, or a retention period expires.
• Define the available format and process for returning or exporting data.
• Address backups, disaster recovery copies, logs, caches, and data held for legal obligations.
• Specify how deletion is confirmed and whether a certificate or written attestation is available.
• Check whether the provider can retain aggregated, anonymized, or de-identified information and how those terms are defined.

Deletion terms should match your offboarding plan. Test an export before termination if the data is operationally important. Also document how you will remove copies from connected systems under your control.

7. Audits, liability, and contract changes

• Check whether you can obtain enough information to verify compliance and conduct proportionate audits.
• Review notice periods, confidentiality rules, reasonable limitations, cost allocation, and access to relevant facilities or records.
• Confirm how audit findings, corrective actions, and unresolved material issues are managed.
• Read liability caps, exclusions, indemnities, and insurance terms together with the DPA; do not assume the DPA overrides the main agreement.
• Understand how amendments are made, including updates to security measures, subprocessors, transfer provisions, and legal language.

Contract-change notices should be operationally useful. A provider's right to update a webpage may not give your team enough time to assess a material change. Establish who receives notices, how they are logged, and what happens if a change creates unacceptable privacy or security risk.

What to double-check

Use the checklist alongside a documented vendor risk scoring guide. Escalate unresolved issues based on data sensitivity, service criticality, transfer exposure, and the practical ability to change providers. A low-risk marketing tool may justify a different review depth from a platform containing employee records, health information, payment data, or production credentials.

Common mistakes

• Signing the DPA without reading the product terms. The DPA may not cover data used in optional features, support tickets, analytics, or integrations.
• Treating a security certification as a complete privacy review. Assurance evidence can support the review but does not define processing purposes, retention, or data subject assistance.
• Ignoring the subprocessor mechanism. A list is useful only if your team can monitor changes and act on an objection.
• Accepting indefinite retention. Ask what remains in backups, logs, and derived data after account closure.
• Using one DPA for every workflow. Different products, regions, data categories, and customer obligations may require different schedules or assessments.
• Failing to assign ownership. A signed contract does not create an operating process. Name owners for notices, incidents, access requests, audits, and renewals.

When to revisit

Review the DPA before signing a new SaaS contract, adding a materially different feature, changing the data collected, enabling a new integration, or expanding into a new processing location. Revisit it when the provider changes subprocessors, security measures, retention practices, transfer arrangements, or contract language. It should also be part of the annual privacy-program review, vendor renewal cycle, and any risk assessment triggered by a new business process.

Keep a lightweight DPA review record with the contract version, processing description, subprocessor list, transfer assessment, security evidence, open issues, decision owner, and next review date. Add recurring reminders to your cybersecurity compliance calendar and connect material changes to continuous monitoring where available.

Before approval, complete three practical actions: map the service's data flows, resolve or formally accept material gaps, and test the response and offboarding contacts. Then store the executed agreement where procurement, privacy, security, and operational owners can find it. This turns a DPA from a one-time signature into a working control for vendor risk and data protection compliance.