Does Your Server-Side Session Cookie Need a PECR Consent Banner?

A common belief goes: "we keep all session state on the server, so there's no cookie to worry about." That's wrong on the facts. The browser still has to hold an ID, and that ID is stored on the user's device. Whether it needs consent is a separate question, and the answer is usually "no", but not for the reason people give.

PECR regulates the storage, not the word "cookie"

Regulation 6 of the Privacy and Electronic Communications Regulations 2003 (PECR) covers storing information, or gaining access to information already stored, in a user's terminal equipment. Cookies are the best-known case. Where the data lives on your server is irrelevant: the opaque session ID in the browser is the thing being stored.

The default rule is that the user gets clear and comprehensive information and gives consent. The text is on legislation.gov.uk. That is the legislation; what follows about how it applies is regulator guidance or my own reading.

The exemption that does the work

Regulation 6 has an exemption for storage that is strictly necessary to provide a service the user has requested. Logging in and staying logged in is the textbook case. The ICO's guidance on storage and access technologies lists authentication, shopping baskets and security among the things it treats as covered.

Two words in that test carry the weight: "strictly" and "requested". The test is about necessity for something the user asked for. It is not about whether the cookie is first-party, whether it expires when the browser closes, or whether it holds personal data.

"Session cookie" does not mean "exempt"

Lifetime is a red herring. A cookie that dies with the tab can still need consent if it serves your purposes rather than the user's request. A cookie that lasts a year can be exempt if it is genuinely needed. Ask what it is for, not how long it lives.

Here are the usual places where a session cookie stops being obviously safe:

• It is set on the first request to a page that offers no login, basket or form, so no requested service exists yet.
• The same ID is read by your analytics or ad code, so it now does a second job.
• It is made persistent for convenience, such as a "stay signed in for 30 days" that the user never chose.
• It is used to profile what anonymous visitors read.

The exemption covers the purpose. If one cookie has a necessary purpose and an unnecessary one, the unnecessary one is not excused by the other.

Set it when the user asks for something

The practical fix is small: don't create a session until there is something to attach to it. Here is a Go sketch (simplified, with the session store and authentication left out):

func login(w http.ResponseWriter, r *http.Request) {
	user, err := authenticate(r)
	if err != nil {
		http.Error(w, "forbidden", http.StatusForbidden)
		return
	}
	id, err := sessions.Create(user)
	if err != nil {
		http.Error(w, "internal error", http.StatusInternalServerError)
		return
	}
	http.SetCookie(w, &http.Cookie{
		Name:     "sid",
		Value:    id,
		Path:     "/",
		HttpOnly: true,
		Secure:   true,
		SameSite: http.SameSiteLaxMode,
		// No Expires or MaxAge: a browser-session cookie.
	})
	http.Redirect(w, r, "/account", http.StatusSeeOther)
}

The cookie appears only after a successful login, which is the user asking for the service. Nothing sets it for a casual visitor reading a public page. That one decision removes the commonest awkward case.

Quick detour: the login form's own cookie

Hang on, what about the CSRF token cookie on the login form itself, before anyone has authenticated? That one is more interesting. The user has asked to log in, and the token is there to protect that very request, so the ICO's security reasoning points towards exempt. It is a judgement about purpose, though, so keep it to the form and don't reuse it elsewhere.

Remember-me and preferences

A persistent login is fine when the user ticks a box asking for it, because then it is the requested service. Defaulting it on, with the box pre-ticked, is harder to defend. Language and display choices the user made themselves have long been treated as exempt in ICO guidance. The Data (Use and Access) Act 2025 also added further exceptions to regulation 6; check the current text of the regulation for their exact scope, as I haven't reproduced it here.

Does exempt mean silent?

An exempt cookie needs neither consent nor the regulation 6 information duty. That is a PECR point only. If the session is tied to an identifiable person, UK GDPR still applies to that processing, so your privacy notice should mention the cookie anyway. It costs one sentence and avoids a mismatch between what you say and what you do.

A quick audit

1. Open the browser dev tools on a fresh visit and list every cookie set before any login or form.
2. For each one, write down what the user asked for that requires it.
3. If you can't, either remove it or put it behind consent.
4. Check that nothing else (analytics, A/B tests, ad scripts) reads the session ID.

Whether a given cookie is strictly necessary depends on what your service actually does, so this is general information, not advice for your site. The reliable approach is boring: one cookie, one purpose, set when the user asks for something.