Contract or Policy?

Short answer: use a contract when you need a commitment neither side can change unilaterally (caps, indemnities, service levels); use a policy when you need the freedom to change the rules as your business evolves (security practices, support hours, acceptable use). The test is whether you need to be bound or need to be flexible.

While this is a complex issue, from the perspective of a software and SaaS attorney, here are some practical tips on when to use policies and when to use contracts.

Contracts.

Contracts are mutual agreements between two parties. Both sides commit to obligations, and neither side can change the terms without the other’s consent. The two ingredients are mutual assent and consideration (something of value flowing both ways), which is what makes a promise enforceable as a contract. Use contracts when (a) the customer relationship is significant and you need a clear, enforceable framework, (b) you need to address specific commitments like liability caps, indemnities, or service levels, and (c) there is consideration flowing both ways (money for service).

Policies.

Policies are unilateral statements by the software company about how it operates. The company can generally change a policy without the customer’s consent. That is the key feature. Use policies when (a) you need flexibility to adapt without renegotiating, (b) the topic is operational rather than contractual (security practices, support hours, acceptable use), and (c) you want to communicate something to customers without making it a hard commitment.

A Few Worked Examples.

Abstract rules are easy to nod along to and hard to apply, so here is how I sort the common ones for SaaS vendors:

• Service levels and uptime. Usually a contract (an SLA). Customers are paying for availability and want a remedy if it slips; you want that remedy bounded (service credits, not damages).
• Acceptable use. Usually a policy (an AUP referenced by the contract). You need to add a newly-abused behavior next week without amending every customer agreement.
• Security practices. Usually a policy, but referenced by the contract with a “no material degradation” commitment. That gives the customer comfort without freezing your security program in amber.
• Support hours and response targets. Usually a policy, unless an enterprise customer pays for a contractual support tier.
• Privacy. A hybrid. A public privacy policy describing practices, plus contractual data protection terms (a DPA) where the customer needs enforceable commitments.

Where It Goes Wrong.

The biggest mistake I see: putting things in a contract that should be in a policy, then being unable to change them when the business evolves. You hard-code your support hours or your security stack into 200 signed agreements, and now a routine operational change requires 200 amendments. The opposite mistake is just as costly: putting something in a policy that customers reasonably expect to be contractually binding (an uptime number, a data-handling promise), so when it matters there is no enforceable commitment and a lot of unhappy expectations. Match the instrument to whether you need to be bound or need to be free.

Frequently Asked Questions.

Can I just put everything in the contract to be safe? No. Anything in a signed contract needs the customer’s consent to change, so operational items you revise often (support hours, security details, acceptable use) become a renegotiation burden. Reference those from a policy instead.

Are my policies legally binding? Sometimes, if incorporated into the contract by reference. Standing alone, a policy is a unilateral statement you can change, which is exactly why it is the wrong home for promises a customer needs to enforce.

Where does privacy go? Both places. A public privacy policy describes your practices; a DPA gives regulated customers the enforceable data-protection commitments they require.

A few related reads on managing the customer side of every deal. 3 Things Every SaaS Company Should Remember in Enterprise Deals covers price and terms linkage. SaaS Contract Negotiations Are Not All About the Software covers buyer psychology. 6 Tips When Your Customer Insists on Their Form Agreement covers when to push back on buyer paper. And on streamlining your paper and deciding what belongs in a contract versus a policy, see Who Else Is Streamlining Their Agreements?

Disclaimer:

This post is for informational and educational purposes only, and is not legal advice. You should hire an attorney if you need legal advice, which should be provided only after review of all relevant facts and applicable law.