We strongly advise that you also apply data encryption to all anonymized data. Askia has added anonymization & encryption features across the board that can be activated on all existing data as soon as you have updated to V5.4.9 of Askiafield. Encryption is available on both survey and list data.
List Data Encryption
To protect sensitive data from being read in SQL Server directly (either by a DBA or in case of a security breach), sensitive data should be encrypted in database.
On every list field a user will be able to configure whether a field is encrypted or not:
The data will be encrypted the same way survey data is encrypted. Please refer to this article.
As result, encrypted data will appear like this in SQL table:
- A different encryption key will be used per field.
- This encryption key will be stored in the ListsFields table, encrypted the same way as survey data encryption keys (using the master encryption key).
- It will be possible to retrieve the encryption keys using the API.
- If a field is encrypted, using that field in a find contact through the API will be limited: The field will only be allowed in a top-level AND/NOT condition.
Using the field in a find contact through CCA, Supervisor or CATI will not be impacted (because only top-level conditions are used).
Also note the performance will be worse for find contact with a condition on an encrypted field.
- Encrypted data will be decrypted when exporting the list to LST
- If a field is encrypted it won’t be available for quota – so the list will be considered ‘not compatible’ if a quota question has an import for an encrypted list field.
- The external unique ID field cannot be encrypted.
In the general settings, there is a new setting (quite self-explanary) to indicate the default encryption for new lists:
By default, the setting is set on "None".