The general features are quite simple. For all new quests created after the 25th of May, GDPR will be enabled by default. This means that the controller will have to create a GDPR statement describing the purpose, duration etc. of collecting the data, and that the data subject will have to accept this on a comply page in order to respond to the quest. Moreover, the controller must make sure to flag any question containing personal data (by default, all open answer questions as well as any uploaded respondent data will be pre-flagged as personal data). When the retention period set for the personal data is up, all data flagged as personal (as well as the IP address) will be deleted from the system, and the respondent’s e-mail address will be anonymized.
In the first release, we provide the following features:
GDPR settings accordion introduced to quest settings:
The rest of the fields are described here:
|Field label||Mandatory||Example for employee engagement|
|Company name (controller)||yes||Questback AS|
||yes||Bogstadveien 54, Oslo|
|Controller’s representative (if applicable)||no||Kanzlei Vollpfeifen & Partner
|Purpose of each processing operation for which consent is sought||yes||The purpose for the processing of personal data for the defined use case is to comply with company regulations regarding continuous dialogue with employees about their work environment, job satisfaction, career opportunities and other elements relevant to their position in the company. Company will use the personal data in order to assess trends in employee satisfaction over years, in order to pinpoint areas where measures are needed for increased employee satisfaction, or to mitigate negative working environment.|
|What personal data will be collected and used||no||Name, email, IP address,|
|What special categories of personal data will be collected and used||no||sexual orientation, health information, trade union membership|
|Retention period||yes||3 months|
|Criteria used to determine processing period (if no retention period has been defined)||yes if unlimited retention period||after 250 survey are completed|
|Legal basis for processing||no||consent|
|egitimate interest of controller or third party (if applicable)||no||evaluate and assess customer satisfaction, improve workplace culture and atmosphere|
|Recipients or categories of recipients of the personal data||no||HR, Senior managemant|
|Transfer of data to a non-EU/EEC country or international organisation, and safeguards||no||transfer to USA based on EU standards clauses|
|Statutory or contractual requirement (if applicable)||none|
|Automated decision making||no||none|
|Information on data subject rights||no||text|
|Information on right to withdraw consent||no||text|
|Information on supervisory authority||no||text|
|Name & contact details of data protection officer (if applicable)||no||Dr. Kinast und Partner
Next to the input field for “Purpose of each processing operation for which consent is sought”, the controller has access to a set of pre-defined purpose statements that can be used when creating GDPR statements:
In quest designer, the controller can easily see which questions and/or respondent data are flagged as personal data:
The controller has two ways of flagging questions and/or respondent data as personal data inside quest designer:
1. From question settings:
2. From Other actions > set properties on multiple questions:
In this dialog, we have in addition to adding the personal data setting, also carried out the following changes:
Access the GDPR Statement Manager from the side menu:
Like all managers in ESS, the user will have access to their own GDPR statements as well as the statements other users in the account have shared:
Shared statements will be shared with all users on the account. Users can use and edit other users’ shared statements, but only delete or un-share their own.
Each statement is mono-lingual, so translations are carried out by creating multiple versions of the same statement, each in their own language.
When creating and/or editing a statement, the controller has access to the same fields as described in “Quest settings” above, with the exception of retention period, which is treated as a quest-specific setting. In addition, he/she will have to tag the GDPR statement with a language using the language control.
Before starting to answer a GDPR enabled quest, the data subject must comply to the consent page:
The main consent page will display the following data:
The rest of the fields are available by clicking the “here” link:
We are not deleting anything in the first iteration but will implement the automatic deletion of fields flagged as personal data as well as the anonymization of the data subject’s e-mail address in the second iteration – scheduled for release prior to the 25th of May, 2018.
is a tool for handling existing responses on quests just GDPR enabled. This will be a button next to the retention period setting in GDPR settings, that when clicked, will give the controller the option to delete personal data for pre-GDPR responses.
Running quest with 50 responses. Controller enables GDPR and flags a few questions as personal data. The automatic deletion will take care of new responses coming in, but for the existing responses, the controller will have to click “Delete personal data pre-GDPR” in order to do the same with the 50 existing responses.
is a tool to cater for the GDPR requirement that data subjects can request to either have their personal data exported in a readable format or deleted. In short this will consist of expanding the current delete function in the responses grid on the follow-up page, as well as when viewing an individual response in follow-up.
When opting to delete a response, the controller will be presented with two options:
The second option will delete all data flagged as personal (incl. the IP address), as well as anonymizing the e-mail address for the selected data subject(s).
The export functionality we currently have in place, already caters for the export of personal data, but will have to be extended with the IP address browser.
is a tool for handling the invitation data.
When the controller uploads any respondent data (and an e-mail address or mobile number), we store this data in a database table separate from the table containing the responses. The system described above will therefore not be able to delete any data connected to the invitation – as opposed to the response. When the data subject responds to the quest, the uploaded invitation data is copied to the response table, and data flagged as personal will of course be deleted from that table. The data will, however, remain in our system as part of the invitation. This is also true for data subjects who don’t answer the quest.
To cater for this, we will introduce a separate “invitation retention period” to the GDPR settings accordion, where the controller can define how long the data uploaded should remain in our system before being deleted. Moreover, we will also introduce a button for deleting the invitation data uploaded prior to enabling GDPR on the quest.