Write your Terms of Service and Privacy Policy
An 8-step playbook. Open in Dock and you'll get four surfaces seeded:
- **Steps** (table) — the 8 gates as rows, owner + due + status
- **Clauses** (table) — the 25-30 specific clauses every SaaS ToS needs
- **Brief** (doc) — the canonical write-up plus the ToS + privacy drafts
- **Versions log** (table) — every published version of both docs with the change-log
Read `Steps` top-to-bottom. The single biggest mistake is treating these as a one-shot template fill-in. They're living documents that have to match what your code actually does.
Outcome
ToS + Privacy Policy + Cookie Notice + standard DPA published, lawyer-blessed, version-controlled, and matching what your product actually does.
Estimated time: 1-2 weeks
Difficulty: intermediate
For: Founders launching a SaaS or web product.
What you'll need
Pre-register or install before you start.
- Termly (Free tier; $10/mo Pro; $99/mo Pro+) — Generates ToS + privacy + cookie notice from a questionnaire. Solid starting point.
- Iubenda (From $27/year for privacy + cookies) — Privacy + cookie generator with strong EU coverage. Used by many EU-facing companies.
- Stripe Atlas legal documents (Free templates) — Stripe's reference templates for ToS + privacy. Free, well-respected starting point.
- Common Paper (Free) — Free standard contracts (MSA, DPA, NDA) that real lawyers actually use.
- Lawyer (1-3 hours) ($300-$800 for review) — A real lawyer reviews your final draft. Worth the spend; templates miss product-specific risk.
The template · 8 steps
Step 1: Decide what kind of agreement you actually need
Estimated time: 1 hr
Most SaaS needs three documents: Terms of Service (the contract between you and the user), Privacy Policy (the GDPR/CCPA notice), and a Data Processing Agreement (the back-end contract for B2B customers whose users you process data for). Some businesses also need an Acceptable Use Policy, an SLA, and an EULA for downloadable software. Pick the set you actually need before you write a word.
Tasks
- Decide: is this a clickwrap (user clicks 'Accept' on signup) or a signed contract (B2B, MSA-style)?
- Decide: do you need a separate DPA for B2B customers? (Yes if you process personal data on their behalf.)
- Decide: do you need an SLA? (Only if you commit to uptime / support response times.)
- Decide: do you need an Acceptable Use Policy? (Yes if your product can be misused.)
- Document the document set in the Brief
Pointers
[!CAUTION] Gotchas
- Browsewrap (a tiny 'by using this site you agree to terms' link in the footer) is unenforceable in most US courts. Clickwrap with an explicit checkbox is the standard.
- B2B customers will demand a DPA whether or not you have one. Pre-draft so the first procurement question doesn't take a week to answer.
- An SLA you wrote because everyone has one is a liability. Only commit to uptime / response times you can actually deliver, with clear remedies (service credits) for misses.
Step 2: Capture what your product actually does
Estimated time: 1 day
Most ToS / privacy template fails are because the doc doesn't match the product. Before you write, build a one-page product spec: what users do, what data flows, who pays whom, what's in scope, what's out of scope. The legal docs ride on top of this spec. Without it, you're filling in a generic template with vague guesses.
Tasks
- Write a 1-page product spec: what the product does, who uses it, what they pay
- List every personal data field collected (email, name, IP, payment, behavioral)
- List every sub-processor (Stripe, AWS, SendGrid, OpenAI, Datadog, etc.)
- List every paid feature, free feature, and how billing works (subscription / usage / one-time)
- List every integration that creates legal obligations (OAuth scopes, API access, webhooks)
- Save the spec in the Brief — both ToS + privacy will reference it
Pointers
[!CAUTION] Gotchas
- If the spec contradicts the product, the legal docs will too. A founder writing 'we do not collect IP addresses' while their analytics SDK is sending IPs is a real GDPR violation.
- Pricing edge cases (free trials that auto-convert, prorated cancellations, refund windows) all need explicit ToS clauses. List them in the spec.
- AI features that train on user input need their own clause. State explicitly: do you train on user content? If yes, opt-in or opt-out?
Agent prompt for this step
Read this codebase + the product landing page + any internal product specs and produce a 1-page legal-grade product spec.
Output:
1. What the product does (in plain English, 2-3 paragraphs)
2. Who uses it (target user, role, intended use cases)
3. Pricing model (free / freemium / subscription / usage-based / one-time / mixed)
4. Personal data collected (every field, where stored, how long retained)
5. Sub-processors (every third party that processes user data)
6. Integrations (OAuth scopes, API surface, webhooks)
7. Out of scope (what the product is NOT, to set ToS expectations)
Output to the Brief surface as a versioned product-spec section. The ToS + privacy notice will derive from this spec.
Step 3: Draft the Terms of Service
Estimated time: 2-3 days
A SaaS ToS typically has 25-35 clauses across 6 sections: Definitions, Account & Use, Payment & Subscription, Intellectual Property, Liability & Disclaimers, General Provisions (governing law, dispute resolution, modification). Use a respected starting template (Stripe, Common Paper, your competitor) but rewrite every clause to match your product spec.
Tasks
- Pull a starting template (Stripe Atlas / Common Paper / Termly / a competitor's public ToS)
- Rewrite the Definitions section to match your terminology
- Write Account & Use: signup eligibility, account security, prohibited uses
- Write Payment & Subscription: pricing, billing, refunds, cancellation, auto-renewal
- Write Intellectual Property: who owns what (your platform IP vs user content)
- Write Liability & Disclaimers: limit of liability, warranty disclaimer, indemnification
- Write General Provisions: governing law, dispute resolution (arbitration vs court), modification process
- Save the draft in the Brief; track each clause as a row in Clauses
Pointers
- [Official] Common Paper Cloud Service Agreement
- [Guide] Stripe Atlas Terms of Service template
[!CAUTION] Gotchas
- Limit of liability caps are heavily product-specific. The default 'fees paid in the past 12 months' clause may not be enforceable for high-value B2B contracts; for consumer products it may be too aggressive.
- Governing law + dispute resolution clauses (arbitration vs court, jury waiver) are the most-fought clauses in court. Get a lawyer specifically on these.
- Auto-renewal terms have specific consumer-protection rules (California's Auto-Renewal Law, EU consumer rules). Generic clauses get fined; explicit clauses with reminders work.
Agent prompt for this step
Draft a Terms of Service for this SaaS based on the product spec in the Brief.
Use the Common Paper Cloud Service Agreement as the structural reference. Adapt every clause to this product. Output:
1. Definitions (User, Account, Service, Subscription, Content, Confidential Information)
2. Account & Use (eligibility, security, prohibited uses, content rights, suspension)
3. Payment & Subscription (pricing, billing, refunds, cancellation, auto-renewal, taxes)
4. Intellectual Property (your platform IP, user content ownership, license to use, feedback)
5. Liability & Disclaimers (warranty disclaimer, limit of liability, indemnification — both directions)
6. General Provisions (term, termination, governing law, dispute resolution, modification, severability, notices)
Plain language. No "WHEREAS" / "HEREINAFTER". Each clause should be 1-3 paragraphs. Mark sections that need lawyer review (limit of liability cap, governing law, arbitration vs court).
Output to the Brief surface as a versioned ToS section.
Step 4: Draft the Privacy Policy
Estimated time: 1-2 days
Your privacy policy is the public-facing version of your GDPR / CCPA / state-law disclosures. It must list every category of personal data, every purpose, every sub-processor, every retention period. The big mistake is copying a competitor's privacy policy without auditing what YOUR app actually collects. Match the data inventory exactly.
Tasks
- Pull the data inventory from the product spec (or build one — see GDPR playbook)
- Draft the privacy policy with all 12+ items required by GDPR Articles 13-14 + CCPA disclosures
- Include: identity of controller, purposes, legal bases, recipients, retention, transfer mechanisms, rights
- Include CCPA-specific clauses: 'Do Not Sell My Info,' categories of personal information sold (if any), right to delete
- Include cookie disclosure (or link to a separate cookie notice)
- Save the draft in the Brief; cross-check every claim against the data inventory
Pointers
- [Official] GDPR Articles 13-14
- [Official] CCPA / CPRA full text
- [Official] ICO privacy notice checklist
[!CAUTION] Gotchas
- A privacy policy that under-claims what your app collects is THE most common GDPR + CCPA fine trigger. Audit before drafting.
- Don't copy 'we may share your data with third parties' — name them. GDPR + CCPA both require sub-processor lists.
- If you operate in California: 'Do Not Sell My Personal Information' is a required prominent link if you sell personal info (broadly defined to include certain advertising data exchanges).
Step 5: Draft the Data Processing Agreement (B2B)
Estimated time: 1 day (using a template)
If you have B2B customers (companies who use your product to process THEIR users' data), they'll demand a DPA. Common Paper publishes a free standard DPA used by hundreds of SaaS companies — start there. The DPA covers: scope of processing, sub-processor list, security measures, breach notification, data return / deletion on termination, audit rights.
Tasks
- Pull a starting DPA template (Common Paper / Stripe / a respected competitor)
- Customize the scope: what data, for what purposes, for what duration
- Attach the sub-processor list (with onboarding process for adding new ones)
- Customize the security measures section (encryption, access control, breach response)
- Set the breach notification window (24 hours is common, GDPR's 72 is the legal floor)
- Set data return / deletion terms on contract termination
- Save the draft in the Brief; expose at yourdomain.com/dpa or via a 'sign DPA' button
Pointers
- [Official] Common Paper Data Processing Agreement
- [Official] EU Standard Contractual Clauses (2021)
[!CAUTION] Gotchas
- If you're US-based and your customers have EU users, your DPA needs Standard Contractual Clauses (SCCs) attached to handle international transfers. Skipping SCCs makes the DPA insufficient.
- The sub-processor list lives in the DPA but evolves over time. Build a 'we'll notify you 30 days before adding a sub-processor' clause + a public sub-processor page.
- Customer-pushed redlines on a DPA are normal. Track them in the Versions log; the lawyer fee is worth it once the redlines start coming.
Step 6: Build the cookie consent + cookie notice
Estimated time: 1 day
Cookie consent is enforced under the EU ePrivacy Directive + UK PECR + (increasingly) US state laws. Non-essential cookies (analytics, advertising, social) require user consent BEFORE they fire. The cookie notice lists every cookie set, the purpose, and the retention. Most SaaS uses a generator (Cookiebot, Cookieyes, Iubenda).
Tasks
- Audit every cookie + tracker on your site (Chrome DevTools → Application → Cookies)
- Categorize: strictly necessary / functional / analytics / advertising
- Pick a CMP: Cookiebot, Cookieyes, Iubenda, OneTrust
- Configure: strictly-necessary loads always; everything else gates on consent
- Make 'Accept All' and 'Reject All' equally prominent (CNIL ruling, 2021)
- Generate the cookie notice (CMPs auto-generate from the scan)
- Publish at yourdomain.com/cookies
Pointers
- [Tool] Cookiebot
- [Official] CNIL guidance on cookies
[!CAUTION] Gotchas
- 'Reject All' has to be one click. CNIL has fined Google €150M and Facebook €60M for burying it. Match 'Accept All' visually.
- Cookie scanners miss client-side trackers loaded by third-party SDKs. Audit manually with browser DevTools too.
- Loading Google Analytics or a Facebook pixel BEFORE consent is given is a top GDPR violation. Configure tag managers in consent-gated mode.
Step 7: Get a real lawyer to review
Estimated time: 1 week (lawyer turnaround)
Generated docs are 80% of the way there. The remaining 20% is product-specific risk that templates miss: limit of liability cap appropriate to your contract sizes, IP carve-outs that match your actual model, indemnification scope, governing law that's enforceable for your customer base. Budget 1-3 hours of a SaaS lawyer's time ($300-$800) for a final review.
Tasks
- Find a SaaS-experienced lawyer (UpCounsel, recommendations from peers, Common Paper's lawyer directory)
- Send them: ToS draft, privacy policy draft, DPA draft, product spec, data inventory
- Schedule a 1-hour call to walk the lawyer through your business model
- Receive redlines; integrate the changes; re-circulate if substantial
- Get sign-off in writing (email is fine)
- Save the lawyer-blessed final versions in Versions log
Pointers
- [Tool] UpCounsel — find a lawyer
- [Guide] Common Paper lawyer directory
[!CAUTION] Gotchas
- A general-practice lawyer who 'does some tech work' is a bad fit for SaaS docs. Hire someone whose practice is 70%+ SaaS / tech. Their template is closer to your reality.
- Lawyer redlines come back in tracked changes Word docs. Keep your master in a tracked-changes-friendly format (Word, Google Docs) until final.
- Don't ask the lawyer to 'rewrite from scratch' if you've already drafted. That's a $5k bill. Ask for a focused review of risk areas (limit of liability, IP, dispute resolution).
Step 8: Publish + version + maintain
Estimated time: 1 day setup, 1 hr/quarter maintenance
Hosting a ToS is mostly straightforward, but the maintenance is where most SaaS companies fall down. Every material change needs a version bump, a 30-day user notice, and a record of what changed when. Build the rhythm now so the docs don't drift away from reality 6 months in.
Tasks
- Publish ToS at yourdomain.com/terms with last-updated date + version history
- Publish privacy policy at yourdomain.com/privacy with last-updated date + version history
- Publish DPA at yourdomain.com/dpa or as a click-to-sign in-app
- Publish cookie notice at yourdomain.com/cookies
- Add the ToS + privacy links to the signup form with an explicit checkbox + the email footer
- Set up a process for material changes: 30-day user notice via email, version bump, audit log
- Schedule quarterly reviews to check that docs still match reality
Pointers
[!CAUTION] Gotchas
- Material changes (price increases, scope changes, IP changes, dispute-resolution changes) require user notice. Silent updates of material clauses are unenforceable.
- Last-updated dates lie if you don't have a version history. Keep a public versions log so users can see what changed when.
- If you change the privacy policy and your processing is materially different, you need to re-collect consent for any consent-based processing. Don't skip this in version bumps.
Agent prompt for this step
Quarterly review pass: read the latest sprint's PRs + product changes and check whether the ToS, privacy notice, DPA, or cookie notice need an update.
For each change, output:
1. The change (e.g. "Added OpenAI for AI features")
2. The doc(s) that need an update (ToS for new feature scope; privacy for new sub-processor; DPA sub-processor list)
3. The specific clauses affected
4. Whether the change is material (requires 30-day user notice) or non-material (silent update with version bump)
Output as new rows on Steps for each doc that needs an update.
Hand the template to your agent
Paste the prompt below into your agent's permanent system prompt so the agent reads, writes, and maintains this workspace as you work through the steps.
You are an agent on the "Write your Terms of Service and Privacy Policy" playbook workspace at your-org/write-terms-of-service-and-privacy-policy.
Your role: maintain the four surfaces (Steps, Clauses, Brief, Versions log) as the user works through the 8-step playbook.
Cadence:
- When the user marks a step Done, append a line to the Brief summarising what's now in place.
- When the user pastes a finalised draft into Brief, snapshot it as a row on Versions log with the date.
- When the user adds a new feature that materially affects the ToS or privacy (new sub-processor, new data category, new payment flow), open a row on Steps for the version bump.
First MCP tool calls:
1. list_surfaces(workspace_slug="write-terms-of-service-and-privacy-policy")
2. list_rows(workspace_slug="write-terms-of-service-and-privacy-policy", surface_slug="clauses")
3. get_doc(workspace_slug="write-terms-of-service-and-privacy-policy", surface_slug="brief")
Do NOT publish a draft without lawyer review. If the user asks you to "ship the ToS", remind them step 7 is lawyer review.
FAQ
Can I just use a template generator and skip the lawyer?
For a side project: probably yes; the template generators (Termly, Iubenda) cover the basics. For a real business with revenue or B2B contracts: no. Templates miss product-specific risk: limit-of-liability caps appropriate to your contract sizes, IP carve-outs for AI features, indemnification scope, governing law that's actually enforceable. Budget $300-$800 for a 1-3 hour SaaS lawyer review of your final draft.
How long should the Terms of Service be?
Short and clear beats long and bulletproof. Stripe's Services Agreement is ~3500 words. AWS Customer Agreement is ~12,000 words. The right length is whatever your product spec demands — every clause should map to a real risk. Don't pad.
What's the difference between a ToS and a Privacy Policy?
ToS is the contract: what users agree to when they use your product (rights, obligations, liability, payment, dispute resolution). Privacy Policy is the legally-required disclosure: what personal data you collect, why, with whom you share it, how long you retain it, what rights users have. They're separate documents; sometimes a privacy policy is referenced from inside the ToS.
Do I need a Data Processing Agreement?
If you have B2B customers whose users you process personal data on behalf of: yes, you'll be asked for one in procurement, often by week 2 of any enterprise sale. Common Paper's free standard DPA is the right starting point. If you're consumer-only with no B2B path, you may not need one yet — but many SaaS companies add it the day the first B2B prospect asks.
Can my AI agents help draft these documents?
Yes, for the first draft. Agents are good at: building the product spec from your codebase, drafting the data inventory, drafting initial ToS and privacy text from a template + your spec, scanning new PRs for changes that affect the docs. They are NOT a substitute for lawyer review on liability, IP, and dispute resolution clauses. The playbook ships agent prompts inline.
How often do I need to update these documents?
Quarterly review at minimum. Material change updates: when you add a sub-processor, change pricing materially, add a new product feature with new data flows, change governing law or limit of liability. Material changes typically require a 30-day user notice (email + in-app banner). Non-material changes can ship silently with a version bump.