Running a survey that collects personal data from people in the EU or UK brings GDPR into scope from the first question. Getting the basics right at the design stage is far easier than retrofitting compliance after responses start arriving. This guide covers the concepts that matter most for anyone designing a survey: who is responsible for what, how to minimise the data collected, and how to be transparent with the people answering.

Controller and processor roles

The single most important concept to understand is the split between controller and processor. When you build and publish a survey, you (or your organisation) are the data controller: you decide why the survey exists, what data it collects, and the lawful basis for collecting it. The survey software or hosting provider you use acts as the data processor, storing and transmitting participant response data on your behalf under contractual terms, but never deciding why that data is being collected.

This distinction matters because compliance obligations do not fall on the provider. Establishing a lawful basis for processing, whether that is consent, legitimate interest, or another Article 6 basis, is the controller’s responsibility. The provider supplies the infrastructure; you define the purpose. Anyone designing a survey should start by asking: what is the lawful basis for this data collection, and can it be stated plainly to participants before they answer a single question?

Minimising the data collected

Data minimisation is a GDPR principle, not just good practice. Every question added to a survey should earn its place by supporting a specific, stated purpose. A useful test before publishing: for each question, can you explain why the answer is needed and what will be done with it?

Special-category data, covering health, religion, sexual orientation, political opinion, and similar, carries a higher bar for lawful processing under Article 9 and should be avoided by default. If a survey genuinely requires it, for example a health outcomes study, you need an applicable Article 9 exemption in addition to an Article 6 basis, and should say so explicitly in the survey’s introduction.

Where a question is optional rather than essential, mark it as optional rather than required. Participants should never be forced to disclose more than the survey’s stated purpose justifies.

Participants should know, before they start answering, who is running the survey, why it exists, what data will be collected, how long it will be kept, and who to contact with questions. A short introduction section at the start of a survey, rather than a buried link to a separate policy, is the clearest way to meet this expectation.

Where consent is the lawful basis, that consent needs to be freely given, specific, informed, and unambiguous. A pre-ticked checkbox does not meet this bar; an explicit opt-in does. Where a different lawful basis applies, transparency is still required: participants must be told what is happening with their data even if their agreement is not the legal basis for processing it.

What to expect from your survey platform

As controller you remain accountable for the processing, so part of the design work is checking that whatever platform you use can support your obligations. Before committing to a tool, confirm it offers:

  • Hosting and data residency you can account for. Know which country personal data is stored and processed in, and whether that creates an international transfer you need to document. For many EU and UK surveys, EU or UK hosting removes that question entirely.
  • Encryption in transit and at rest, including for backups, using TLS 1.2 or later for connections.
  • A breach-notification commitment consistent with the 72-hour authority-notification requirement in GDPR Article 33, so you can meet your own deadline if the processor is the source of a breach.
  • Controlled retention and deletion. You should be able to set how long participant and response data is kept, and delete it when the purpose is met. A short recovery window before permanent removal protects against accidental loss while still honouring deletion requests.
  • Sub-processors bound by Article 28 data processing agreements, with advance notice of any changes to the sub-processor list.

None of this replaces your own obligations. It gives you the infrastructure needed to meet them.

Participant rights

GDPR gives participants rights over their own data, including the right to access what has been collected and the right to erasure. In practice, most access and erasure requests are handled by the controller using the participant-management and export tools built into the survey software.

Design for this from the start. Collect enough identifying information to link a request to the right records, but no more than that: a survey that over-identifies participants makes every later request harder to scope. Decide in advance who in your organisation actions these requests and how quickly, so a request that arrives months after the survey closed does not catch anyone unprepared.

Summary

GDPR-compliant survey design comes down to a small number of decisions made early: understanding the controller and processor split, collecting only what the survey’s stated purpose justifies, being transparent with participants before they answer, and knowing how to action access and erasure requests when they arrive. These decisions are independent of the tool you run the survey with. The right platform makes them easier to carry out, but the responsibility for making them sits with you.