Data stored in Good Grants is protected by a broad range of security measures by default. Additional data protection options are available on fields, for specific circumstances, which are explained in this article.
General Data Protection Regulation applicability (GDPR)
The European Union General Data Protection Regulation (GDPR) requires that data controllers (that's you) and data processors (that's Good Grants) implement state-of-the-art measures for the protection of the personal data of all natural persons located in Europe. The data protection option on fields is one measure to help with compliance and serves two purposes:
- The data protection setting on fields provides you a clear record of personal data that you are collecting (in the fields list view, you can filter by data protection level or add a column for this visibility).
- Setting Elevated or Maximum security provides additional layers of (state-of-the-art) technical protection on those fields, explained further below.
What if GDPR is not applicable to your program?
Complying with GDPR may not be relevant for you, if you do not store personal data of anybody that is located in Europe— however, we still encourage best-practice protection of personal data wherever you are.
What are the additional protections, and why not just use them by default?
This topic gets technical and theoretical, but since you asked, here goes...
By default with Good Grants, all data in transit (transferring between the user's browser and Good Grants servers) is encrypted. All data at rest (stored in our databases) is encrypted by default too. A lot of data protection measures are to mitigate theoretical risks. Encryption of data at rest is a "disk/file level" protection so that if an attacker gained access to a server at a file level, the data would not be readable due to strong encryption. However, if by some means an attacker were able to gain database read access, they could access decrypted data.
The Elevated data protection level applies unbreakable AES 256-bit encryption to field data before it is stored in our databases. This means that if an attacker were to somehow gain database access, they would still not be able to read data in a field with Elevated/Maximum protection applied. Furthermore, the encryption key is only stored in active memory, making it much harder for an attacker to obtain, than if it is stored on disk (i.e. in code or configuration file). The only way that field content can be read is via the Good Grants application. A disadvantage of this encryption though is that the contents of an encrypted field cannot be searched. Nevertheless, for fields set with Elevated data protection, we have an option to set as searchable— in which case, a hashed version of the data is stored alongside, to facilitate partial search of these fields. This one-way hash is considered less secure than the encrypted data as, in theory, with access to the hashed data, a brute force attack could be used to reveal the data. So an elevated level of protection is achieved, but not maximum protection. The caveat with searchability of a field with Elevated protection is that it can support a case-insensitive exact match, but not a partial match. So for example, a field containing "Joe Bloggs" could be found with a search for "Joe Bloggs" or "joe bloggs", but not with a search for "joe" nor "bloggs".
The Maximum data protection level applies unbreakable AES 256-bit encryption to field data before it is stored in our databases, the same as for the elevated data protection option. However, to achieve maximum protection, you do not have the option for the field to be searchable, and no hash is stored like with Elevated protection.
That is why we don't apply these levels of protection to all fields by default.
When should you use field data protection?
We advise using the additional data protection options for any fields containing personal data (use Elevated protection) or sensitive personal data (use Maximum protection).
GDPR Article 4 defined personal data as:
Any information relating to an identified or identifiable natural person; an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
Sensitive personal data
GDPR Article 9 defines special categories of personal data (sensitive data) as:
Data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation.
If you have legitimate cause to collect these special categories of sensitive data, you should use the Maximum data protection level.