LimeSurvey can encrypt personal data before it is written to the database, so that names, email addresses and sensitive answers are unreadable to anyone reading the database directly. It is switched on per field, not per survey, and there are three separate places to do it.
Two things to get straight before you start.
Encryption is not anonymity. Encryption changes who can read the data outside LimeSurvey. Anonymity changes whether the link between a person and their answers exists at all. If your goal is that nobody — including you — can connect a response to a participant, you want anonymised responses, with or without encryption on top.
Your data stays visible in LimeSurvey. Only the stored value is encrypted. Anyone who can log in and open a response or a participant record still sees the plain value, and exports come out readable.
Field-level encryption protects data at rest: someone reading the stored values without going through LimeSurvey. That covers a stolen database backup, a compromised database account, or anyone with database-level access who has no business seeing respondent names.
It does not protect against a logged-in user who has permission to view responses, an exported file, or a screenshot. Those are permission and process problems, not encryption problems.
Survey menu → Participants → Manage attributes
Each attribute row has an Encrypted? toggle, set to On or Off.
Check this before you assume anything. On a current LimeSurvey Cloud survey the three core attributes — firstname, lastname and email — show Encrypted? = Off. If you need participant names and addresses encrypted at rest, switch them on yourself and click Save. Custom attributes you add are off as well, and they are usually where the sensitive identifiers actually sit: employee number, patient ID, customer reference.
Participant attribute encryption can be changed at any time, including after the survey is activated.
Configuration → Central participant database → Attributes, which opens Attribute management.
Here the columns are Name, Attribute type, Visible, Encrypted, Core attribute and Action, and the toggles read Yes / No rather than On / Off.
The defaults here are the opposite of the survey participant list. The three core attributes — email, firstname, lastname — are marked Encrypted: Yes out of the box. Attributes you add with Add new attribute are not, so set encryption when you create them.
This matters more than it looks. The central participant database keeps its copy of a person's details independently of the surveys they took, so those records outlive the surveys themselves.
Select the question in the survey editor, open Question settings, and switch the panel to Advanced. Under General, directly below Mandatory, is Store answers encrypted — set to Yes or No. The default is No.
It is not in the Simple view, so if you cannot see it, that is the first thing to check.
The classic editor calls the same setting Encrypted, with On / Off, and its question summary lists it as Encrypted: No. One setting, two names — worth knowing if you are searching the interface for it.
Decide this before you activate. Once a survey is active the whole General block — Type, Mandatory, Store answers encrypted, Save as default values and Other — is greyed out, and hovering over it shows "Deactivate survey to edit". So if the controls look present but dead, the survey is live; that is the reason.
You can deactivate to change it, but deactivating archives your responses, so treat this as a pre-launch decision rather than something to revisit. If you are unsure whether a question will end up holding personal data, switch encryption on before you go live.
Encrypt selectively. The questions worth encrypting are the ones that identify somebody: name, email, address, phone, ID number, and free-text boxes where people write about themselves. Encrypting a 1–5 satisfaction rating gains nothing and costs you the ability to filter on it.
The stored value becomes ciphertext, so anything that works by reading inside the value stops working on that column.
| Still works | Stops working |
|---|---|
| Viewing and editing inside LimeSurvey | Partial or "contains" search |
| Exact-match search | Alphabetical sorting on that column |
| Exports — values are decrypted on the way out | Reporting directly against the stored column |
LimeSurvey states this limitation directly: partial string search is not possible on an encrypted column, only exact match.
In practice it bites hardest on the participants table. If your support routine is "search part of the email address to find the record", encrypting that column changes how your team works — an exact address still finds it, a fragment no longer will.
They answer different questions, and a data-protection review will usually ask about both.
| Encryption | Anonymised responses | |
|---|---|---|
| What it changes | Who can read stored values from outside the application | Whether a response can be traced to a participant at all |
| Can an admin still see it? | Yes | No — the link does not exist |
| Changeable after activation? | Participant attributes yes; question encryption only by deactivating | No |
Neither covers retention. Deciding how long you keep the data, and deleting it when that time is up, is a separate job from both.