So you work for a software-as-service (SaaS) vendor and you have your standard SaaS Agreement that you send to customers for signing prior to onboarding. As part of your SaaS Agreement package, you also have a Data Protection Addendum (DPA) template that governs data privacy and security provisions.
The goal is that your customers will use your contractual templates. But often, you receive redlines for classic items, like the limitation of liability and indemnity clauses. Some customers even send their template DPA for review, refusing to use yours because they are the data owner and want to maintain control over the DPA terms.
This customer’s request creates potential confusion, greater liability, new operational promises, and client experience friction. But your sales team really wants to sign them.
What can you do to be a good business partner while also protecting the overall business? This article lays out four options you can use to manage this issue, in priority order from a vendor’s perspective.
1. Explain the “Operational Truth” for why your DPA should be the foundation
This is the best approach for the vendor since it reflects its actual processes, which I like to call the “operational truth”. You can explain to the customer that you run a scaled service which prioritizes consistency and stability for the entire client base and keeps pricing efficient. If you start creating bespoke technical operations on a one-off client basis, that breaks the scale, consistency, and price efficiency of your operations.
For these reasons, it makes the most sense to use the vendor’s DPA as-is, so that the promises match the client experience, and the pricing remains efficient. I like to explain to customers that bespoke customer processes require greater vendor resources, which in turn increases the cost of the vendor’s services. The customer is not typically looking to increase its price, so this explanation gives the customer an internal explanation for what they understand the value of a consistent and scaled vendor processes.
Great work if this is your result.
2. Add reasonable clauses from the customer’s DPA to close specific gaps
If the customer remains insistent that the vendor’s DPA is not acceptable as-is, you can ask the customer to identify specific items in their DPA that they feel are gaps in the vendor DPA. This way you can keep your foundation and only review specific items that seem reasonable and that don’t deviate (too much) from your standard operations. If you’re unsure about any new responsibilities being requested, check first with your hosting or data security team.
Still a good result at this stage.
3. Use the customer’s DPA as the foundation but water it down
Some customers will not move forward due to “policy” (or similar) reasons without their DPA being the foundation. This becomes a bit more work but still doable because you can take their DPA and do a map against yours.
First, water down the bespoke operational requirements to become higher level promises that generally match your standard operations.
Then, include specific items from your standard DPA to close gaps. Again, if you’re unsure about any new responsibilities check with your hosting or data security team.
At this stage you’re being a very accommodating vendor so I hope you’re winning good will with the sales team and customer!
4. Sign up and plug nose
The most unfortunate situation is a customer that will not sign the agreement without their DPA being agreed as-is. As the vendor you are now in a (slightly) concerning situation where you could be signing up to data security and hosting obligations that do not fall into your standard operations.
This is a bit stressful but we still have a couple of options to mitigate the risk of signing up to bespoke customer data security and hosting obligations.
First, identify the operational concerns and copy those out into a meeting invite with your hosting or data security team to determine how atypical these processes might be. Maybe they’re no big deal, or perhaps there’s a technical or internal solution.
Second, if these are a big deal (such as: bespoke business continuity/failover processes, or cumbersome continuous technical audit obligations) but signing is more important, then you can get the functional leaders to align (ideally in an email for context later) that we are signing up to these commitments knowing we may not be able to perform some of them, but the reward is worth the risk.
A bit more nerve-wracking, but hey this is the business world, not Utopia!
* * *
On the vendor side, there is always a fine line to balance between revenue generation/retainment vs. risk management. Each company sits somewhere on the risk appetite continuum. I’d encourage being curious about where your company is today, and wants to be, on that continuum so you can build processes that remove deal friction and maintain as much of your data security and hosting team’s standard processes as possible.
You won’t win them all, but these four tips have helped me manage my fair share to a good result.
