A practical GDPR checklist for anyone collecting survey responses in the EU

This is general information, not legal advice. GDPR obligations depend on what you're collecting, why you're collecting it, who the respondents are, your role in the processing, and the surrounding context. A real compliance assessment may need someone qualified to advise on your specific situation. What follows is a practical checklist for avoiding common survey-data mistakes.

1. Know what "personal data" can include

The definition is wider than names and email addresses. Information can be personal data when it identifies someone directly or when, in context, it can reasonably be linked back to an identifiable person. In survey work that can include:

• IP addresses and other online identifiers
• Free-text answers that mention someone's role, department, location, or a specific incident
• Combinations of answers that narrow down to one person in a small population

A common mistake is calling a survey "anonymous" while still storing direct or linkable identifiers in the background. Removing a name is not enough on its own. Hashing or otherwise pseudonymising an identifier can reduce risk, but pseudonymised data can still be personal data under the GDPR when it remains linkable to an individual using additional information or other reasonably available means.

Checklist: If you're promising respondents anonymity, inspect what the tool actually stores — raw IPs, account identifiers, device metadata, hidden fields, and small-group demographics all matter. Treat "anonymous" as a claim you need to be able to defend, not a cosmetic label.

2. Identify a lawful basis before collection starts

Processing personal data needs an applicable lawful basis. Which one fits depends on the purpose and relationship involved; consent and legitimate interests are only two of the possibilities, and neither is automatically correct for a survey.

Consent, when relied on, has to satisfy the GDPR's requirements rather than functioning as a decorative checkbox. Legitimate interests requires its own assessment and balancing. Employment, health, research, public-sector, and special-category data can introduce additional rules beyond the basic lawful-basis question.

Checklist: Decide and document the basis for the processing before launching the survey, and make sure the respondent-facing explanation matches what you are actually doing with the data.

3. Only ask for what you need

Data minimisation is a GDPR principle and usually good survey design. Every unnecessary identifier or demographic field increases both privacy risk and respondent effort.

Checklist: For every field, ask what concrete purpose requires it. If the survey can fulfil its purpose without the data, remove the field or make the collection less identifying.

4. Have a retention policy — and enforce it

Personal data should not be kept longer than necessary for the purpose for which it was collected. That does not mean every survey has the same correct retention period; it means you should be able to explain why the period you chose is necessary and what happens when it ends.

Checklist: Give surveys or datasets an actual retention/review date, document exceptions that require longer retention, and make deletion or genuine anonymisation part of the process rather than an aspirational policy sentence.

5. Plan for data-subject rights before requests arrive

Depending on the circumstances and lawful basis, respondents may have rights such as access, correction, objection, restriction, portability, or erasure. Those rights are not all absolute, and a genuinely anonymous dataset may no longer allow you to identify a particular respondent at all.

If you are the survey owner/controller, your tooling should make it practical to locate, export, correct, or delete data when you are legally required to do so. The provider's own account-export feature does not, by itself, satisfy every controller obligation you may have toward respondents.

Checklist: Work through how you would handle a real request using the identifiers you intentionally collect. If the answer depends on an emergency engineering script, improve the process before you need it.

6. Know where data is processed, not just where one database sits

Hosting location can matter, especially where international transfers, procurement rules, contractual commitments, or sector-specific requirements apply. But "hosted in the EU" is not a complete GDPR analysis on its own: subprocessors, support access, backups, analytics, email providers, and other transfers can also be relevant.

Checklist: Understand the provider's hosting and subprocessors, any transfers outside the EEA, and the safeguards that apply to those transfers. Use the answer in your own controller assessment rather than treating geography as a compliance badge.

7. Use stronger security when the data warrants it

Sensitive surveys — for example health information, whistleblowing reports, or HR complaints — deserve a security model proportionate to the risk. Encryption in transit and at rest are important baseline protections. Client-side end-to-end encryption can provide a stronger property when it is implemented correctly: the response content is encrypted before it reaches the survey provider, so the provider does not hold the decryption key needed to read that content.

End-to-end encryption does not remove every compliance obligation. Metadata, recipient access, key management, retention, and the survey owner's own handling of decrypted data still matter.

---

Where Surveyee stands on these points: anonymous mode is the default, and in that mode raw respondent IP addresses are not persisted; Surveyee uses EU/Germany hosting for its core service; account export and deletion are available as self-service account controls; and survey owners can opt into end-to-end response encryption. Those product properties can reduce risk, but they cannot make a controller's specific survey automatically "GDPR compliant." Use them as building blocks in your own assessment, not as a substitute for one.