Privacy Policy vs. Terms of Use: the differences and a practical way to write yours

Estimated reading time: 10 minutes. This article addresses the Brazilian context.

The site looks great. Registration works. The payment button is in place. Then someone remembers those two pages that usually appear in the footer: Privacy Policy and Terms of Use.

The template hunt begins. Copy some text from here, change the company name there, ask AI to make it sound more professional, and you're done.

Are you, though?

If the document says you don't share data, but the system sends information to hosting, payment, analytics, and AI services, there's already something to discuss. If the Terms promise a feature the product doesn't deliver, there's something else.

These documents need to reflect how the service works. And although they sit next to each other in the footer, they answer different questions. Let's separate the issues and get to the practical tip: a way to start both documents without writing legal fiction.

Privacy Policy and Terms of Use: what's the difference?

The Privacy Policy explains what happens to personal data. The Terms of Use establish the conditions for using the service.

Question	Privacy Policy	Terms of Use
What is the main subject?	Processing personal data.	How the service works and the rules that apply.
What should users understand?	Which data is used, for what purposes, by whom, and for how long.	What is being offered, under what conditions, and with which responsibilities.
Examples of content	Registration, cookies, service providers, rights, and a privacy contact channel.	Accounts, plans, payment, cancellation, prohibited uses, and support.
What misunderstanding should you avoid?	Treating the notice as authorization for any use of the data.	Assuming a clause can eliminate all responsibility.

A note on terminology: on a website, what we call a Privacy Policy often serves as a privacy notice addressed to the public. That differs from an internal data protection policy, which guides the organization. The Brazilian Digital Government guide to privacy notices makes this distinction.

To keep things readable, I'll use the more familiar name here: Privacy Policy.

What needs to go into the Privacy Policy?

Start with the questions someone would ask before handing over their information:

• Who is behind the service? Identify who makes decisions about the data and how to contact them.
• What data comes in, and why? Connect data categories to their actual purposes, including information received from third parties.
• What is the basis for using it? Assess the legal basis for each purpose, rather than using one generic justification for everything.
• Who receives the data? Identify service providers, integrations, and any international transfers.
• How long is it kept? Give understandable periods or criteria that match the need and applicable obligations.
• How can people exercise their rights? Explain the channel and procedure for making a request.

Article 9 of the LGPD, Brazil's General Data Protection Law, requires transparency about matters such as purpose, duration, the controller's identity, sharing, and rights. So a friendly sentence saying the company values privacy doesn't cover everything the document needs to say.

It's also worth explaining, at a level appropriate for the audience, the security measures actually in place and how significant changes will be communicated. Avoid promising invulnerability or describing controls that don't yet exist.

On rights, Brazil's data protection regulator, the ANPD, provides specific guidance on confirmation of processing, access, correction, deletion, and other options. Conditions and exceptions apply: closing an account does not necessarily mean immediately deleting every record whose retention has a legal basis.

“I accept everything” deserves a closer look

Here's a common source of confusion: accepting the Terms of Use, acknowledging the Privacy Policy, and consenting to a particular processing activity are different things.

Consent is one of the legal bases provided by the LGPD. Depending on the purpose and circumstances, processing may rely on performance of a contract, a legal obligation, or another applicable basis. The ANPD explains these bases in its frequently asked questions.

When consent is the chosen and appropriate basis, it must meet the legal requirements, with a defined purpose and the option to withdraw it. A generic acceptance hidden inside a contract doesn't solve that: Article 8 of the LGPD requires written consent to be presented distinctly and renders blanket authorizations invalid.

In the interface, think about actions with clear meanings: agreeing to the service conditions; accessing privacy information; and, where applicable, making a separate choice about an optional purpose that relies on consent, such as receiving a particular type of promotional communication.

The goal is for people to understand what they're doing. A checked box cannot replace that understanding.

What about cookies?

They belong in the assessment too. Identify their purposes, duration, and the third parties involved. The ANPD's cookie guide recommends keeping cookies that rely on consent disabled by default and making it easy to reject nonessential cookies and review previous choices.

If the reject button is there but the tracker keeps running exactly as before, the implementation is part of the problem. The banner needs to do what it offers.

What needs to go into the Terms of Use?

Think of the Terms as an organized explanation of the relationship between the service provider and the person using it. An initial outline might include:

1. Identity and scope: who provides the service, what the product does, and its limitations.
2. Access and accounts: registration conditions, credential security, and rules for authorized users.
3. Permitted use: prohibited conduct, respect for third-party rights, and handling of user-submitted content.
4. Commercial conditions: plans, charges, renewal, cancellation, and refunds, where relevant.
5. Operation: support, maintenance, external dependencies, and communication of changes.
6. Termination and disputes: grounds and procedures for suspension, ending the relationship, and channels for resolving problems.

This outline needs adapting. A free tool, a subscription SaaS, and a platform hosting user content have meaningful differences.

For e-commerce subject to Brazil's Consumer Protection Code, or CDC, Decree No. 7,962/2013 requires clear information, a summary before the contract is concluded, access to the contract, and support for requests such as cancellation. The statutory right of withdrawal must also be respected where applicable.

And adding a clause saying the company is never responsible for anything won't fix that. The CDC, particularly Articles 46 and 51, protects consumers' ability to understand the contract and addresses the invalidity of unfair clauses.

Specific requirements also depend on the type of operation. The regulations implementing Brazil's Internet Civil Framework were updated by Decree No. 12,975/2026, which includes provisions on terms and conditions, notifications, and transparency for internet application providers. How the service falls within these rules needs to be checked; an old template doesn't automatically cover these obligations.

Two examples from my own work

Working with marketplace integrations at Oombe, I deal with something that helps explain this distinction: software also depends on other systems.

For a SaaS product of this kind, the Terms should explain the contracted features and how limitations or changes to integrations are handled. The Privacy Policy should explain the data flows involved in those operations.

These subjects are related, but serve different purposes. Explaining an external dependency also does not automatically transfer all responsibility to the API provider.

Here's another example: when I considered a résumé generator for Pinheiral Digital, the idea was to let people create and download the document without an account and without storing their résumés.

That intention needs to be confirmed by the architecture. Will the PDF be generated in the browser? Will the form fields reach the server? Will an external service receive any information? What will remain in technical logs?

Even without registration, a server may log access information. The Apache documentation, for example, shows logs that may contain the client's address, the time, and the requested resource, depending on the configuration.

For that project, the Terms could explain that users need to review their résumés and that the service doesn't guarantee employment. The Policy would explain the actual path the data takes. These are examples of content to validate, not a description of an implementation that has already been audited.

“We don't store résumés” is a specific statement. “We don't process any data” requires a much broader check.

The practical tip: create a system fact sheet before asking for the text

Open a simple document and answer the questions below. If needed, sit down with the people who develop and operate the service, support customers, and handle legal matters.

Area	What to establish
Service	What does it deliver, to whom, under which conditions, and with which limitations?
Data	What information comes in through forms, integrations, cookies, and technical logs?
Purpose	What is each use for, and which legal basis needs validation?
Path	Where does processing happen, who receives the data, and which providers are involved?
Duration	What is deleted, when and how, and what needs to be retained?
Relationship with the user	How do billing, support, cancellation, suspension, and privacy requests work?
Evidence	Who confirmed each answer, and what is still unresolved?

Don't know an answer? Write “to confirm.” That's more useful than filling the gap with a nice-sounding promise.

This approach has support in an official reference: the Brazilian Digital Government Guide to Preparing Privacy Notices, dated June 2026 recommends using the record of processing activities as a source for the notice. The guide is aimed at Brazil's federal public administration; starting with actual operations is a useful principle to adapt to other projects.

With the fact sheet completed, you already have the raw material for both documents. You may also discover that some data doesn't need to be collected at all, or that a commercial rule hasn't been decided yet.

Can you use AI? Yes. Provide context and ask for questions

AI can help organize the fact sheet and improve the writing. One practical way to start is with this prompt:

I will provide a description of a digital service operating in Brazil. Help me prepare two separate drafts: a user-facing Privacy Policy and Terms of Use.

Before drafting, ask questions to identify gaps concerning the service, audience, data, purposes, providers, retention, security, billing, cancellation, and support.

Use only confirmed facts. Mark missing information as [TO CONFIRM]. Do not invent retention periods, security controls, providers, or legal bases. Where a legal issue arises, flag what needs professional validation.

Distinguish contractual acceptance, transparency, and consent. Do not create blanket authorizations or promises of absolute security. Consider the specific issues associated with public services, children, sensitive data, or third-party content if they appear in the description.

Deliver the texts in plain language, a list of unresolved issues, and a checklist for comparing each statement with how the system actually works. Do not declare compliance with the law.

Confirmed description of the service: [INSERT THE FACT SHEET].

Use categories and fictional examples to complete this fact sheet. There's no need to paste customers' personal data, passwords, or integration tokens into the prompt.

The response will be a starting point. People familiar with the operation need to check the facts; a legal review needs to assess the applicable rules and clauses. AI cannot guess what your hosting service logs or which processes the team can actually carry out.

After writing, test what you've promised

My suggestion is to review the user's journey: create an account, read the documents on a phone, cancel a test plan, reject cookies, and submit a privacy request.

Does the contact channel work? Does the team know how to respond? Does deletion follow the procedure described? Are the conditions shown before the contract is concluded?

Keep version numbers and dates for the documents. Where acceptance is collected, retain proportionate evidence of the version presented, the time, and the action taken, without collecting excessive data. This helps demonstrate the process; it doesn't make an invalid clause valid.

Review the texts when the product, a provider, the purpose of data use, or a commercial rule changes. And check that translations still say the same thing.

The best document is one the user can understand and the operation can live up to.

Starting with that consistency takes more work than changing the company name in a template. It also helps avoid discovering later that the footer promised a service that never existed.

This article is an educational guide, not a legal opinion or a ready-made template for every business. The final documents should be adapted to the operation and applicable rules, with professional review appropriate to the circumstances.

Sources and references

• Brazil's General Data Protection Law — LGPD.
• ANPD — Frequently asked questions and Data subjects' rights.
• ANPD — Guidance on cookies and personal data protection.
• Brazilian Digital Government — Guide to Preparing Privacy Notices, version 1.0, June 2026.
• Brazil's Consumer Protection Code and Decree No. 7,962/2013 — E-commerce.
• Decree No. 12,975/2026 — Update to the regulations implementing Brazil's Internet Civil Framework.
• Apache HTTP Server — Access logging documentation.