Your B2B SaaS company has a lot of legal surface area. Employment agreements, IP assignments, equity documents, corporate governance. All of it matters. But this post isn’t about any of that.
This is about the customer-facing contractual stack: the documents that govern every commercial relationship with the people paying you money. The documents that procurement teams evaluate, that enterprise buyers expect to see before signing, and that define your liability exposure on every deal.
I’ve reviewed hundreds of these stacks as a lawyer at a PE-backed serial software acquirer. The companies we look at range from bootstrapped five-person shops to venture-backed teams doing eight figures in ARR. And the pattern is consistent: the companies with a clean contracting framework aren’t the ones with the most documents. They’re the ones with the right four, done well.
Here’s what that framework looks like, why each document exists, and when each one becomes necessary.
The Four Documents That Matter
Your B2B SaaS legal stack has four components. Each serves a distinct purpose, and together they cover the contractual surface area that customers, prospects, and procurement teams evaluate.
1. Terms of Service (or SaaS Agreement)
This is your core commercial agreement. It governs the relationship between you and every customer who uses your product.
Your Terms of Service define the scope of access you’re providing, what customers can and can’t do with your product, how billing works, what happens when things go wrong, and how either side can walk away. It’s the document that sets your liability exposure, protects your intellectual property, and establishes the rules of engagement for every customer relationship.
One point worth noting: SaaS terms typically grant access to a hosted service, not a license to software. A license implies the customer is receiving a copy of the software to install and run, which is the on-premise model. In SaaS, the customer accesses your service over the internet and you maintain control of the underlying software. The distinction matters because it affects how IP ownership, usage restrictions, and termination rights are structured. If your terms say “license grant” but you’re providing hosted access, the language doesn’t match the delivery model.
If you have a product and customers are using it, you need Terms of Service. There’s no minimum revenue threshold or customer count that triggers this. Day one, terms should be live.
The mistake most founders make isn’t skipping terms entirely. It’s grabbing a generic template that doesn’t match their product. A template written for a consumer app includes provisions for individual users, COPPA compliance, and user-generated content moderation. None of that applies to your B2B workflow tool. Worse, that same template probably doesn’t include the billing mechanics your pricing model actually requires, or the data handling commitments your customers expect.
2. Privacy Policy
Your privacy policy is a disclosure document. It tells users and customers what data you collect, why you collect it, who you share it with, how long you keep it, and what rights they have.
For B2B SaaS, the privacy policy operates differently than it does for consumer apps. Your data subjects are often your customers’ employees, not individual consumers. Your data collection is shaped by the service you provide, not by advertising models. And your disclosure obligations come from a patchwork of state laws, not a single federal statute.
The key distinction founders miss: your privacy policy is a public-facing disclosure. It’s not a contract governing how you handle customer data. That’s what a DPA does. These two documents serve different purposes, and one doesn’t replace the other.
Every B2B SaaS company needs a privacy policy from day one. Even if you’re pre-revenue, if your product collects any data from users, a privacy policy is required under most US state privacy frameworks. And “data” here is broad: names, email addresses, IP addresses, usage analytics, and session data all count.
The consequences of operating without one are more concrete than most founders realize. State regulators can impose per-violation fines under statutes like the CCPA. Enterprise procurement teams treat a published privacy policy as a baseline vendor requirement. No policy, no further review. And if a data incident occurs, the absence of a documented privacy framework means you have no disclosed practices to point to in your defense. Plaintiffs’ attorneys specifically look for that gap.
3. Data Processing Addendum (DPA)
This is the document founders understand least and enterprise customers ask for most.
A DPA is a contract between you (the data processor) and your customer (the data controller) that governs how you handle their data. It sits alongside your Terms of Service as a separate agreement and covers processing scope, security obligations, breach notification timelines, subprocessor management, and data deletion procedures.
Most B2B SaaS companies operating today should have a DPA. Many don’t. And the ones that do often have one they copied from a larger company without understanding the commitments they’ve made. If your DPA promises annual penetration testing and a dedicated security team, and you’re a five-person startup running on managed cloud infrastructure, you’ve made legally binding promises you can’t honor.
The confusion around DPAs usually stems from two misunderstandings. First, founders assume their privacy policy covers what a DPA covers. It doesn’t. Your privacy policy discloses your data practices to the world. Your DPA contractually commits to specific data handling obligations with each customer. Second, founders don’t realize that enterprise procurement teams treat a ready-made DPA as a signal of operational maturity. If a prospect asks for your DPA and you don’t have one, you’re not just missing a document. You’re signaling that you haven’t thought about data governance, and the prospect is now evaluating whether to put you on their paper instead.
That’s the real cost: if you don’t bring your own DPA, you end up reviewing and negotiating against the customer’s template, which is always drafted to protect them, not you.
4. Service Level Agreement (SLA)
An SLA converts your infrastructure reliability into contractual commitments. It defines your uptime target, how uptime is measured, what’s excluded from the calculation, and what happens when you miss the target.
Not every B2B SaaS company needs an SLA on day one. If you’re selling to SMBs at lower price points, a general “commercially reasonable efforts” commitment in your Terms of Service is usually sufficient. The SLA becomes necessary when you’re selling to mid-market or enterprise customers who need defined uptime guarantees as part of their vendor evaluation.
The trigger is usually procurement. When a prospect’s security or IT team sends you a vendor questionnaire asking about your uptime commitments, response times, and remediation procedures, that’s when an SLA needs to exist as a standalone document. Having one ready means you control the terms. Not having one means you’re either scrambling to draft something under deal pressure or accepting whatever the customer’s template demands.
The critical principle with SLAs: promise what you can actually deliver. A single-region deployment on a shared database shouldn’t promise 99.99% uptime. That’s 52 minutes of allowed downtime per year. If your architecture can’t support it, your SLA shouldn’t promise it. Overpromising creates liability exposure and erodes trust when you inevitably miss the target.
There’s another dimension to SLAs that founders often overlook: an SLA is also a liability management tool. By defining your uptime commitment, the exclusions that apply, and the remedy when you miss (typically service credits), you’re putting a functional cap on your exposure for downtime. Without an SLA, a customer experiencing a major outage has an open-ended damages argument: lost revenue, business disruption, consequential losses. With a well-structured SLA, the remedy is defined and bounded. That makes the SLA as much about protecting you as it is about satisfying procurement.
When You Need Each Document
The short answer: all four, from day one.
That might sound aggressive for a seed-stage company, but the logic is straightforward. Each of these documents manages a different category of liability. Your Terms of Service cap your commercial exposure. Your Privacy Policy documents your data practices before a regulator or plaintiff asks about them. Your DPA defines your data handling obligations before an enterprise prospect puts you on their paper. Your SLA bounds your downtime liability before an outage gives a customer an open-ended damages argument.
Waiting until someone asks for a document means you’ve been operating without the protection it provides. If your first DPA gets drafted under deal pressure because a prospect’s procurement team requires one, you’re writing it reactively, with less leverage and less time to get it right. The same applies to SLAs: if you don’t define your uptime commitments and remedies until a customer experiences an outage, you’ve already lost control of the narrative.
From an operational readiness standpoint, having all four ready signals maturity to every customer you engage with. It removes friction from the sales process. And it means that when the first enterprise prospect does show up, you’re not scrambling. You’re sending a link.
There’s a structural reason these four documents need to exist together, not just individually: they reference each other and are designed to work as an integrated framework. Your Terms of Service incorporate the DPA and SLA by reference. Your DPA’s security commitments need to align with what your SLA promises about uptime and incident response. Your Privacy Policy’s disclosures about data sharing and retention need to be consistent with the processing scope defined in your DPA. If one document exists without the others, or if they’re drafted independently without cross-referencing, you end up with gaps or contradictions. A Privacy Policy that says you retain data for 12 months while your DPA commits to deletion within 30 days of termination, for example. The protection these documents provide is enhanced when used as a stack, as opposed to any single document in isolation.
The cost of having these documents ready before you technically need them is minimal. The cost of not having them when you do need them is real: unfavorable terms, extended sales cycles, and liability exposure you could have defined on your own terms.
Supporting Documents That Round Out the Stack
The four documents above are the core of your customer contracting framework. In practice, a few additional documents extend and support them.
Order Form. The Order Form is the commercial layer that sits on top of your Terms of Service. It contains the deal-specific details: pricing, subscription term, support tier, usage limits, and any customer-specific commitments. Your standard Terms, DPA, and SLA are incorporated by reference. The Order Form is the first document the customer sees and signs, putting the business terms front and center rather than burying them in the body of a legal agreement. This structure keeps your standard terms reusable across every customer while the Order Form captures the variables that change deal to deal.
Acceptable Use Policy. The AUP defines what customers can and can’t do with your service. It can live inline as a section within your Terms of Service or as a standalone document incorporated by reference. For most seed-stage companies, inline is simpler. A standalone AUP makes sense when the people who need to follow it (developers, end users) are different from the people who sign the contract, and need an accessible reference they can consult independently.
Subprocessor List. Your DPA commits to transparency about the third-party services that process customer data on your behalf. The subprocessor list is typically maintained as a separate schedule to the DPA or as a public webpage that can be updated independently. It names each subprocessor, describes the processing activity, and specifies the location. Maintaining this as a living document (rather than embedding it in the DPA itself) allows you to update it without amending the DPA every time you add or change a vendor.
Each of these is an extension of a core document, not an independent item. The Order Form extends the Terms of Service. The AUP extends or supplements the Terms. The subprocessor list extends the DPA. Together with the core four, they form the complete contracting framework your customers and procurement teams evaluate.
The Real Risk: Someone Else’s Paper
Here’s the practical reality that makes this urgent rather than aspirational.
If you don’t show up to a deal with your own legal documents, you don’t avoid legal complexity. You inherit it. Your customer sends you their terms, their DPA, their SLA. And those documents are drafted to protect them.
Their limitation of liability section will be structured in their favor. Their DPA will include security commitments calibrated to their vendor requirements, not your actual capabilities. Their SLA will include uptime targets and remedies designed for the enterprise vendors they usually work with, not for a seed-stage SaaS company.
You can negotiate, but you’re negotiating from a position of weakness. You’re on their paper, playing defense, reacting to their terms rather than setting your own. And every hour you spend redlining their documents is an hour you’re not building product.
The alternative is straightforward: have your own stack ready. Terms, Privacy Policy, DPA, SLA. Customized to your product, your data practices, your infrastructure, and your pricing model. When a customer asks for your terms, you send them. When procurement asks for your DPA, it’s ready. When the security questionnaire asks about your SLA commitments, you have an answer.
No Boiler provides self-service legal document generation and educational content. This material and our service is not a substitute for legal advice. Please have a qualified attorney review any documents before relying on them. No Boiler is not a law firm, and communications with us do not create an attorney-client relationship or carry any expectation of confidentiality. Use of our platform and content is governed by our Terms of Service and Privacy Policy.
This is the first post in a series covering the legal documents B2B SaaS founders need at each stage of growth. Next up: why template legal documents are worse than no documents at all.