You do not need a privacy checkbox. Here is what you actually need.

TL;DR. The Terms of Service are a contract. The user has to agree to them, and clicking a clearly labelled button is enough. The Privacy Policy is a notice. The law says show it, not get it accepted. Putting both behind one checkbox does not make you safer. Under GDPR it is the one construction the regulators explicitly call out: consent bundled with terms and conditions is presumed not freely given. Swiss law does not ask for consent to ordinary account data at all. Put a one-line notice next to the submit button, record who agreed to which version and when, and save the unchecked checkboxes for the things that really need them: marketing email, non-essential cookies, sensitive data.

The checkbox everyone adds

Open ten B2B SaaS signup forms and you will find this on most of them, just above the button:

[ ] I accept the Terms and Conditions and the Privacy Policy

Unchecked, required, and often wired so the button stays grey until you tick it. Ask the team why it is there and you get some version of “GDPR”. Nobody remembers the article. The checkbox came from a template, a competitor, or a lawyer who was asked a different question. It carries three assumptions, and all three are wrong:

1. that the law requires users to accept the privacy policy,
2. that a checkbox is stronger proof than a button,
3. that one checkbox for both documents is efficient.

Two different laws in one checkbox

The Terms of Service and the Privacy Policy look alike: two long pages, two links in the footer. Legally they are different animals.

The Terms of Service are a contract. That is civil law: offer, acceptance, a record of who accepted what. For a contract to exist the user has to do something that signals agreement. A tick in a box is such an act. So is a click on a button that says what the click means. Nothing in GDPR governs this part. GDPR only cares that the data you process for the contract has a legal basis, and it hands you one directly:

“processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract”

(Article 6(1)(b) GDPR)

The email address, the password hash, the company name: you need them to deliver the service the user just asked for. Contract is the basis. Consent, Article 6(1)(a), is a different basis, and you do not need it for this data.

The Privacy Policy is a notice. Article 13 GDPR is titled “Information to be provided where personal data are collected from the data subject”. Its first sentence tells you what the duty is:

“Where personal data relating to a data subject are collected from the data subject, the controller shall, at the time when personal data are obtained, provide the data subject with all of the following information:”

(Article 13(1) GDPR)

Provide. Not obtain agreement to. The list that follows (who you are, the purposes, the legal basis, the recipients, transfers abroad) is what the privacy policy contains. Your obligation is to put it in front of the user at the moment you collect the data. A link next to the signup button does that. A checkbox does not do it any better, and it quietly changes the story you are telling: “I accept the Privacy Policy” reads as consent to the processing described in it. You did not need consent, and now you have a record that looks like you asked for it.

That matters because consent has strings attached that contract does not. Article 7(3) gives the user the right to withdraw consent “at any time”, and says that “It shall be as easy to withdraw as to give consent.” If your privacy policy says the basis for account data is consent, a withdrawal request means you have to stop, which for an account means deleting it. If it says contract, the account simply continues until the contract ends. The checkbox pushed you onto the weaker basis for no gain.

Why bundling is the one thing GDPR calls out

Suppose you do want consent for something at signup. The bundled checkbox is still the wrong tool, and this time the regulation says so directly. Consent is defined as:

“any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her”

(Article 4(11) GDPR)

“Freely given” is where a bundled checkbox breaks. Two provisions spell it out. The first is about presentation:

“If the data subject’s consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language.”

(Article 7(2) GDPR)

The second is about conditionality:

“When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.”

(Article 7(4) GDPR)

Recital 43 turns that into a presumption: consent “is presumed not to be freely given if it does not allow separate consent to be given to different personal data processing operations despite it being appropriate in the individual case, or if the performance of a contract, including the provision of a service, is dependent on the consent despite such consent not being necessary for such performance.” A required checkbox that says “I accept the Terms and the Privacy Policy” makes the account conditional on the tick. That is the situation the recital describes.

The European Data Protection Board’s Guidelines 05/2020 on consent (version 1.1, adopted 4 May 2020) leave no room for interpretation. Paragraph 26:

“Article 7(4) GDPR indicates that, inter alia, the situation of ‘bundling’ consent with acceptance of terms or conditions, or ‘tying’ the provision of a contract or a service to a request for consent to process personal data that are not necessary for the performance of that contract or service, is considered highly undesirable. If consent is given in this situation, it is presumed to be not freely given (recital 43).”

Paragraph 71 covers the electronic form: “if consent is requested by electronic means, the consent request has to be separate and distinct, it cannot simply be a paragraph within terms and conditions”. And paragraph 81 is the sentence to pin above the designer’s desk:

“A controller must also beware that consent cannot be obtained through the same motion as agreeing to a contract or accepting general terms and conditions of a service. Blanket acceptance of general terms and conditions cannot be seen as a clear affirmative action to consent to the use of personal data.”

So the bundled checkbox fails both ways. If you needed consent, the tick is not valid consent. If you did not need consent, the tick is a contract acceptance wearing a privacy costume. Either way, a single click on a well-labelled button would have done the job.

Switzerland in one paragraph

The revised Federal Act on Data Protection (FADP, SR 235.1, in force since 1 September 2023) is built differently from GDPR and lands in the same place. It has no list of legal bases. Article 30(1) says anyone processing personal data “must not unlawfully breach the data subjects’ personality rights”, and Article 31(1) says such a breach “is unlawful unless it is justified by the consent of the data subject, by an overriding private or public interest, or by the law”. Processing ordinary account data in line with the principles is not a breach in the first place, so no justification, and no consent, is needed. Explicit consent is reserved by Article 6(7) for “processing sensitive personal data”, “high-risk profiling by a private person” and “profiling by a federal body”. What the law does demand at signup is information. Article 19(1): “The controller shall inform the data subject in an appropriate manner when collecting personal data”. Article 19(2) sets the minimum: “the controller’s identity and contact details”, “the purpose of processing” and, if applicable, “the recipients or the categories of recipients”. A linked privacy policy next to the button satisfies it. A checkbox is not mentioned anywhere.

Three patterns, side by side

1. Inline notice at the submit button (recommended)

No checkbox. The button carries the contract, and the sentence under it names both documents with the right verb for each:

<button type="submit">Create account</button>

<p class="notice">
  By clicking “Create account” you agree to our
  <a href="/terms">Terms of Service</a>
  and acknowledge our
  <a href="/privacy">Privacy Policy</a>.
</p>

Three details carry the weight. The notice names the button, so the click is unambiguous. “Agree to” goes with the Terms, because that is the contract. “Acknowledge” goes with the Privacy Policy, because a notice can be received but not accepted. Keep the sentence visible without scrolling and keep it next to the button, not in the footer. Article 13 says “at the time when personal data are obtained”, and a footer link three screens down is a weak way to prove you met that.

2. Terms checkbox, privacy as a link (also fine)

If you want a distinct tick on record for the contract, give the Terms their own box and leave the Privacy Policy as a sentence beside it:

<label>
  <input type="checkbox" name="terms" required>
  I agree to the <a href="/terms">Terms of Service</a>
</label>

<p class="notice">
  See our <a href="/privacy">Privacy Policy</a> for how we process your data.
</p>

<button type="submit">Create account</button>

Nothing is bundled, the privacy policy is not dressed up as consent, and the record you keep is the same as in pattern 1. The cost is one more required field and one more way to fail the form. Validate on submit and show the error at the box, do not grey out the button.

3. Bundled checkbox (the anti-pattern)

<label>
  <input type="checkbox" name="legal" required>
  I accept the <a href="/terms">Terms and Conditions</a>
  and the <a href="/privacy">Privacy Policy</a>
</label>

Three things are wrong with it, in order of how much they will cost you. It uses the same verb for a contract and a notice, so the user is told they are consenting to processing you never needed consent for. It ties that apparent consent to the account, which is the exact shape Article 7(4) and Recital 43 presume invalid. And it puts the request inside the Terms acceptance, which paragraph 81 of the EDPB guidelines says cannot count as a clear affirmative action. If a supervisory authority ever asks what your legal basis for account data is, this checkbox answers “consent” on your behalf.

What you must record server-side

Whichever of the two good patterns you pick, the UI is only half of it. The evidence lives in your database. Article 7(1) puts the burden on you to “demonstrate” consent where you rely on it, and contract law puts the same burden on you for the Terms. A screenshot of the form is not a record. Write a row at the moment of the click:

Make the table append-only and make one user plus one pair of versions equal one row. Repeat logins with the same versions are a no-op. A version bump means the next click writes a fresh row, which is your re-acknowledgement mechanism without any extra UI. In code the whole thing is a single upsert:

await db.from('legal_acknowledgements').upsert(
  {
    user_id: userId,
    tos_version: TOS_VERSION,        // '2026-04-18'
    privacy_version: PRIVACY_VERSION, // '2026-04-18'
    source: 'signup',
  },
  { onConflict: 'user_id,tos_version,privacy_version', ignoreDuplicates: true },
)

The version constants live in one file that both the form and the server import, so the UI can never show a version the record does not name. Cover every entry path, not only the email form. A user who arrives through “Continue with Google” never sees a checkbox, but they do see the notice and click the button, and the OAuth callback is where you write their row.

When a real unchecked checkbox is required

None of this means checkboxes are bad. It means they are for consent, and consent is for the things the contract does not cover. Each of these gets its own box, unchecked by default (Recital 32: “Silence, pre-ticked boxes or inactivity should not therefore constitute consent”), and never merged with the Terms:

• Marketing email. Article 13(1) of the ePrivacy Directive (2002/58/EC) requires prior consent before you send direct marketing by email. The exception in Article 13(2) for existing customers and your own similar products is narrow and requires a free, easy way to object both at collection and “on the occasion of each message”. “Also send me occasional product tips” is a separate box, and the account works without it.
• Non-essential cookies and other storage on the device. Article 5(3) of the same directive requires consent for storing or accessing information on the user’s device unless it is strictly necessary for a service the user asked for. That is the cookie banner’s legal home. The session cookie your signup sets is necessary and needs no consent. The technical side of that cookie, the flags that keep it safe, is a different topic: see the Academy article on cookie flags.
• Sensitive data. Special categories under Article 9 GDPR (health, religion, biometrics and the rest) need explicit consent under Article 9(2)(a) unless another exception applies. Switzerland says the same in Article 6(7)(a) FADP. If your signup form asks for any of it, that field gets its own explicit opt-in.

Notice the pattern: every real checkbox governs something optional. The moment a box is required for the account to exist, it is not consent any more, and it should not be phrased as consent.

The claims you will hear, checked

Live example. Sudory’s own sign-in and signup form uses pattern 1: one sentence under the button, “agree to” for the Terms, “acknowledge” for the Privacy Policy, and one row per user and version pair written on the server when the email link is confirmed. The scan-claim form adds a separate, unchecked marketing box, which is the only consent we actually ask for. For how GDPR shapes the rest of the vendor relationship, from Article 28 processor duties to sub-processor chains, see the GDPR framework page.

FAQ

Does GDPR require users to accept the privacy policy at signup?

No. Article 13 GDPR is a duty to provide information "at the time when personal data are obtained". You have to show the privacy policy, or a link to it, at the moment of collection. Nothing in Article 13 asks the user to accept anything. The legal basis for account data is the contract (Article 6(1)(b)), not consent.

Is a bundled "I accept the Terms and the Privacy Policy" checkbox illegal?

It is not a fine on its own, but it is a defect. If you rely on that tick as consent for anything, Article 7(2) requires the consent request to be "clearly distinguishable from the other matters", and Article 7(4) with Recital 43 presume consent bundled into contract acceptance is not freely given. The EDPB puts it plainly: "consent cannot be obtained through the same motion as agreeing to a contract or accepting general terms and conditions of a service". If you do not rely on it as consent, the tick adds nothing a click on the submit button did not already give you.

Do I need a checkbox for the Terms of Service?

You need an affirmative act that forms the contract. A checkbox is one such act. A button that says "Create account" under a notice that reads "By clicking Create account you agree to our Terms of Service" is another. Both are contract law, not data protection law. Pick the one that gives you a clean record and the shorter form.

What does Swiss law say about consent at signup?

The revised Federal Act on Data Protection (FADP, SR 235.1, in force since 1 September 2023) does not require consent to process ordinary personal data. Article 31(1) lists consent as one of three grounds that justify a breach of personality rights, next to an overriding interest and the law. Explicit consent is reserved by Article 6(7) for sensitive personal data, high-risk profiling by a private person, and profiling by a federal body. What Article 19 requires at collection is information: who you are, the purpose, and the recipients.

What should I record server-side when someone signs up?

The user ID, a timestamp, the version of the Terms of Service in force, the version of the Privacy Policy in force, and which form produced the record. Store it in a table you never edit, keyed so that one user and one pair of versions gives one row. When either document changes, bump its version and let the next login write a fresh row.

When is a separate unchecked checkbox actually required?

For marketing email, which needs prior consent under the ePrivacy Directive unless the narrow existing-customer exception applies. For non-essential cookies and similar storage on the device, which need consent under Article 5(3) of the same directive. For special categories of data under Article 9 GDPR, or sensitive personal data under Article 6(7) FADP, which need explicit consent. Each of those gets its own unchecked box, never bundled with the Terms.