Controller or Processor? What Your DPA Says About Who Controls the Data

Sep 11

5 min read

Executive Summary: In many SaaS relationships, the client acts as the controller and the vendor acts as the processor. The controller decides why and how personal data is processed, while the processor handles it according to the controller’s instructions. A DPA should clearly define those roles, permitted uses, security requirements, subprocessors, and any independent uses of the data.

Your company signs up for a software platform and uploads customer information. The vendor stores it, analyzes it, and may send it through other systems to provide the service. So who is responsible for that data?

The answer is rarely “the vendor who stores the data.”

In many vendor relationships, the client remains responsible for deciding why personal data is being used, while the vendor handles that data on the client’s behalf. Those two roles—controller and processor—are central to a Data Processing Agreement (DPA). Getting them wrong can create problems with privacy compliance, vendor oversight, and even the promises you make to your own customers.

What Is the Difference Between a Controller and a Processor?

A controller decides the purpose and means of processing personal data. A processor handles personal data on the controller’s behalf and according to its instructions.

The Connecticut Data Privacy Act (CTDPA) uses this distinction. The Connecticut Attorney General explains that a processor acts at the direction of a controller. If the processor starts deciding for itself why and how data will be used, it may become a controller for that processing.

The same basic framework appears in the EU’s General Data Protection Regulation (GDPR). Under the GDPR, a controller determines why and how personal data is processed, while a processor performs processing for the controller.

Your role comes from what you actually do with the data, not simply what the contract calls you. The privacy laws that apply can also depend on whose data you process and where those individuals are located. A Connecticut-based business, for example, may need to account for privacy laws in other U.S. states when serving customers there, as well as the GDPR or UK GDPR when processing personal data of individuals in the EU or UK, provided the applicable law’s jurisdictional requirements are met.

What Is the Client Responsible For?

In a common SaaS relationship, the client is the controller. It decides what customer information to collect, why it needs the information, and which vendors can access it. That means outsourcing data processing does not outsource all responsibility for it.

For businesses covered by the CTDPA, controller duties can include limiting collection to data that is adequate and reasonably necessary, providing required privacy notices, protecting personal data, honoring consumer rights, and obtaining consent before processing certain sensitive data.

The stakes can be even higher for healthcare and healthtech companies. Connecticut now applies its consumer health data provisions to consumer health data controllers without the general law’s usual processing thresholds. Those controllers also must have written contracts requiring processors that receive consumer health data to comply with applicable CTDPA requirements, including confidentiality requirements.

Depending on the business and information involved, HIPAA or other federal requirements may apply as well.

What Is the Vendor Responsible For?

The processor does more than promise to keep data safe. A strong DPA defines what the vendor may do with personal data, the type of data involved, the purpose of processing, security obligations, confidentiality requirements, and what happens when the relationship ends.

It should also address subprocessors.

Your vendor may rely on cloud hosting providers, analytics platforms, AI providers, or other third parties. Your data could therefore travel beyond the company named on the contract.

Under GDPR Article 28, processors generally cannot appoint another processor without the controller’s prior specific or general written authorization. Processor contracts must also address issues such as documented instructions, confidentiality, and appropriate security measures.

That’s why reviewing a vendor’s subprocessor list can be just as useful as reviewing the main DPA.

What Happens When the Vendor Wants to Use the Data for Itself?

This is becoming a bigger issue as software vendors add AI features.

Suppose a vendor processes your customer data to provide its software service. That fits naturally within the processor role. But what if it also wants to use that information to train its own AI model or develop unrelated products?

Now the analysis can change.

The European Commission notes that a processor that begins using personal data for its own purposes may be acting as a controller for that use.

Businesses should therefore look closely at clauses covering product improvement, analytics, aggregated data, AI training, and other secondary uses. Do not assume “processor” means the vendor has no independent rights to your information.

Broad secondary-use rights can be a significant red flag because they may allow data to be used beyond the purpose for which your company originally collected or disclosed it. That can create privacy and contractual concerns, particularly if the data includes confidential, sensitive, health-related, or customer information, or if your own agreements and privacy notices promise more limited use.

A DPA Should Reflect the Real Relationship

DPAs are often treated as secondary documents. A SaaS vendor may send you an MSA while incorporating its DPA through a hyperlink several pages into the agreement.

Do not stop at the MSA.

Check what data the vendor receives, what it can do with it, which subprocessors can access it, and what protections apply if something goes wrong. Then compare those terms with your own privacy policies and customer commitments.

The goal is consistency between what you promise and what your vendors actually do.

Know Where Your Responsibility Ends (and Where It Doesn’t)

Signing a DPA does not automatically solve your data privacy concerns. The useful question is whether the agreement accurately describes what happens after your information leaves your systems.

Temple Law, PLLC helps businesses in Connecticut, New Jersey, New York, and Pennsylvania review DPAs, SaaS agreements, and vendor data practices. If you need a clearer picture of who controls your data and where it goes, contact us to discuss your agreements.

FAQs

Can a company be both a controller and processor? Yes. A company may be a processor for one activity and a controller for another, depending on who determines the purpose and means of each use of personal data.

Is the SaaS vendor always the processor? No. The actual use of the data determines the role. A vendor using information for its own independent purposes may act as a controller for that activity.

What should a controller look for in a DPA? Review processing instructions, confidentiality, security requirements, breach procedures, subprocessors, deletion or return of data, and secondary uses.

What is a subprocessor? A subprocessor is another party a processor uses to process personal data, such as a cloud hosting or AI provider.

Are healthcare companies subject to additional DPA requirements? Potentially. HIPAA may apply to certain protected health information, while state privacy laws can impose separate requirements. Connecticut has specific protections for consumer health data.