Cookie Consent Security and Data Storage

The tool that solves your privacy problem is also a privacy decision

A consent management platform is an unusual purchase. You are adding a third party's script to every page of your site, showing it every visitor you have, and asking it to keep a record of what each of them chose. You are solving a data protection problem by handing a new supplier some data. That is a reasonable trade, but only if you can say what the supplier holds.

In the language the regulation uses, you are the controller and your consent platform is a processor acting on your instructions. The obligation to explain the arrangement stays with you.

The question you will be asked

"Who else sees our visitors?"

It arrives from a client, a procurement team, a new data protection officer or a security questionnaire attached to a contract you want to sign. The answer has to be specific, and "it is a cookie banner, it does not really collect anything" is not specific.

The paperwork that needs it

Your record of processing

A record of processing activities asks what categories of data you hold, why, where they sit and how long you keep them. Your consent log is one of those entries. So is the list of processors you use, which is where your consent platform appears by name.

The irony worth avoiding

A privacy log that is a privacy risk

A consent log built without thought becomes a table of IP addresses, browser fingerprints and page histories: a fresh pile of personal data whose only job was to prove you were careful with personal data. That is the failure this page is written against.

Kukie provides the technical infrastructure for consent management. Whether your site is compliant depends on how you configure it and may require additional legal measures specific to your organisation. What this page can do is tell you exactly what the platform holds, so that the parts you are responsible for are the only parts left to work out.

What is actually in a consent record?

This is the whole of it. When a visitor answers your banner, one row is written, and the table below is every field in that row. Nothing else about that person is stored anywhere in Kukie.

Every field stored in a Kukie consent record, what it contains and why it is kept
What is recorded	What it actually contains	Why it is kept
The choice	Whether the visitor accepted, refused or made a custom selection, and which categories they allowed	It is the thing the whole log exists to evidence
A receipt identifier	A unique reference generated for that single record	Lets one specific decision be looked up and verified afterwards
Date and time	The moment the banner was answered	Shows the agreement was in place before the cookies were set, not after
A visitor identifier	A random value the visitor's own browser generates and stores in your site's browser storage	Connects a later change of mind to the original decision
Country	A two-letter country code, and nothing narrower	Shows which of your region rules applied to that visitor
IP address, hashed	A one-way keyed hash. The address itself is never written to the record	Separates one visitor from another without holding an identifier
User agent, hashed	The browser identification string, given exactly the same treatment as the IP address	Same reason, and it keeps a fingerprinting surface out of the database
Page address	The URL of the page the banner was answered on	Shows where on your site the choice was made
Banner version	A number identifying the wording and configuration in force at the time	Shows what the visitor was actually shown when they agreed to it

Deliberately not in the record

The raw IP address, in any column, at any point after the request has been handled
The raw browser user agent string
Any name, email address, account detail or form entry belonging to your visitor
Anything the visitor did after answering the banner. Kukie is not an analytics product, and the record stops at the moment of the choice

One row, one visitor, one site

The visitor identifier is not issued by us. It is a random value minted by the visitor's own browser and kept in the browser storage belonging to your website, which means it has no meaning anywhere else and does not follow a person from your site to anyone else's.

That is why the consent log answers "did this visitor agree, and to what" and cannot answer "where else has this person been". The second question is one a consent platform has no business being able to answer.

What you can do with the record once it exists, including looking one up by its receipt identifier and exporting the log, is covered on consent analytics and records.

Why an IP address is hashed and never stored

This is the single most consequential decision in how Kukie handles your visitors, so it is worth understanding rather than taking on trust. It is also the one people push back on, because storing the address would occasionally be convenient.

A hash is a one-way calculation. Feed it a value and it produces a fixed-length string. Feed it the same value tomorrow and you get the same string again, which is what makes it useful. What you cannot do is run the calculation backwards and recover the original from the result.

Applied naively to an IP address, that guarantee is weaker than it sounds. There are only about four billion possible IPv4 addresses, and a computer can hash every one of them and build a lookup table. Kukie therefore mixes a secret key held on its own servers into the calculation. Without that key, working through every address gets you nowhere, so the stored value stays a stored value rather than an address in disguise.

The user agent, the string your browser sends describing itself, is given the same treatment for the same reason. In full it is one of the more useful ingredients in browser fingerprinting, and there is no version of a consent log that needs it in full.

What the trade-off costs

You can never search the log by IP address

If somebody hands you an address and asks which consents came from it, there is no query that answers. Nobody at Kukie can answer it either, which is deliberate rather than an omission. The same applies to the browser string: you cannot break your consent rates down by browser version, because that data is not there to break down.

Those are real capabilities, and giving them up is the price. It is worth naming the price rather than pretending the choice was free.

What the trade-off keeps

Everything the log is actually for

Because the same input always produces the same output, two records from the same visitor still match each other, duplicates still collapse, and a decision can still be shown to have existed at a specific moment under a specific banner version. That is the entire job of a consent log.

What is gone is only the part that identified a person. An IP address is personal data on its own, so storing one would make every consent record an identifiable record about an individual, and a database of those is a liability that grows quietly with your traffic. Keeping less is the only reliable way to lose less.

One caveat worth stating plainly, because some vendors are vague about it: hashing makes the record pseudonymous, not anonymous. Pseudonymised data is generally still treated as personal data by European supervisory authorities, so your consent log still belongs in your record of processing activities. Hashing lowers the risk it carries. It does not take it out of scope.

Where does consent data live, and how long does it stay?

Two questions that arrive together on every vendor review form, and the two that decide how much of your own paperwork the answer covers.

Data residency

Consent records are stored in the European Union

The servers holding your consent log are in the EU. That is the plain answer to "where is our consent data", and it is the answer that saves the most work downstream, because personal data leaving the European Economic Area brings a set of transfer obligations with it that you would otherwise have to document and justify.

The region a visitor is in is resolved on those same servers rather than by calling out to a geolocation service, which is why the country code in the table above does not involve a third party. How that lookup feeds your banner rules is on the geo-targeting page.

Kukie is an EU-based platform, and the current list of sub-processors around it, including payment and network providers, is published in our privacy policy and kept current as it changes.

Retention

Records are deleted when their time is up

You set how long consent records are kept, within a maximum that depends on your plan. Once a record passes that window it is deleted by a scheduled job that runs on its own, so retention is something the platform enforces rather than something you have to remember to do every quarter.

Storage limits are usually read as a plan restriction. Read the other way round, a retention period is a data protection control: the principle that you do not keep personal data longer than the purpose requires is one of the few parts of the regulation with no ambiguity in it. A log that deletes itself is one fewer thing to be found holding.

Which retention limit comes with which plan is set out on the pricing page. Pick the shortest one that still covers the period you might need to evidence.

What protects the account the records sit in

Careful handling of the data is undone by a careless account around it. These four are the parts of the platform that exist for that reason rather than for anything a visitor will ever notice.

Two-factor authentication on your login

Available on every account, using an authenticator app, with recovery codes issued at setup so a lost phone does not become a lost account. It is worth switching on: the login is the one place where a single reused password would put every consent record you hold behind one guess.

A three-tier audit log

Events are recorded in three separate streams. Administrative changes, ordinary account activity and security events such as sign-ins are each kept apart, and each carries its own retention period, so the trail that answers "who changed this, and when" is not thrown away on the same schedule as routine noise.

A rate-limited public API

The endpoint that receives consent has to be open, because it is called by a browser on your website rather than by a server holding a secret. Rate limiting is what keeps an open endpoint from being flooded with invented records, which would corrupt exactly the evidence you were keeping it for.

Sanitisation of anything you paste in

Script snippets, custom HTML and custom CSS are cleaned before they are stored and again before they are served. Whatever goes into those boxes ends up running on every page of your site, so a snippet from a vendor, an agency or a five-year-old support article is checked rather than trusted. The same applies to tags managed through script blocking.

Why there is no row of certification badges here

You have seen the strip: a line of logos, a shield, a percentage. It is the conventional way to end a security page, and we have left it out, because we would have to put something there that we cannot stand behind.

What we can show you is the design, and the design is the whole of this page. The table earlier is every column in a consent record, not a selection from it. The hash uses a secret key, and we explained why a hash without one would not be worth much. The records sit in the EU. Retention is enforced by a job rather than by good intentions. Those are things you can hold us to, and things you can put in your own documentation.

If your procurement process needs a specific document before you can sign anything, ask us at the start rather than after you have migrated. A straight answer about what exists is more useful to you than a badge, and it is quicker to get.

Ask before you commit →

Who ends up needing these answers

Most site owners never think about where their consent log lives, and for a small site that is a defensible position. These are the situations where somebody eventually asks, and where not having an answer costs you something concrete.

Agencies and freelancers

It is not your data to be casual with

Choosing a consent tool for a client means choosing a sub-processor on their behalf, and they may have to name it. Being able to hand over one page instead of writing an email per client is the practical version of that. Managing the sites themselves is on the agencies and teams page.

Anyone selling to larger organisations

The questionnaire arrives eventually

Vendor security reviews ask about every third party with access to customer data, and a consent banner qualifies. "Stored in the EU, IP addresses hashed, retention enforced" answers three questions on that form in one sentence.

Sensitive sectors

Where the visitor list is itself revealing

On a health site, a legal advice site, a charity or a public body, the fact that somebody visited at all can be the sensitive part. Not holding an address or a browser fingerprint against each visit matters more here than anywhere else.

Anyone writing the paperwork

You cannot document what you cannot see

A record of processing activities needs categories of data, purposes, locations and retention periods, filled in per processor. The table earlier on this page is the consent log entry, more or less ready to copy across.

Hashing, EU storage, audit logging, two-factor authentication and input sanitisation are how the platform is built, so they apply on every plan including the free one. What changes with the plan is how long consent records are kept, which is on the pricing page.

Consent data questions

What people ask before they trust a third party with a record of their visitors' choices.

Where is cookie consent data stored?

Consent records collected through Kukie are stored on servers in the European Union. That matters because moving personal data outside the European Economic Area brings a set of transfer obligations with it, and keeping the consent log in the EU avoids that question for the log itself. The current list of sub-processors that sit around the platform is published in our privacy policy and is kept up to date as it changes.

Is cookie consent data personal data?

Treat it as though it is. A consent record holds no name and no email address, and the IP address and user agent are hashed rather than stored, but it is still tied to a pseudonymous identifier for a particular visitor. Pseudonymised is not the same as anonymous, and European supervisory authorities have generally treated pseudonymised records as personal data. The practical consequence is that your consent log belongs in your record of processing activities like any other set of personal data.

Why does Kukie hash IP addresses instead of storing them?

Because the log exists to evidence that a choice was made and respected, not to identify the person who made it. An IP address is personal data in its own right, so keeping one would turn every consent record into an identifiable record about an individual. Hashing preserves what the log is actually for, which is telling one visitor apart from another and showing that a decision existed at a point in time, while removing the part you would rather not be holding at all.

Can a hashed IP address be turned back into an IP address?

Not from the stored value on its own. A plain hash of an IP address would be weak, because there are only about four billion possible IPv4 addresses and a computer can work through all of them. Kukie therefore mixes in a secret key held on its own servers, so the stored value cannot be matched back to an address by someone simply trying every possibility. The result is still stable, which is why the same visitor keeps producing the same value.

How long is cookie consent data kept?

You choose, within a maximum that depends on your plan. A scheduled job deletes consent records once they pass the retention window set for your organisation, so deletion is enforced by the platform rather than left as something you have to remember to do. Audit log retention is configured separately, with its own period for administrative, activity and security events. The pricing page shows which retention limit each plan carries.

Is Kukie a data controller or a data processor?

For the consent data collected from your website visitors, Kukie acts as a processor and you are the controller. You decide what to ask your visitors, which categories exist on your site and how long the answers are kept. Kukie stores and processes that data on your instructions. The distinction matters when you write your privacy policy and your record of processing activities, because it determines which obligations fall on you and which fall on us.

Cookie consent data security:
what we hold, and where

The tool that solves your privacy problem is also a privacy decision