Cookie consent in Finland, in one paragraph
Ask before you store anything on the visitor's device, unless what you are storing is necessary to deliver the service they asked for. Necessary covers the login session and the shopping basket. It does not cover analytics, advertising or anything that follows a person between sites.
The rule lives in section 205 of the Act on Electronic Communications Services, number 917/2014, and Traficom supervises it. Anything that also involves personal data brings in the GDPR and the Data Protection Ombudsman on top.
Everything else in this article follows from that one sentence.
Two authorities, two laws
Traficom polices the storing and reading of data on a device. The Data Protection Ombudsman at tietosuoja.fi polices what you then do with the personal data. Most banners get judged on the first and most privacy policies on the second.
The split explains an odd result that confuses people. You can be storing nothing on the device and still be processing personal data, and you can be storing something harmless and still need consent to do it.
When in doubt, answer both questions separately. Is anything being stored on or read from the device, and is anything identifiable being processed afterwards.
Consent before the cookie
Before, not after the page has loaded and already set six of them. The single most common failure on Finnish business sites is a banner that asks politely while the analytics script has already run.
Traficom's guidance is that a service provider storing cookies or reading information from them has to tell the user clearly and understandably which cookies or similar technologies are in use, what types they are, what they are for and how long they last, and then ask for consent.
Test this rather than trusting the plugin. Open your own site in a fresh browser profile, look at the storage before touching the banner, and see what is already there. On the sites we review, something usually is.
Which cookies are necessary
The exemption is narrower than most banners claim. Traficom describes necessary cookies as the ones that make essential functions possible, such as logging into a protected part of the site or remembering the contents of a shopping basket.
Consent is also not needed when the only purpose is carrying out the transmission of a message over a communications network, or when storage is strictly required to provide a service the user has specifically asked for.
Everything outside that needs a yes, and analytics is outside it. A statistics cookie is useful to you rather than necessary to the visitor, and that is the distinction the law draws.
What the banner has to allow
Refusing has to be as easy as accepting, and the user must not be steered towards accepting. In practice that means a reject button with the same prominence as the accept button, on the first layer, not two clicks away behind Settings.
Beyond that: no pre-ticked boxes, separate choices per purpose rather than one bundled yes, plain language rather than legal text, and the ability to leave without choosing anything and still read the page.
The dark patterns are familiar because they are everywhere. A grey ghost reject next to a bright green accept, a Settings link where the reject should be, or a second nag on the next page. Each is a way of making no harder than yes, which is the thing the guidance forbids.
Withdrawing consent later
Changing your mind has to be as easy as giving consent was in the first place, and the method has to match how consent was asked. Traficom gives the example directly: if consent was requested through a banner, that banner should be reachable again through an icon or a link on the site, so the user can change their settings at any time.
A small link in the footer that says Cookie settings does the job, and it takes an hour to add.
Then honour it. A withdrawal that removes the banner but leaves the tracking running is worse than never offering the link.
Embedded video, maps and fonts
Third party embeds are the leak nobody plans for. A video player, a map, a font served from someone else's domain or a social feed can set storage and send the visitor's address to a third country before your banner appears.
The fix is a placeholder. Show a still image with a play button and load the real embed only after the visitor agrees, which is a standard pattern and adds a click most people never notice.
Fonts are the easy win. Copy them onto your own server and the whole question disappears, and the page usually loads faster as well.
Analytics without cookies
You can measure a website without storing anything on the visitor's device, and if nothing is stored or read, section 205 has nothing to bite on. Server side log analysis and the cookieless analytics tools work this way, counting visits from the request rather than from an identifier planted in the browser.
That settles the Traficom question. It does not automatically settle the GDPR one, because an IP address can still be personal data, so the tool has to be configured to handle that and the processing has to be documented and given a legal basis.
What you give up is cross session identity, so returning visitors and long attribution windows get fuzzier. What you get back is a number that counts everybody instead of only the people who clicked accept, which for most small businesses is the better trade.
What you actually gain by asking for less
Cleaner numbers and a faster site. A site that sets nothing until consent and measures without cookies has no banner argument, no consent rate to correct for, and fewer third party scripts slowing the first paint.
The honest counterpoint is retargeting. A shop that runs paid advertising and needs conversion tracking is going to need consent, and there the work is to make the banner good rather than to pretend the tracking is necessary.
Decide which of the two you are before the site is built. Retrofitting consent management into a site full of embeds is more expensive than planning it in on day one, and our guidance on hosting and upkeep without plugin sprawl comes from exactly this problem.
The privacy policy in practice
Write it so a customer can answer four questions from it: whose data you process, for what purposes and on what basis, whether it is transferred or disclosed to anyone else, and how long you keep it. That is what the Data Protection Ombudsman asks controllers to inform people about.
Plain language is a requirement, with particular attention to describing the purposes and the consequences of the processing in terms a reader understands. A page of copied clauses fails on that alone.
One more detail that surprises people. A mere reference to the privacy statement is not always enough. At the point where you ask for consent, the specific purposes and the recipients have to be visible there, in the form, not only behind a link.
Forms, newsletters and the legal basis
A contact form does not need consent as its basis. Someone asking you for a quote has a clear purpose of their own, and the processing to answer them stands on its own feet. A pre-ticked marketing box on that same form does need consent, and a pre-ticked one is not consent.
Keep the two separate. One field to send the enquiry, one clear and empty checkbox to join the newsletter, with what you will send and how often written beside it.
Record what people agreed to and when. The controller has to be able to show that the information was actually received and that it has not changed since, which is impossible if the only record is the form as it looks today.
Where the data lives
Know which countries your visitors' data reaches, because that is the first question in any complaint. A Finnish site can easily send data to four continents through tools nobody on your side chose deliberately.
Make a one page list: every third party script on the site, what it does, what it stores and where the company sits. Most small business sites can cut half of it in an afternoon without losing anything anybody uses.
Our own list is public on the privacy and cookies page, which is a reasonable format to copy.
The banner mistakes we see on Finnish sites
Six, in the order they turn up. Cookies set before the choice is made. Reject hidden behind Settings while Accept sits in colour. One bundled consent instead of a choice per purpose. No way to change your mind later. A banner in Finnish only on a site that sells in English. And a cookie list written when the site launched and never updated after three tools were added.
The last one is the quietest. Nothing on the page looks wrong, and the document describes a website that stopped existing two years ago.
Put the review in the same calendar slot as the domain renewal and it stays true.
A short checklist
Seven checks, and any developer can do them in a morning.
- Open the site in a clean browser profile and confirm nothing beyond the necessary is stored before a choice.
- Reject as visible and as easy as accept, on the first layer.
- A choice per purpose, nothing pre-ticked.
- A cookie settings link in the footer that reopens the banner and takes effect.
- Embeds behind a placeholder, fonts served from your own domain.
- A privacy page that answers who, why, on what basis, to whom and for how long.
- The same banner and the same text in every language the site sells in.
None of this needs a lawyer to start. It needs somebody to open the site with the storage panel visible, which is where every review we run begins, including the free review we offer on existing sites.
