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 the database itself.

On every field in an uploaded list, a user will be able to configure whether a field is encrypted or not:

The data will be encrypted in the same way that survey data is encrypted. More details are contained in this article.

As result, encrypted data will appear like this in the SQL table:

Key Encryption

• A different encryption key will be used per field.
• This encryption key will be stored in the ListsFields table, encrypted using the same encryption keys that are used on survey data fields (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 to find a contact via the API will be limited: The field will only be allowed in a top-level AND/NOT condition.
  Using an encrypted field to a find contact through CCA, Supervisor or CATI will not be impacted (because only top-level conditions are used).
  Also note that the performance will likely be impacted when finding a 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.

Default settings

In the general settings, there is a new setting to indicate the default encryption for new lists:

By default, the setting is set to "None".