Kohler Law Group
Insights / Privacy & data

Data Processing Agreements (DPAs): What US SaaS Companies Should Know

What a data processing agreement is, when a DPA is required under GDPR and US state privacy laws, and which DPA terms SaaS companies should negotiate.

By Robert Kohler, Founder & Attorney8 min read

Key takeaways

  • A DPA governs how a vendor handles personal data on a customer’s behalf; it supplements the main contract rather than replacing it.
  • GDPR Article 28 and many US state privacy laws require specific contract terms when a business shares personal data with a processor or service provider.
  • Subprocessors, security, breach notice, audits, deletion, and international transfers are where most DPA negotiation happens.
  • SaaS sellers benefit from a well-built DPA of their own, while buyers should test vendor DPAs against the data and obligations actually involved.

What is a data processing agreement (DPA)?

A data processing agreement, often called a data processing addendum, is a contract that governs how a vendor processes personal data on behalf of a customer. It sets the vendor’s processing instructions, confidentiality, security, subprocessor, breach notice, audit, and deletion obligations, and it helps both parties meet privacy laws such as the GDPR and US state laws.

For a SaaS company, the DPA usually attaches to the subscription agreement or master services agreement. The main agreement covers the commercial deal; the DPA covers the privacy and data protection rules that apply when the service touches personal data about the customer’s employees, users, or customers.

The terminology varies by law. The GDPR distinguishes a controller, which decides why and how personal data is processed, from a processor, which processes data on the controller’s behalf. The California Consumer Privacy Act uses “business,” “service provider,” and “contractor,” while several other state laws use controller and processor. A SaaS vendor is often the processor or service provider for customer data and a controller for its own account and marketing data.

When is a DPA required?

A DPA is generally required when a company subject to the GDPR or a comparable US state privacy law uses a vendor to process personal data on its behalf. Customers also commonly require one by contract even where a specific statute may not.

Health information covered by HIPAA is handled through a business associate agreement, which is a separate document with its own required terms. Some vendors need both.

  • GDPR: Article 28 requires a written contract, which can be electronic, whenever a controller uses a processor. The GDPR can reach US companies that offer goods or services to, or monitor the behavior of, individuals in the EU.
  • California: the CCPA requires a written contract with service providers and contractors that includes specific restrictions. Under the California regulations, a recipient without a compliant contract may not qualify as a service provider, which can change how the disclosure is treated.
  • Other states: comprehensive privacy laws in states such as Virginia, Colorado, and Connecticut require a binding contract between a controller and a processor that sets out processing instructions and related duties.
  • Customer requirements: enterprise buyers often require a DPA as part of vendor onboarding, regardless of which laws apply to a given dataset.

What terms does GDPR Article 28 require in a DPA?

Article 28 requires the contract to describe the processing and to bind the processor to act only on documented instructions, keep data confidential, implement appropriate security, control subprocessors, assist the controller, delete or return data at the end, and support audits.

  • Subject matter, duration, nature and purpose of processing, types of personal data, and categories of data subjects.
  • Processing only on the controller’s documented instructions, including for international transfers.
  • Confidentiality commitments from personnel authorized to process the data.
  • Security measures appropriate to the risk, as described in Article 32.
  • Use of subprocessors only with the controller’s authorization, with equivalent obligations flowed down.
  • Assistance with data subject requests, security, breach notification, and data protection impact assessments.
  • Deletion or return of personal data at the end of the services, unless law requires retention.
  • Information needed to demonstrate compliance, and allowance for audits and inspections.

What do US state privacy laws require in service provider contracts?

US state laws generally require the contract to limit the vendor’s use of personal data to the specified business purposes, prohibit selling or sharing it, require appropriate protection, and give the business rights to verify and stop unauthorized use.

The California requirements are among the most detailed. A CCPA service provider contract typically must identify the business purposes for processing, prohibit selling or sharing the information, prohibit retaining, using, or disclosing it outside the direct business relationship except as permitted, restrict combining it with other data, require the vendor to comply with the CCPA and provide the same level of privacy protection, and require notice if the vendor can no longer meet its obligations. The California Privacy Protection Agency’s regulations add detail on these terms.

Because state requirements overlap but are not identical, many SaaS companies build one DPA with a US state law section rather than separate documents for each state. State law varies, so the DPA should be reviewed as new laws take effect.

How do Standard Contractual Clauses fit into a DPA?

When personal data subject to the GDPR is transferred to a country without an adequacy decision, the parties need a transfer mechanism. The European Commission’s Standard Contractual Clauses are the most common one and are usually incorporated into the DPA by reference.

The current SCCs, adopted by the Commission in 2021, use modules for different relationships, such as controller to processor and processor to processor. The parties select the right module, complete the annexes describing the processing and security measures, and generally assess whether the destination country’s laws allow the clauses to be honored in practice.

US recipients that have self-certified under the EU-U.S. Data Privacy Framework may be able to rely on that framework instead, and UK transfers use their own mechanisms. Because transfer rules continue to evolve, confirm the current status of each mechanism when the DPA is prepared or renewed.

Which DPA terms are most often negotiated?

The most negotiated terms are subprocessor approval, security commitments, breach notice timing, audit rights, deletion, liability, and who pays for assistance.

  • Subprocessors: a published list, advance notice of changes, and a right to object, often with termination as the remedy if the parties cannot agree.
  • Security: a security exhibit that describes real controls, rather than a promise of “industry standard” measures.
  • Breach notice: notice “without undue delay” or within a fixed number of hours, plus what information and cooperation the vendor will provide.
  • Audits: reliance on independent reports such as SOC 2 or ISO 27001 certifications first, with on-site audits limited in frequency and scope.
  • Deletion: timing, backups, and whether the vendor certifies deletion on request.
  • Liability: whether DPA claims fall within the main agreement’s cap, a super cap, or no cap.

How should SaaS sellers and buyers approach DPAs differently?

Sellers should publish a consistent DPA they can operate at scale. Buyers should map the data they will share and test the vendor’s DPA against their own legal obligations and customer commitments.

For a SaaS seller, every bespoke DPA creates an operational obligation someone must track: a different notice deadline, a different audit right, a different subprocessor approval process. A clear standard DPA, a current subprocessor list, and a security summary can shorten sales cycles and reduce the number of one-off promises. Exceptions should go through a defined approval path.

For a buyer, the DPA should match the data actually flowing to the vendor. A tool that receives only business contact details presents different risk from one that stores customer records or sensitive data. The buyer’s DPA terms should also support any commitments it has made to its own customers, so that obligations flow down rather than stop at the buyer.

What practical steps help a company manage DPAs?

Keep a data inventory, maintain current DPA templates, track subprocessors and notice obligations, and align the DPA with the privacy policy, security program, and main commercial agreement.

  • Inventory which vendors process personal data, what data, and under which laws.
  • Record signed DPAs, transfer mechanisms, and notice deadlines in the contract system.
  • Coordinate breach response plans with vendor notice and cooperation commitments.
  • Review templates when new state laws, regulations, or transfer rules take effect.

Authoritative resources

Questions answered

Frequently asked questions

Is a DPA the same as a data processing addendum?

In practice, yes. Data processing agreement and data processing addendum describe the same type of document. It is called an addendum when it attaches to a main agreement, such as a SaaS subscription agreement or master services agreement, rather than standing alone as a separate contract.

Does a US company with no EU customers need a DPA?

It may. The GDPR may not apply, but US state privacy laws such as the CCPA require specific contract terms with service providers and processors when the business is covered. Enterprise customers also frequently require a DPA as a condition of buying, regardless of which statutes apply.

Who drafts the DPA, the customer or the vendor?

Either can. Large customers often insist on their own DPA, while SaaS vendors usually offer a standard DPA designed for their service. Vendors serving many customers often prefer their own version because consistent terms are easier to operate, but key terms are still frequently negotiated.

What is a subprocessor?

A subprocessor is a third party that a processor engages to process personal data on the customer’s behalf, such as a cloud hosting provider or support platform. GDPR Article 28 requires the customer’s authorization and flowed down obligations, and DPAs usually include a list and a change notice process.

Do Standard Contractual Clauses replace a DPA?

No. Standard Contractual Clauses address international transfers of personal data subject to the GDPR. A DPA covers the broader processor relationship. In practice, the SCCs are often incorporated into the DPA as an exhibit, with annexes describing the processing and the security measures.

Continue reading

This article provides general information, not legal advice. Reading it or submitting the website form does not create an attorney-client relationship. Legal outcomes depend on the facts, contract language, and applicable law.

Continue the conversation

Put senior legal judgment behind the next decision.

Explore SaaS & software agreements
Schedule a discovery call