"By using the Service, You agree" in a privacy policy is not consent under GDPR

A SaaS company wants to email a launch announcement to everyone who signed up this year. Nobody ticked a newsletter box, but the privacy policy says "By using the Service, You agree to the collection and use of information in accordance with this Privacy Policy", and its legal-basis section lists consent for marketing. Under GDPR that sentence gets the company no consent at all, because using a service is not consent. And because the policy named consent as the basis, the EDPB, the body of all EU data protection authorities, says the company cannot swap to its legitimate interest once that consent turns out to be invalid. Nobody was offered a way to opt out at sign-up either, so the EU's exception for emailing existing customers does not apply. The email would go out with no legal basis, and the first complaint would ask for consent records that do not exist.

If a generator wrote your privacy policy, the sentence is probably in it. It is the third sentence of the template TermsFeed's free Privacy Policy Generator produces, and a search of public code on GitHub finds it, word for word, in about 9,000 files. Germany's data protection authorities restated the rule in an updated paper on consent dated 23 September 2026: silence, pre-ticked boxes, inactivity and simply carrying on using a service are not consent 1.

Why is using a service not consent under GDPR?

GDPR never asks users to agree to a privacy policy. Article 13 lists what a company must tell people when it collects their data, including the legal basis for each purpose 2, and telling them is the whole duty. The risk is that people inside the company treat the sentence as consent anyway, as in the launch email above, or write consent into the legal-basis section for purposes the product never asks about. That second case is what I look for first when I read a generated policy, because nobody notices it until someone asks to see the consent.

The rule itself is short. Consent has to be an active step the person takes for a stated purpose. Recital 32 of GDPR says silence, pre-ticked boxes and inactivity are not consent 2, the EU Court of Justice applied that to a pre-ticked cookie box in its 2019 Planet49 judgment, and the EDPB says scrolling or swiping through a page will "not under any circumstances" count 3. The German paper, from the Datenschutzkonferenz (DSK), the joint body of Germany's data protection authorities, adds "simple continued use of a service, such as scrolling further down a web page" (my translation) 1. It is guidance that builds on the EDPB's guidelines, so little in it is specific to Germany.

The template also leans on the sentence for data sent abroad. Further down, a live copy of the template says "Your consent to this Privacy Policy followed by Your submission of such information represents Your agreement to that transfer." Consent only works for a transfer the person was specifically told about and explicitly agreed to, including its risks (Article 49(1)(a) 2), and the EDPB says this exception must not become the rule and that companies should favour the standard transfer tools 4. Read that way, I would not rely on it for a vendor you send data to every day. For US vendors that job belongs to the vendor's Standard Contractual Clauses (SCCs) or its self-certification under the EU-US Data Privacy Framework (DPF), which I covered vendor by vendor in the post on data transfers outside the EU. A policy that names consent here names the wrong tool.

Which parts of a SaaS product need consent?

Fewer than most generated policies suggest. Most of what a SaaS product does rests on the contract with the user (Article 6(1)(b)) or on the company's legitimate interest (Article 6(1)(f)) 2, and the EDPB says that when processing is necessary to perform the contract, consent is not the appropriate basis 3. This is how I would split a typical SaaS product, for a policy you are writing or rewriting:

If your current policy names consent for marketing, the legitimate-interest rows apply only to addresses collected after the policy names that basis and the sign-up form offers the opt-out. The EDPB wants the basis decided before collection 3, and the opt-out has to be offered when the address is collected 5. The users you already have need to be asked for consent.

Marketing email. GDPR's Recital 47 says direct marketing may be a legitimate interest 2. Email marketing also has to pass the ePrivacy Directive, the EU law on electronic marketing and cookies. Its "soft opt-in" lets a company email customers about its own similar products when it got their address "in the context of the sale of a product or a service". The customers must also have been given a clear, free way to object when the address was collected, and again in every message 5. For any other individual, sole traders included, the directive requires consent. It does not say whether a free-plan sign-up counts as a sale, so I would ask free users for consent. For business subscribers it leaves the rule to each EU country (Article 13(5) 5), and it does not say whether a person who signs up with a work address counts as one. That is the "Email to business contacts" row: for B2B sign-ups and B2B prospecting alike, check the rule in the country you are emailing.

Cookies. Article 5(3) of the ePrivacy Directive requires consent before storing or reading information on a visitor's device, unless that is strictly necessary for a service the visitor asked for 5. Advertising cookies never fit that exception. Whether an analytics setup fits it depends on what it stores (more in the post on analytics consent).

Where a purpose does need consent, ask for it on its own. One checkbox reading "I agree to the Terms of Service and Privacy Policy" cannot carry marketing consent, because Article 7(2) requires a consent request to be clearly distinguishable from other matters 2. A second, unticked box that says what the emails will be can. Sign-up has to work when the box is left empty: when a service is made conditional on consent to processing the service does not need, that consent is presumed not freely given (Article 7(4) and Recital 43 2).

What does a consent record have to hold?

Article 7(1) says that where processing is based on consent, the company must be able to demonstrate that the person consented 2. The DSK paper spells out what that means: the consent of each individual person documented in full, with the exact wording for a consent given in words. Storing an IP address and asserting that consent came from it is not proof 1. Neither, the EDPB adds, is a claim that the form was set up correctly. It suggests keeping information on the session in which consent was given, documentation of the consent flow at the time, and a copy of what the person was shown 3.

If I were building this, I would keep one row per consent, per purpose:

• Who: the user ID or email address.
• What for: one purpose per row, such as "product newsletter".
• What they saw: the exact wording, stored as a version you can retrieve later, because the wording on the form will change.
• When and where: the timestamp and the form or page it came from.
• Withdrawal: when they withdrew, if they did.

What happens without the record is easy to find in enforcement. France's data protection authority, the CNIL, fined Solocal Marketing Services 900,000 euros in May 2025 for email and SMS marketing without valid consent. For the contacts from one of its main data suppliers, the company could not prove consent at all, and the CNIL wrote that the burden of proof was on the company as controller 6. Solocal bought its lists, but the rule is the same for a sign-up form you built yourself.

Can you switch to legitimate interest if the consent is invalid?

Not according to the EDPB. If your policy named consent for a purpose and the only consent behind it is the "By using the Service" sentence, that processing has no legal basis, and its guidelines say you cannot repair it by pointing to legitimate interest: "it is not allowed to retrospectively utilise the legitimate interest basis in order to justify processing, where problems have been encountered with the validity of consent" 3. The same paragraph says a company "cannot swap from consent to other lawful bases" and has to decide the basis before it collects the data. The German paper is softer in tone: switching after the fact "can raise problems" of fairness and transparency, and switching at will is not possible 1. I know of no court ruling that settles it, so I would build on the EDPB's version.

The DSK paper points to fines under Article 83(5)(a) of GDPR for processing on an invalid consent 1. That is the upper of GDPR's two fine levels: up to 20 million euros or 4% of worldwide annual turnover, whichever is higher 2.

The route that works is to ask. For the launch email in the opening, that means showing users a separate opt-in in the product, recording who ticks it, and sending the announcement to them.

What should you change in your privacy policy and sign-up flow?

If you run a product with users in the EU and your privacy policy came from a generator, these are the changes I would make. Without them, any purpose your policy puts on consent has no valid consent behind it, and no record to show a regulator who asks.

1. Delete the "By using the Service, You agree" sentence. Search the policy for "by using", "you agree" and "you consent", and replace each with a plain statement such as "This policy explains what personal data we collect, why, and on what legal basis."
2. Keep consent only where the product asks for it. In the legal-basis section, consent belongs next to purposes that have an opt-in in the product, such as marketing to individuals who are not paying customers and non-essential cookies. Give every other purpose its real basis.
3. Name the transfer tool for each vendor. Replace the "your consent represents your agreement to that transfer" sentence with the SCCs or DPF certification each vendor outside the EU relies on.
4. Give each consent its own opt-in. An unticked box is the simplest, separate from accepting the Terms, with sign-up still working when it is left empty, and a way to withdraw as easy as the way in, such as an unsubscribe link or a settings toggle.
5. Store the record. One row per person and purpose, with the wording version they saw.

A legal-basis section is accurate on the day it is written and goes out of date the week someone adds a newsletter form or a new analytics script. Lawcel is a compliance tool we build that connects to your code repository: it reads each pull request and flags the changes that mean the privacy policy has to change too, while the change is still in review.