When is an employee survey anonymous?

Anonymous means that information does not relate to an identified or identifiable person. Confidential, by contrast, describes who may see or share information. A response handled confidentially can still be personal data: for example, if an external consultant could link it to an individual while the employer receives only aggregated results.

Pseudonymisation is not complete anonymisation either. If a name is replaced by a code and a way of linking the two exists, identification remains possible in principle. The legal assessment follows, in particular, Article 4 and Recital 26 of the General Data Protection Regulation. The text of the GDPR is the starting point; Germany's Federal Commissioner for Data Protection and Freedom of Information (BfDI) also provides it in its GDPR and BDSG collection.

In practical communication, this means that 'The team lead does not see any names' is a specific piece of information. 'Nobody can ever identify who said what' is a much broader promise. Use only statements supported by the entire process.

A minimum threshold can prevent one person's feedback from appearing as a group result. It does not remove knowledge other people already have. In a hypothetical team, for example, only one person may have attended a particular client meeting. If a comment mentions that exact meeting, a larger number of other responses offers little protection.

Conversely, team size says nothing about how many people answer a particular question. Holidays, part-time work, changing assignments or skipped questions can reduce the group available for analysis. What matters is the result actually shown, rather than the number of names on the team list.

The GDPR does not specify a general minimum number of employees that would make every survey anonymous. In its statement on anonymisation, the BfDI explains why a blanket promise of legally certain anonymisation is difficult. A number can be a safeguard, but not a complete answer.

Combinations of characteristics can be particularly revealing. A department alone might include many people. Combined with an unusual role, a particular working pattern and a specific project, it may narrow the group considerably. Review the combination of all information requested.

Ask only for characteristics genuinely needed for the intended decision. If a team wants to improve handovers, detailed information about age, length of service or contracted hours may be unnecessary. Leaving out such information often also makes the survey easier to understand.

Also consider whom an answer is about. A survey can protect respondents while simultaneously assessing a clearly identifiable manager. Germany's Federal Labour Court addressed this distinction in a specific case involving an electronic employee survey. This is not a blanket assessment of all surveys, but it is an important point to check: BAG, decision of 11 December 2018, 1 ABR 13/17.

Free text can explain what lies behind a rating. It can also reveal writing style, events or the people involved. A notice before the input field should therefore ask people not to include names, sensitive individual cases or unnecessarily identifying details.

That request is not a technical guarantee. People may still enter identifying information. Clarify in advance who may read comments and whether they will be shared unchanged, as excerpts or only as thematic summaries. Automatically publishing every comment to the whole team is not the only possible approach.

Hypothetical example: A comment describes an argument during a one-off handover. The information relevant to working together may be that handover responsibilities are unclear. There is no need to project the exact wording to establish that. A summary should represent the content fairly, rather than remove uncomfortable criticism.

Even reports that each cover a sufficiently large group can reveal more than intended when combined. If one report covers the whole team and another covers almost the same people, the difference may in some circumstances allow inferences about the remaining person. Consider these combinations when planning reports.

The same applies to rapidly changing filters or reports published in close succession. The more freely different versions can be combined, the harder it becomes to limit the risk of inference through a minimum count alone. Check exports and subsequent analyses as well as the default overview.

For small teams, a simple report is often more appropriate: a few topics, no unnecessary subdivisions and a defined time for reporting. A simple report is not automatically anonymous. It is, however, easier to explain and assess for possible inferences.

The visible results screen is only one part of the process. Also check which data is generated during invitation, sign-in, submission, storage and technical operation. A personal invitation link may be convenient to administer; whether and how it remains linked to answers needs separate clarification.

Ask the provider specific questions: Are identifiers stored with answers? Which logs are created? Who can access raw data? What can be exported? How are backups handled? 'The report contains no names' does not tell you anything about these other processing steps.

An external service provider does not automatically solve the problem. It can create a useful organisational separation. Whether the underlying data is personal data, and which agreements or safeguards are required, still depends on the actual process. Data protection roles should be clear before the first invitation is sent.

Explain the purpose, who is authorised to access information and how results will be used. Also state when information becomes visible, how free text is handled and what happens if too few people respond. Make this information accessible before participation.

A clear explanation can acknowledge limits. For example: 'We show only aggregated results. Descriptions of particular events may still be recognisable. Please use the designated contact route for sensitive individual matters.' This is more helpful than a sweeping promise of anonymity with limitations that are hard to find.

Collect questions from the team and answer them before the start. If a safeguard is to change later, update the information about it too. An introductory message sent once is no substitute for handling changes transparently.

Do not lower an agreed threshold on the spot simply to display a result. Instead, consider whether the question can be addressed within a larger, meaningfully related group, or whether another process is more suitable. Merging arbitrary teams may increase the count while making the result unusable.

A facilitated discussion or confidential individual feedback may also be appropriate if its nature is explained honestly. It should then not be called an anonymous survey. The purpose, protection and process need to fit together.

The article on pulse surveys in small teams helps with choosing a format. Further information about the specific product process is available under confidentiality and co-determination.

EngageBeat shows results to authorised team owners after the weekly survey closes and once there are at least five valid responses per question. The product information on confidentiality also explains that this threshold is neither an identity check nor an absolute guarantee of anonymity. Before using it, check whether this framework suits your team.

This article provides general guidance and is not legal advice. The specific data protection assessment depends on your process.