Am I the only one who thinks the liability cap in their agreement is absurdly low?

You're absolutely not alone, that "twelve months' fees" cap is practically an industry standard joke. It's designed to shield them, not make you whole.

I've seen some success with negotiation, but it's entirely dependent on your leverage and the provider's size. For a mid-market SaaS vendor, we got the cap raised to 3x ACV. For a major cloud provider, they wouldn't move the cap itself, but we did get a critical carve-out: liability for data breaches and confidentiality breaches remained uncapped. That's often a more achievable win than moving the number.

The "standard" line is their opening gambit. The real question to ask them is: "If this incident is entirely your fault and causes catastrophic loss, why should your financial responsibility be limited to a fraction of the value we derive from you?" It forces them to defend the indefensible. Sometimes that creates just enough pressure.

Walked away. Twice. Both times with major, household-name IaaS providers. The sales engineering team came back after procurement closed the file. Got a 5x ACV cap on the second round with one of them.

Your point about the incentive is the real issue. They have no skin in the game. Their SLA credits are a rounding error. The cap needs to hurt for them to care.

Your "walk away" strategy is powerful because it flips the script. The sales team's metrics are based on closed deals, not perfect contracts, so a lost procurement file creates real pressure.

But I'd add a caveat from the data side: a higher monetary cap alone doesn't address operational recovery. We once negotiated a 10x ACV cap but paired it with specific, binding obligations for incident response timelines and data restoration procedures in the SOW. The money is a deterrent, but the procedural commitments are what actually minimize the damage during an outage.

Without those, even a 5x cap just becomes a slightly more expensive cost of doing business for them.

You're right, the twelve-month fee cap is a joke. But the real joke is how it interacts with their other terms, particularly the indemnity clauses. They'll happily cap their liability to a pittance, but their indemnity for IP infringement often has no cap at all. The asymmetry is breathtaking.

The incentive problem you mentioned is the core of it. If their maximum exposure is a refund, they'll optimize for cost over resilience every time. I've had some luck by shifting the negotiation away from just the cap number. Instead, demand that the incident response and restoration SLAs in the SOW be made contractual obligations, with specific penalties for missing them that are *separate from* the liability cap. It doesn't raise the cap, but it forces them to commit real resources to fixing their mess, which sometimes hurts more than money.

That said, for a core transactional system, walking away is the only sane move if they won't give you a multiple of ACV. "Standard" just means they've convinced everyone else to accept a bad deal.

That asymmetry between a hard cap on general liability and an uncapped indemnity for their own IP issues is a critical observation. It reveals the cap isn't about managing risk, it's about allocating it entirely to the customer.

Your pivot to binding operational commitments in the SOW is the most practical path forward when the cap number itself is immovable. In data pipeline contexts, we've used this to lock in not just restoration timelines, but specific RPO/RTO commitments with escalating service credits that operate outside the liability clause. The provider's operational team hates these because they're measurable and unavoidable, which creates the internal pressure you want.

But for a core platform, if they won't budge on a multiple of ACV, the asymmetry you've pointed out is itself a valid reason to walk. It signals a fundamental misalignment on where responsibility should lie.

Exactly. You've hit on the core dynamic. Their legal team knows the IP indemnity is a low-probability event for them, so they can afford to leave it uncapped to look generous. Their operational failure is a high-probability event, hence the ironclad, laughable cap.

Your point about SOW commitments is the only real tool when the cap number is locked. I'd add that you have to be viciously specific in defining the "incident" that triggers those obligations. I once saw a provider try to wriggle out of an RTO penalty by arguing the clock started at their "first internal alert," not our declared outage. We now define the start time as *our* written notification, with an acknowledgment required within 15 minutes.

But if they won't move on ACV *and* fight you on SOW language, that's the signal. They're not a partner; they're a landlord with a clever lease.

That's a really sharp point about the high-probability vs low-probability risks. Makes total sense now why the terms are built that way.

The detail about defining the start time as your written notification is crucial. I wouldn't have thought of that. Is that kind of specificity something you can usually get them to agree to, or does it start another big fight?

Yes, getting them to agree to that specificity starts a fight every single time. Their boilerplate always defines the incident start based on their own monitoring, which is a black box. The negotiation becomes about shifting the trigger to an external, customer-controlled event.

The trick isn't to argue fairness, it's to embed the mechanism in the SOW's reporting procedures. We define the notification as a ticket created in their own support portal with a specific severity tag, and the acknowledgment as a system-generated email from that ticket. This ties their own tooling to the contractual clock. If they refuse that, they're telling you their support process is too broken to be accountable to.

It's tedious, but it turns a fuzzy legal argument into a testable integration requirement. Their ops team usually prefers the clarity, even if legal squirms.

Exactly. Tying the trigger to *their own support system* is the only way to make it operational instead of legal. We do the same, but we also require the severity tag to auto-create an alert in our Grafana dashboard. That gives us a real-time, auditable log of when the clock actually started for our own incident timelines.

One caveat: make sure their portal's ticket creation has an API. If it's only a manual web form, they can argue delays. We got burned once because their "system-generated email" had a 90-second lag on high-volume days. Now the clause includes "timestamp from the API response."

Their ops team usually does prefer the clarity. It's their legal department that treats any measurable commitment like a threat.

Tying the start time to the API response is clever, but it assumes the API is stable. I've seen vendors quietly deprecate or throttle the exact endpoint used for ticket creation, especially during major incidents. Suddenly your airtight clock starts drifting because their "system is under load."

Their legal department isn't just treating measurable commitments like a threat, they're actively designing the service to avoid them. The real trick is getting the SOW to specify the API's performance SLA alongside the incident response one. Good luck with that.

That line about "a landlord with a clever lease" is so painfully accurate. It perfectly captures the mentality you're dealing with when they dig in on both fronts.

Your method of defining the start time is key, but I'd stress that the 15-minute acknowledgment window can become a loophole itself. We had a provider send a generic auto-reply within the window, then claim that met the "acknowledgment" requirement, even though no human or actionable response followed for hours. We had to amend ours to specify "acknowledgment by a named support engineer, including a preliminary impact assessment." It's another layer of tedious, but it closes off their easiest escape route.

Nope, you're not the only one, and "standard" is just their opening position. On your specific questions:

We did get a multiple of ACV once, but only by bundling it with a longer term commitment. Think 3x ACV in exchange for a 3-year deal. It's a trade.

On exclusions, gross negligence is a non-starter for the big guys. They'll fight it tooth and nail. Data breach carve-outs are slightly more negotiable, but they often try to limit it to direct costs, not business loss.

I've walked away. When a core platform vendor wouldn't move an inch, we found a smaller, hungry competitor who accepted a more balanced risk model. Their sales line is a test. If they won't even *try* to escalate it to legal for a serious deal, that tells you everything.

Oh wow, this whole thread is a massive reality check for me. I'm neck-deep in planning a migration right now and honestly hadn't even looked at the liability section yet. I was so focused on the technical SLOs.

Seeing you all break down the "standard" cap like that is terrifying. If our main production database goes down because of their error, that fee cap wouldn't even cover our payroll for the outage response team, let alone lost revenue.

So, a naive question from someone who hasn't been through this fight: when they say "it's standard," is that basically the end of the discussion with the sales rep? Do you have to demand to talk to someone in legal directly to even have a shot at changing it? That feels like a daunting step to take.

The sales rep line about it being "standard" is usually just a filter. They'll say that to everyone who doesn't push.

My experience is smaller. We once got them to use the *greater of* that 12-month fee or a fixed dollar amount. The fixed amount was still low, but it was better than a month's fee. It proved they could move if they wanted the business.

How do you even start that push back? Is the first step just refusing to sign and sending the marked-up agreement back?