SaaS Contracts After the Connecticut Data Privacy Act — The Provisions Your Vendor Template Is Missing

The Connecticut Data Privacy Act, Conn. Gen. Stat. § 42-515 et seq., took effect on July 1, 2023. By now most SaaS providers serving Connecticut customers have updated their consumer-facing privacy notices. The contract terms, by contrast, are lagging. When I review a SaaS vendor agreement for a Connecticut customer today — whether on the customer side or the vendor side — the privacy provisions are still usually written for a pre-CTDPA world. The gap between what the Act requires and what most vendor templates actually say is where the compliance risk lives.

What the CTDPA requires in a processor contract

Section 42-520 of the Act governs the relationship between a controller (typically the SaaS customer) and a processor (typically the SaaS vendor). The statute requires the contract between them to address at least the following: the nature and purpose of processing, the type of personal data, the duration of processing, the rights and obligations of both parties, a duty of confidentiality for personnel handling the data, a requirement that the processor delete or return personal data at the end of the engagement, an obligation to cooperate with assessments, and specific constraints on subcontractor (subprocessor) engagement.

This is not a list of nice-to-haves. The Act makes the contractual terms a regulatory prerequisite for the processor relationship. A SaaS agreement that lacks them does not meet the CTDPA standard, and the Attorney General's office — which has enforcement authority under § 42-527 — has signaled in its public guidance that processor-controller contracts are within the enforcement scope.

The gaps I see most often

Three gaps come up in nearly every template I review.

No express subprocessor flowdown. Vendor templates commonly permit the vendor to use subcontractors "in its reasonable discretion" without imposing any contractual obligation to bind those subcontractors to equivalent privacy and security terms. The CTDPA requires that flowdown. A SaaS agreement that lets the vendor hand data to its own infrastructure providers, support vendors, or analytics partners without passing through the same confidentiality, deletion, and assessment obligations is out of alignment with the Act.

No deletion or return mechanism at termination. Most vendor templates address "data portability" — i.e., export of customer data during the engagement — but are silent on what happens at the end. The CTDPA is not silent on this. The processor must delete or return personal data at the end of the relationship at the controller's direction, and that obligation needs to be in the contract text, not just the privacy policy.

No cooperation commitment for DPIAs and rights requests. The Act requires controllers to conduct data protection assessments for certain processing activities (§ 42-522) and to respond to consumer rights requests under § 42-518. In both cases, the controller typically cannot fulfill those obligations without information or action from the processor. A vendor contract that does not obligate the vendor to cooperate in those workflows is a compliance problem for the customer. On the vendor side, the mirror issue is that vendors who sign up for unbounded cooperation obligations are exposing themselves to significant operational cost; the right answer is a bounded, specific obligation, not silence in either direction.

The CT-NY-MA-CA overlay

One complication: most SaaS contracts serve customers in multiple states, and the privacy compliance overlay now includes California, Virginia, Colorado, Utah, Oregon, Texas, and a growing list of others alongside Connecticut. A vendor that drafts for the California CCPA baseline may or may not be covering the Connecticut requirements, because while the CTDPA was modeled on the Virginia statute and cross-references heavily, there are drafting-level differences — particularly around sensitive data, opt-in consent, and the definition of sale — that a CCPA-oriented template does not reliably capture.

The cleanest approach I have seen is a master services agreement with a jurisdiction-agnostic data processing addendum (DPA) that incorporates state-specific riders by reference. The DPA establishes the framework, and state riders handle the specific requirements of Connecticut, California, and wherever else. This is more contractual infrastructure than many small and mid-sized SaaS vendors want to maintain, but it is the model that scales.

If you are renewing a SaaS contract this year

Three things I would look at before signing a renewal:

1. Does the vendor expressly commit to the CTDPA processor requirements, ideally by reference to § 42-520(b) or equivalent?
2. Is there a subprocessor list (either in the contract or in a linked, version-controlled webpage) and a requirement that subprocessors sign on to equivalent terms?
3. Is there an end-of-engagement data handling provision with specific timing (30 days is typical) and a certification mechanism?

For Connecticut-domiciled customers signing SaaS contracts with out-of-state vendors, and for Connecticut-domiciled SaaS vendors updating their templates, the Corporate group's technology transactions practice can redline or draft from scratch. Most of the work is straightforward — the templates are not hard to update once the gaps are identified.