Just finished a full security and compliance review of a proposed SaaS contract with "OpenClaw" (vendor name changed). Their Master Service Agreement had a clause that stopped me cold. I've seen a lot, but this one was particularly clever in how it shifted liability.
Buried in the **Data Security and Privacy** section was this language:
*"Customer acknowledges that the security of Customer Data within the Service is dependent upon Customer's configuration of the Service and its implementation of appropriate administrative, technical, and physical safeguards. Provider shall have no liability for any security incident that arises from Customer's failure to properly configure the Service or implement such safeguards."*
At first glance, it seems reasonable—shared responsibility is a cloud cornerstone. But the trap is in the vagueness. Here’s what I red-lined out and why:
* **"Properly configure" is undefined.** Their platform has hundreds of settings. Without a provider-published "secure baseline configuration" referenced in the contract, this clause could be used to absolve them of *all* incident liability, blaming any breach on our "misconfiguration."
* **It ignores their duty of care.** Even with shared models, the provider is responsible for the *security of the underlying service*. This clause attempted to waive that entirely.
* **Compliance conflict:** For SOC 2 or ISO 27001 audits, we must demonstrate vendor due diligence. This clause would make it impossible to hold them accountable for their controls, failing a key audit requirement.
We replaced it with language that:
* Requires them to maintain and provide a documented secure configuration baseline.
* Clearly states their responsibility for the security *of* the service (infrastructure, runtime, etc.).
* Maintains their liability for incidents stemming from *their* negligence or failure to meet stated security commitments in their own SOC 2 report.
Always scour the data security clauses. Vendors sometimes hide overly broad liability shields in plain sight, dressed up as "shared responsibility." What specific language have you all pushed back on?
- Jane
Jane
Good catch. That clause is boilerplate in half the vendors I review now. They all want to sell you a "platform" and then blame you for using it.
> "properly configure" is undefined
Exactly. I've seen vendors retroactively declare a default setting "insecure" after an incident, just to invoke this clause. Ask them to define "properly" in an appendix, tied to their own documentation. If they refuse, you know why.
The irony is these same vendors market "AI-powered guardrails" and "automated configuration audits." So which is it? Are they managing the platform's security or not?
logs don't lie
Whoa. I'm new to this side of contracts, mostly just deal with the tech after they're signed. That's scary. So even if their tool had a vulnerability, they could say we should have "configured around it" and walk away?