What to Put in a Client Data Processing Agreement
If your company handles personal data on behalf of another business, whether you're running their marketing automation, hosting their customer records, or processing payments for their platform, you're likely acting as a data processor. A data processing agreement (DPA) is the contract that defines what you're allowed to do with that data, what security you owe, and who bears responsibility if something goes wrong. This is different from a vendor agreement written to protect your own users' data, which we covered in an earlier post. Here, the roles are reversed: you're the vendor, and the DPA sets the terms your client will hold you to.
Getting the terms right matters for two reasons. First, many clients now require a signed DPA before they'll send you any data at all, particularly if they operate in regulated industries or serve consumers directly. Second, the clauses in a poorly drafted DPA can expose your business to liability far beyond what the underlying services contract contemplates. Below are the clauses that deserve real attention, not boilerplate.
Define the Scope of Processing Precisely
A DPA should spell out exactly what data you're allowed to touch, for what purpose, and for how long. This isn't a formality. If the agreement says you may use customer data only to "provide the services," you can't repurpose it for your own product analytics or marketing without breaching the contract, even if your general terms of service would otherwise allow it.
Specify the categories of data involved (names, emails, payment information, health data, employee records, whatever applies), the categories of people it belongs to, and the processing activities you'll perform: storage, transmission, analysis, deletion. Vague scope language creates ambiguity that favors whoever has more leverage in the relationship, and that's usually not the smaller vendor.
Set Security Obligations You Can Actually Meet
Clients will often push for language requiring "industry-standard" or "reasonable" security measures. That sounds fine until there's a breach and a court or regulator has to decide what "reasonable" meant. Better practice is to attach a specific security schedule: encryption standards, access controls, employee training requirements, whether you use multi-factor authentication, how backups are handled. If you already maintain a security framework (SOC 2, ISO 27001, or an internal policy), reference it directly rather than agreeing to open-ended language you'll have to interpret after the fact.
Be honest about what you can commit to. Promising controls you don't actually have in place is worse than negotiating a lower but accurate baseline, because a misrepresentation here can become the basis of a breach of contract claim independent of any actual data incident.
Nail Down Sub-processor Terms
If you use other vendors to help deliver the service, cloud hosting providers, email delivery services, analytics tools, those vendors are sub-processors, and most DPAs require you to either get the client's consent before adding one or provide notice with an objection window. Failing to address this leads to disputes down the road when the client discovers, often during an audit or a breach investigation, that a sub-processor they never approved has been handling their data.
The DPA should also require that you flow down equivalent data protection obligations to your sub-processors. If your sub-processor's security practices are weaker than what you promised the client, that gap becomes your liability, not theirs.
Breach Notification: Timing and Content
Both North Carolina and Pennsylvania have data breach notification statutes that require notifying affected individuals following a security incident involving certain types of personal information, generally on a timeline described as "without unreasonable delay." Neither state's statute currently sets a fixed number of days for all breaches, though the requirements and definitions of a reportable breach differ somewhat between the two states, and clients based elsewhere may be subject to stricter state or federal timelines. Your DPA should require you to notify the client promptly upon discovering a breach, not just once you've confirmed it's reportable, and should specify what information you'll provide: what happened, what data was affected, and what you're doing about it. Clients need lead time to meet their own legal notification obligations, and a vague or delayed notice clause on your end can put them in breach of laws that apply to them.
Data Return and Deletion at Termination
Every DPA should address what happens to the client's data when the relationship ends. Will you delete it, return it, or both? On what timeline? Does the client need written confirmation that deletion occurred? If you're required to retain data for your own legal or accounting purposes, the agreement should carve that out explicitly rather than leaving you in breach of a blanket deletion requirement.
Audit Rights, Kept Reasonable
Larger clients often want the right to audit your data practices, either directly or through a third party. That's a legitimate ask, but an unlimited audit right can be disruptive and expensive for a smaller processor. Negotiate reasonable limits: advance notice, a cap on frequency, confidentiality protections for what the auditor sees, and an option to satisfy the requirement with an existing certification or third-party report instead of a full on-site audit every time.
Liability and Indemnification
This is where many disputes actually end up. A DPA should state clearly whether liability for a data-related claim is subject to the same cap that applies under your main services agreement, or whether the client is asking for an uncapped or separately capped indemnity specific to data incidents. Clients frequently push for carve-outs from liability caps for data breaches, which can expose a vendor to damages well beyond what the underlying contract is worth. This is a heavily negotiated point, and it should be reviewed alongside any general limitation of liability provisions in your master agreement rather than treated as a standalone issue.
Where This Fits With Your Other Agreements
A DPA rarely stands alone. It usually attaches to or references a master services agreement or statement of work, and its terms need to be consistent with those documents rather than contradicting them. If you haven't already thought through how your master agreement and statement of work divide up obligations, that's worth addressing at the same time you build out your DPA.
Data processing terms get more scrutiny every year, from clients, insurers, and regulators alike. If your business processes data on behalf of others and you're working from a generic template or no written agreement at all, that's a gap worth closing before a client, or a regulator, forces the issue. S&A Law's privacy and data security practice helps businesses in North Carolina and Pennsylvania build agreements that hold up under real scrutiny. Reach out to schedule a consultation.