Who Actually Needs a Data Processing Agreement (DPA)?

Executive Summary: Any business that shares personal data with a software vendor likely needs a DPA. The agreement defines the controller–processor relationship and sets standards for data protection. While many DPAs are embedded and non-negotiable, reviewing them is critical to managing regulatory and reputational risk.

You may have signed one without realizing it.

---

Most companies do not set out to negotiate a Data Processing Agreement (DPA). It usually appears as a link buried in a Software as a Service (SaaS) master service agreement (MSA). The vendor sends over a polished PDF of the MSA. Everything looks standard. Then somewhere in the middle, there is a sentence: “Customer agrees to the vendor’s Data Processing Addendum available at [link].”

That link matters.

If your company collects, stores, or shares personal data, you likely need to understand and possibly negotiate a DPA.

What Is a DPA?

A Data Processing Agreement governs how one party processes personal data on behalf of another. It is required under many privacy laws when a company (the “controller”) shares personal data with a third party (the “processor”).

Under laws like the EU’s General Data Protection Regulation (GDPR) and various U.S. state privacy statutes, controllers must ensure processors follow certain data protection standards. Even if you are based in Connecticut, New Jersey, New York, or Pennsylvania, you may still need a DPA if:

• You serve customers in the European Union

• You process data subject to Connecticut’s Data Privacy Act (CTDPA)

• You operate in states with similar privacy laws

• You contract with customers who demand it

  
  

The Controller vs. Processor Distinction

In most SaaS relationships:

• You (as SaaS customer) are the controller because you decide why and how personal data is used.

• The vendor is the processor because it processes data on your behalf.

This distinction matters. Controllers bear primary responsibility for data protection compliance. Processors must follow the controller’s instructions and maintain appropriate safeguards.

A DPA formalizes that relationship.

Under GDPR Article 28, a controller must use processors that provide “sufficient guarantees” of data protection. Similar obligations appear in Connecticut’s Data Privacy Act and other emerging U.S. state privacy frameworks.

If you are the controller, you are responsible for ensuring your vendors comply.

Who Needs a DPA?

You likely need a DPA if:

• You use cloud software that stores personal data.

• You collect customer emails, payment information, or employee data.

• You use payroll providers, CRMs, marketing platforms, or HR software.

• You provide services to larger companies that require data protection compliance.

In practice, most software-as-a-service agreements include a DPA. The issue is not whether it exists. The issue is whether you have reviewed it.

The Hidden Problem with DPAs

Vendors rarely highlight the DPA. It is often incorporated by reference in the MSA. You get the main contract in PDF form. The DPA is a hyperlink.

Even when provided, DPAs are frequently non-negotiable for smaller customers. And over time, some standards appear to have softened. Notification timelines may be vague. Security commitments may be general. Breach response terms may lack firm deadlines.

For example, some DPAs promise notification of a data breach “without undue delay” instead of within a defined number of days. That language may satisfy baseline requirements but offer limited practical protection.

Why does this matter? Because if there is a breach, your company—not just the vendor—may face regulatory scrutiny, customer claims, and reputational harm.

Under the FTC Act and state consumer protection laws, misleading representations about data protection can trigger enforcement. If your privacy policy promises strong safeguards but your vendor agreement does not require them, you may face exposure.

Negotiation: Art, Not Science

Can you negotiate a DPA? Sometimes. Your leverage depends on:

• How much you spend with the vendor

• How critical your business is to them

• The sensitivity of the data involved

• Your reputation and position in the market

Enterprise customers often secure stronger protections. Smaller customers may have limited room to negotiate. But even when the DPA is “standard,” you should still:

• Review breach notification timelines

• Confirm sub-processor transparency

• Understand data retention terms

• Evaluate audit rights

• Clarify indemnification language

• 
  

If your company handles health information, financial data, or children’s data, heightened standards may apply under HIPAA, GLBA, COPPA, or sector-specific laws.

When It May Not Matter as Much

Not every DPA deserves equal energy. If the data shared is low risk and limited in scope, and your exposure is minimal, a standard DPA may be acceptable. If the data includes customer financial records, employee Social Security numbers, or proprietary business information, scrutiny should increase.

This is where judgment matters. Data governance is not one-size-fits-all.

Why This Deserves Attention

Most companies assume their vendors “have it covered.” But if something goes wrong, regulators and customers will look at your contracts.

A DPA is not just paperwork. It defines who is responsible, how data is protected, and what happens if there is a breach. Ignoring it does not make it disappear.

Temple Law helps businesses across Connecticut, New Jersey, New York, and Pennsylvania review vendor agreements and data protection terms so companies can make informed decisions about risk and leverage.

---

FAQs

1. Is a DPA required under U.S. law?

Not always. However, state privacy laws such as Connecticut’s Data Privacy Act require certain controller–processor agreements. If you serve EU customers, GDPR mandates a DPA.

2. Can I refuse to sign a vendor’s DPA?

You can request changes, but many SaaS providers treat their DPA as standard. Negotiation leverage depends on your size and spending power.

3. What happens if I ignore the DPA?

You may assume regulatory responsibility without fully understanding the vendor’s obligations. In the event of a breach, unclear terms can increase your exposure.

4. Does every SaaS contract include a DPA?

Most do, even if it is incorporated by reference. Always check for linked data processing addenda.

5. What is the difference between a controller and a processor?

A controller decides how and why personal data is used. A processor handles data on the controller’s behalf under contract.