Terms of service vs privacy policy: sort each clause
A privacy policy explains what happens to personal data; terms of service set the rules of use. Sort 16 clauses and know which page to update.
Kristian Hoffmann
SaaS founder and operator
Terms of service vs privacy policy comes down to two different questions. Terms of service set the rules of the deal: what the provider offers, what users may and may not do, and how payment, cancellation and disputes are handled. A privacy policy describes what happens to personal data: what is collected, why, who receives it, how long it is kept, and whom to contact about it. One governs conduct. The other discloses data handling. That split is why the two usually sit on separate pages, even when a single sign-up checkbox links to both.
Web designers get this question from the other side of the desk. A client asks you to "add the legal pages" before launch, and you end up holding a pile of clauses copied from three other sites. If you need the basics first, meaning what terms of service are and which clauses they usually hold, read Terms of service: what it is and why you need one. This article stays on the boundary between the two pages. It gives you a one-question test for sorting clauses, a worked example with sixteen clauses, and a list of site changes that should send you back to each page. It covers how the documents are organised, not what they have to say. The wording belongs to the client and their counsel.
The one question that sorts a clause
Ask this of every sentence: is it about what someone may do, or about what happens to someone's data?
Conduct goes into the terms. Data goes into the privacy policy. If the honest answer is "both", the sentence is doing two jobs and needs splitting.
Terms of service: the rules of the deal
Terms of service, also called terms of use or terms and conditions, are defined by Wikipedia as the legal agreements between service providers and service consumers (Wikipedia: Terms of service).
What goes into the terms depends on the business model. A subscription site writes about renewals and cancellation. A platform with user uploads writes about what people may post. A brochure site with no accounts and nothing for sale may have very little to put here.
Privacy policy: the account of the data
A privacy policy is a written notice to the people whose personal data a site or service handles. What goes into it depends on the data inventory, not the business model. Every form field, analytics script, embedded calendar, newsletter provider and hosting location shows up somewhere in it.
For maintenance, this is the difference that counts. The terms record decisions you made about your offer. The privacy policy records the tools you happen to run this quarter.
Privacy policies usually come up in connection with data protection law, such as the EU's General Data Protection Regulation (GDPR) or the California Consumer Privacy Act (CCPA). For personal data covered by the GDPR, Articles 13 and 14 list the information people must be given, for example who the controller is and how to contact them, the purposes and legal basis of the processing, the recipients, how long data is stored and which rights people have (GDPR on EUR-Lex). In California, a business covered by the CCPA must also update the privacy-policy disclosures listed in Civil Code § 1798.130(a)(5) at least once every 12 months, so that page gets a yearly review even when the tool stack stays the same (Cal. Civ. Code § 1798.130). Whether and how such a law applies to a particular site is a question for counsel. Read the source before you rely on any template.
When a sentence belongs on both pages
Take "You can delete your account at any time." Deleting the account ends the user's access and any paid plan. That is part of the deal, so it goes in the terms. What happens to the files and profile data afterwards, and how long backups keep them, is data handling, so it goes in the privacy policy.
Split the sentence in two, and link the pages to each other at that point. Someone asking "can I cancel?" lands in the terms. Someone asking "is my data gone?" lands in the privacy policy. Each finds a full answer on the page they opened.
Side by side: what each document does
| Terms of service | Privacy policy | |
|---|---|---|
| Question it answers | What are the rules for using this? | What happens to my personal data? |
| Written about | The offer and the user's conduct | Collection, use, sharing and retention of data |
| Content comes from | Business model: plans, prices, accounts, uploads | Data inventory: forms, tools, vendors, hosting |
| Typical sections | Acceptable use, payment, cancellation, suspension, changes to terms, governing law | Data collected, purposes, recipients, retention periods, contact for requests |
| How it is framed | An agreement the user accepts | A disclosure the reader is informed by |
| Reopened when | The offer changes | The tool stack changes |
| Version history records | What users agreed to, and when | What the site disclosed, and when |
The "how it is framed" row describes how the documents are presented. It is not a legal assessment of what clicking "I agree" does.
Large providers keep the two apart. Google's Terms of Service say that, besides those terms, Google also publishes a Privacy Policy, and that the Privacy Policy is not part of the terms. They send readers there to learn how to update, manage, export and delete their information (Google Terms of Service).
Sixteen clauses from a studio website, sorted
This is a fictional example. Northlight is an invented three-person web design studio. Its website has a contact form with a file upload, a newsletter, a client login and a monthly website care plan. Before a relaunch, the founder collected every legal-sounding sentence from the old site and from two competitors' sites. This is how they sorted into documents. It does not judge whether any clause is valid or enough.
| # | Clause (fictional) | Goes in | Why |
|---|---|---|---|
| 1 | Care plans renew monthly and can be cancelled before the next billing date. | Terms | Rules of the paid deal |
| 2 | You may not upload material you do not hold the rights to. | Terms | User conduct |
| 3 | The portal may be unavailable during announced maintenance windows. | Terms | What the service offers |
| 4 | We may suspend logins that are shared between people. | Terms | Conduct and consequence |
| 5 | We announce changes to these terms by email 30 days in advance. | Terms | How the deal changes |
| 6 | These terms are governed by the law of the studio's home country. | Terms | Dispute rules |
| 7 | The contact form collects your name, email address and project description. | Privacy policy | Data collected |
| 8 | We send the newsletter through an external email provider. | Privacy policy | Recipient of data |
| 9 | Analytics cookies are set only after you accept them in the banner. | Privacy policy | What is collected, and when |
| 10 | Files uploaded through the form are deleted 90 days after the project closes. | Privacy policy | Retention |
| 11 | You can request a copy of the data we hold about you at our contact address. | Privacy policy | Contact for requests |
| 12 | We update this policy when we add a tool that handles your data. | Privacy policy | How the disclosure changes |
| 13 | Deleting your account ends your care plan and removes your files within 30 days. | Split | First half terms, second half privacy |
| 14 | We keep ownership of our design templates; you receive a licence to the delivered site. | Client contract | Rules for one project |
| 15 | The launch date depends on receiving all content by the agreed date. | Client contract | Rules for one project |
| 16 | Two revision rounds are included per page. | Client contract | Rules for one project |
The count: six clauses for the terms, six for the privacy policy, one to split, and three that belong on neither page.
The three clauses that belong on neither page
Clauses 14 to 16 are the ones this sort is built to catch. They cover one project with one client: who owns the delivered work, when content is due, how many revisions are included. A website's terms speak to everyone who uses the site. The client contract, meaning the proposal or agreement a client signs for a specific project, speaks to that one client.
If project rules sit in the website terms, you end up keeping the same rule in two places. The copies drift apart. Eventually the site says two revision rounds and the signed proposal says three.
Three of sixteen is nearly one clause in five. Before you paste a clause into any legal page, ask whether a newsletter subscriber could ever be affected by it. If not, it probably belongs in the project paperwork.
The clause that splits
Clause 13 shows the pattern. An action ("deleting your account ends your care plan") is joined by "and" to what happens to data ("removes your files within 30 days"). When you see an action and a data consequence in one sentence, cut at the "and".
What changes which page
The sort tells you where a clause starts. Over a site's life, the more useful question is which page to reopen when something changes. Here are ten changes a small studio site could plausibly go through in a year. The list is fictional, and each row is assigned with the one-question test.
| Change on the site | Terms | Privacy policy |
|---|---|---|
| Add an analytics or heatmap tool | – | Reopen |
| Switch newsletter provider | – | Reopen |
| Add a file upload to the contact form | – | Reopen |
| Move hosting to a provider in another country | – | Reopen |
| Start transcribing client calls with an AI tool | – | Reopen |
| Embed a booking calendar | – | Reopen |
| Cut upload retention from 90 to 30 days | – | Reopen |
| Shorten the care-plan cancellation notice | Reopen | – |
| Launch a paid plan with a new payment provider | Reopen | Reopen |
| Open a community forum with user posts | Reopen | Reopen |
Seven changes touch only the privacy policy. One touches only the terms. Across all ten, the privacy policy gets reopened nine times and the terms three.
Your terms change when your offer changes. Your privacy policy changes when your tool stack changes, and in this list seven of the ten changes touched nothing but the tool stack.
Our own legal pages are just as lopsided in length. Counted in September 2026, our privacy policy came to a little over 800 words and our terms of service to about 220. That makes the privacy page more than three and a half times as long, because it lists what the product does with data, not what customers agree to.
October and November are a good time to go through this list for client sites. Say a client webshop is due to launch before the late-November sales weekend. The payment, shipping and tracking integrations added in the last weeks are rows in this table, and most of them point to the privacy policy. Check each one against the policy before launch day, not after.
One document or two?
Some small sites merge everything into one "Legal" page. There are three practical reasons to keep the documents apart:
- Different update rhythm. If the privacy policy gets reopened nine times for every three changes to the terms, a merged page gets new version dates for reasons unrelated to the deal. Users can't tell which part changed.
- Different questions from readers. Someone checking the cancellation period and someone checking who gets their email address want different things. On one long page, both have to scroll past the other's answer.
- Different presentation. Terms are typically presented for acceptance. A privacy policy is typically presented for reading. A checkbox saying "I agree to the terms and privacy policy" blurs that line. Ask counsel what the label should say where your users are. With two separately versioned pages, either answer is easy to build.
A simple rule: publish two pages, each with its own "last updated" date. Link both from the footer, from any sign-up or checkout step, and from every form that collects personal data. If a site has no accounts, no sales and no user posts, the terms may be short enough to share a page. Even then, give each part its own heading and its own date.
Building the legal pages for a client
A designer's part is usually collecting inputs, placing the pages and wiring the links. Drafting belongs to the client, working with counsel or with a generator they have chosen and checked.
What to collect before anyone drafts
The answers come from the client, not from another website. Five questions feed the privacy policy:
- Which tools on the site receive visitor data: analytics, forms, newsletter, chat, booking, embedded maps or videos?
- Where are the site and its form submissions hosted?
- How long are uploads and form submissions kept, and who deletes them?
- Which email address handles data requests?
- Does the client's team copy form data into other tools, such as a CRM?
Five feed the terms:
- What, if anything, is sold or offered through the site?
- Do users have accounts, and what ends an account?
- How do payment, renewal and cancellation work?
- Can users post or upload content that other people see?
- In which country is the business based?
For the privacy side in more depth, see GDPR Privacy Policy Template: The Nine Inputs to Gather First.
Put all ten questions into the project brief. Intake might run through a form, a shared document or a client portal like cluein.me. Either way, the answers then arrive with the logo files and page copy, not in a separate thread the week before launch.
Where the designer's job stops
You place the pages. You don't write them.
A privacy policy copied from another site describes someone else's tool stack. It lists tools the client doesn't use and leaves out the ones they do. Reusing the last client's policy with the name swapped fails the same way, just more quietly. If the client has no text yet, leave a clearly marked placeholder page, not borrowed wording that looks finished.
Four checks before launch, and the drift each one catches
| Check | Drift it catches |
|---|---|
| Compare the tags and scripts that load on the live site with the tools named in the privacy policy, in both directions. | A policy written before the last tool swap |
| Compare cancellation and renewal periods in the terms with the pricing page, word for word. | Terms that say 30 days while the pricing page says 14 |
| Make sure each page has its own last-updated date, and store earlier versions where the client can find them. | No record of what users saw at sign-up |
| Record who confirmed the jurisdiction-specific wording, and on which date. | Legal text nobody can vouch for |
FAQ
What is a privacy policy and terms of service?
They are two separate documents that sites often link side by side. The terms of service set the rules for using a service: what is offered, what users may do, and how payment and cancellation work. The privacy policy explains what personal data the service collects, why, who receives it and how long it is kept.
What is the difference between a privacy policy and terms and conditions?
Terms and conditions is another name for terms of service, so the difference is the same: rules of use versus disclosure of how data is handled. To sort any sentence, ask whether it covers what someone may do (terms) or what happens to someone's data (privacy policy). If it covers both, split it.
Why is everyone updating their privacy policy in 2026?
No single cause explains every update notice. A privacy policy follows a service's tool stack, so it tends to change when a provider adds a vendor, launches a feature that uses data, or starts using data for a new purpose. Some updates are also routine: a business covered by California's CCPA must update the disclosures listed in Civil Code § 1798.130(a)(5) at least once every 12 months (Cal. Civ. Code § 1798.130). The notice should say what changed. If it doesn't, compare the old and new versions by their last-updated dates.
Is it okay to agree to a privacy policy?
That is your decision, and it depends on the service. Before you click, check three things: which data is collected, who receives it, and how you can ask for a copy or deletion. If one checkbox covers both documents, read both. The terms describe the deal, and the privacy policy describes what happens to your data under it.