There is a moment in every European analytics purchase that the marketing site never mentions. The tool is chosen, the trial went well, the team is ready, and then someone says the sentence that stops the project for three weeks: "Has this been through privacy review?"
What happens next is predictable, because Data Protection Officers ask largely the same questions of every vendor. Which means you can prepare for the review in an afternoon instead of discovering the questions one rejected email at a time. This post lays out the whole exchange: the documents a compliant analytics stack rests on, and the specific questions your DPO will ask, with what a good answer looks like for each.
One honest note before we start: we build an analytics product and we are not your lawyers. Treat this as a map of the review, not legal advice for your situation.
The three documents that carry the review#
Strip away the acronyms and a GDPR-ready analytics setup rests on three pieces of paper.
The Data Processing Agreement#
The DPA is the contract that makes the vendor your processor under GDPR Article 28. It defines what data they may process, for what purpose, under whose instructions, and what happens when you leave. No DPA, no deal. This is the first document your DPO will request, and "we can put something together" is a red flag they have seen before.
What to check inside it: the subject matter and duration of processing, the categories of data, the security measures (usually referenced as an annex), the audit rights, the deletion obligations on termination, and the subprocessor terms. A vendor that publishes its DPA openly, the way we do at our DPA page, saves you a week of email.
The subprocessor list#
Your vendor almost certainly uses other companies: hosting, email delivery, error tracking. Each one is a subprocessor, each one inherits your data protection obligations, and your DPO will want the list with locations. The thing being probed here is quiet US exposure. An "EU company" whose hosting, logging, and support tooling all sit with US providers has not moved your risk, it has hidden it one layer down.
A good vendor answer names every subprocessor, its role, its region, and commits to advance notice before adding new ones.
The transfer mechanism, or better, no transfer at all#
If any personal data leaves the EEA, GDPR Chapter V applies and someone has to name the legal mechanism: adequacy, Standard Contractual Clauses plus a transfer impact assessment, and so on. This is exactly the ground on which multiple EU data protection authorities ruled against Google Analytics, and the ground keeps shifting with every new legal challenge. The cleanest position is the boring one: the data never leaves. When processing stays inside the EEA end to end, the entire transfer chapter of the review disappears.
Data residency: what "EU-hosted" has to mean#
"EU-hosted" is doing a lot of unexamined work in analytics marketing, so here is the standard your DPO will hold it to.
It has to cover all processing, not just primary storage. Backups, replicas, log pipelines, support access paths. Data that lives in Frankfurt but gets backed up to Virginia is not EU-resident. For the record, GrainQL runs its primary infrastructure in Helsinki, Finland, with encrypted backups in Frankfurt, Germany, so both the live data and its copies stay inside the EU.
It also has to survive the corporate-structure question. A US-headquartered company operating an EU region can still face US legal process aimed at the parent, which is precisely the risk the Schrems II line of cases turned into a compliance problem. Your DPO may or may not weight this heavily, but they will ask where the operating entity is established, and the vendor should have a crisp answer.
For the wider context on why so many EU teams are re-platforming over this, our comparison of European Google Analytics alternatives covers the field.
The questions your DPO will ask, with good answers#
Here is the review, compressed. If your vendor can answer all of these in writing, the review goes fast.
"What personal data does the tool collect, exactly?" A precise inventory: which identifiers, which behavioral events, which technical attributes. "Standard analytics data" is not an answer. The strongest position is a tool built on data minimization, collecting no persistent cross-site identifiers at all. Our privacy-first analytics piece explains what that looks like in practice.
"Where is the data stored and processed, including backups?" Named regions for storage, processing, backups, and logs. See above. Anything vague here means the vendor does not know, which is worse than a bad answer.
"Does any data leave the EEA, and under what mechanism?" The best answer is no. The acceptable answer is a named mechanism with a documented transfer impact assessment. The disqualifying answer is a pause.
"What is the lawful basis, and do we need consent?" This depends on how the tool works. Cookie-based analytics needs consent under the ePrivacy rules before anything is stored on the device. Cookieless, identifier-free measurement can, in several member states and under conditions, run on legitimate interest without a consent banner. The vendor should tell you which camp they are in and why, not leave you to guess. We wrote a full explainer on how cookieless tracking works.
"How long is data retained, and can we configure it?" A number, per data type, and a deletion path. Indefinite retention of raw behavioral data fails the storage-limitation principle and your DPO knows it.
"How do you handle data subject requests?" If a user invokes access or erasure rights, the vendor needs a documented way to find and delete that person's data within the deadline. Ask how, and ask how long it takes.
"What are your security measures and breach obligations?" Encryption in transit and at rest, access controls, and a contractual commitment to notify you of a breach fast enough that you can meet your own 72-hour clock. The full technical measures usually live in the DPA annex and a security page. Ours is at grainql.com/security.
"Session replay: what about the data inside the sessions?" If the stack includes replay, expect a sharp follow-up, because replay can capture whatever users type. The answer that passes review is masking by default: form inputs and sensitive fields never leave the browser. Our session replay best practices guide covers configuring this properly.
The consent question changes the whole economics#
One of these questions deserves its own section, because it changes not just compliance but data quality. If your analytics requires consent, you only measure the visitors who click accept, and consent rates on well-behaved banners commonly leave a large fraction of traffic unmeasured. Every funnel, every conversion rate, every experiment then runs on a sample skewed toward people who accept cookies.
An identifier-free, cookieless architecture inverts this. There is nothing stored on the device to consent to, measurement covers everyone, and the consent banner conversation moves from "required" to "check with your DPO whether you need one at all." That question is big enough that we gave it its own post: analytics without a cookie banner.
Run the review before procurement does#
The fastest privacy reviews are the ones where the buyer shows up with the answers. Before you fall in love with a tool, collect five things: the DPA, the subprocessor list with regions, the residency statement including backups, the lawful-basis position, and the retention defaults. If any of the five takes more than a day to obtain, you have learned something important about the next three years of working with that vendor.
And if you want the longer, checkbox-by-checkbox version of the audit, our GDPR analytics compliance checklist walks the whole thing, including the enforcement history that got us all here.
Analytics your DPO will approve
GrainQL is cookieless and identifier-free, hosted in Helsinki with backups in Frankfurt, with a public DPA and security documentation ready for review. Start a 14-day free trial, no card required.