The DPA used to be a niche document. It is now closer to an NDA in frequency, but with much higher stakes when it goes wrong. Lawyers who do not negotiate DPAs every day end up reviewing them anyway, often under deal pressure, and the gap between what the law actually requires and what vendor templates ask for is where most of the risk hides.
This How to Contract webinar was hosted by Laura Frederick and featured Marybeth Stramaglia, Founder of MHS Contract Services, and Carly Penner, Senior Director of Global Commercial Legal at Forter. Marybeth brought 25 years of in-house and outside contract work across startups and Fortune 50 companies. Carly is a trained privacy lawyer running global commercial legal at a SaaS company that handles personal data at scale. Between them, they have seen every version of how a DPA negotiation goes right and wrong.
The conversation covered when a DPA is actually required versus nice-to-have, what belongs inside it and what should stay in the master, how to draft a workable breach notification clause, where vendor templates shift risk back to customers, how to track divergent state laws, how subprocessor flow-down really works, and how to handle cross-border transfers using the updated standard contractual clauses.
Here are our top ten takeaways from the speakers' comments during the webinar:
Start with the data flow before you start the redline. The first move on any DPA is figuring out what personal data is actually moving, where it sits, and who touches it. That is what tells you whether you need a DPA at all, and if so, how aggressive to be. Reviewing a DPA in the abstract without that picture means missing the risks that matter and fighting over language that does not.
A DPA is only required when there is personal data and the right relationship. Controller-to-processor relationships require one. Controller-to-controller relationships do not, although customers often ask for one anyway. Joint controller relationships do not require Article 28 terms but may benefit from additional written protections. Push back on DPA requests that do not meet the threshold, especially when the deal is moving fast and a DPA will slow it down for no legal benefit.
Keep the DPA about personal data and push everything else into the master. Liability caps, indemnities, breach and cure timing, and audit rights all belong in the master agreement. When they end up in the DPA, the deal team starts thinking about privacy risk in isolation, which scares everyone and produces worse outcomes than looking at the full risk picture together. The DPA itself should only govern how personal data gets handled. That discipline keeps the document from turning into the kitchen sink.
Scan vendor templates for littered indemnities. Vendors will scatter narrow indemnities and liability provisions across multiple sections of the contract. Each one looks innocuous on its own. Together they undo the negotiated liability framework. Look in the tax section, the environmental section, the DPA, and any addenda for indemnities that should be sitting in the main liability section instead.
Treat the breach notification clause as the most important provision in the agreement. This is the clause that gets pulled out at three in the morning when something has gone wrong. The definition has to match GDPR or another statutory definition. The time period needs to be specific, usually somewhere between 48 and 72 hours. The cost allocation has to acknowledge that the vendor is not an insurance provider. And there should be one breach clause in the contract, not two with conflicting requirements.
The vendor DPA's defaults are where the risk hides. Bare-bones GDPR and CCPA compliance is the floor, not the ceiling. The security section will say "reasonable measures." The data transfer section will say "complying with law." Pick the few provisions that matter most for the data you are actually moving and dig into those. Accepting the defaults means accepting the vendor's preferred risk allocation.
Build a state-law tracking system you will actually use. California, Connecticut, Virginia, and the growing list of other states have divergent requirements. The IAPP, law firm newsletters, and state-specific cheat sheets all help. AI tools help with summary and translation, but the law still has to be read at least once. Buzzwords matter, and AI will not flag the ones that come straight from the statute.
Cut jurisdiction-specific appendices that do not apply. Multi-jurisdiction DPAs often come with appendices for jurisdictions the deal does not touch. Delete them. Carrying inapplicable obligations through an agreement is a quiet way to acquire obligations you never agreed to. The right structure is a core DPA for common requirements plus targeted appendices for the jurisdictions that actually matter.
The subprocessor objection right is worth fighting for when the data is sensitive. Many vendors default to a no-objection-right model with a published list on their website. For low-risk data that may be fine. For health data, financial data, or special categories, the customer needs at least notice with enough lead time to update its own privacy notice and consent flows. Operationally, a new subprocessor is not just a contract event.
Use the right SCC module, and add supplementary measures. Almost every customer defaults to module one even when the relationship is controller-to-controller and requires a different module. Get that right. Add supplementary measures, either inside the DPA or referenced as an exhibit. Add a government access clause that says the vendor will reject improper requests, comply only as legally required, and notify the customer. That language exists for a reason.
Subscribe to Stay in the Loop
Our weekly newsletter brings you upcoming How to Contract webinars and practical recaps like this one. Subscribe now so you never miss the next one.
