What personal data should be encrypted in a database?

Question

I am having trouble answering what seems like a simple question. I was hoping to find a Yep/Nope style list somewhere, but can't seem to find one.

What data should be encrypted in a cloud (e.g. AWS/Azure) database?

I have researched ICO as well as Stack Exchange Posts, but can't find a direct answer.

Obviously passwords should be hashed and bank card details encrypted, but what about information such as the following?

• Name

• Address

• Telephone Number

• Passport Number

• National ID

• Bank Account Number

These details are sensitive, but do they need encrypting?

Answer 1

There is no definitive list of PII that should be encrypted.

Encryption is a security control that mitigates risk. There are many other controls than can achieve the same result.

So, you need to perform a risk assessment to determine what stakeholders require, what regulatory/legal obligations you have and what risks you face that could be mitigated with encryption.

Encryption is often a Good Idea™, but regulations tend not to specify it because encryption is not a "tick the box" exercise and the regulations don't want to get into the technical details of how to do it correctly. They just specify an outcome they expect.

So, to answer your question, the data that should be encrypted is the data that you have determined should be encrypted.

Answer 2

It depends on the purposes and permissions you have to use user data. Encryption is not really means of blocking third party access to the data. Databases per se are protected, so data access is already restricted to outsiders. It is more that encryption is a way for you as data processor not to have access to data that you're not supposed to have access to, but you have to store. In general, it is only reasonable (and required) that you do not collect data that you don't need.

Clearly due to particularities of passwords, you as a person do not need access, but your application does to be able to authenticate users. This particular machine-user separation of passwords is not the case with any of the other values you've listed and would rarely be the case for non-secrets.

A somewhat similar situation is when you represent a shop that stores customer credit card details. You as a shop do not need the payment information of the user, but you need to carry it from the user to the payment operator/provider. This is when your payment provider would guide you how to encrypt this data in a way that they could decrypt it without having to give you access to it.

Another possible situation might occur if you're legally required to collect e.g. personal identifiers of users to share with some authorities, but you and your organisation do not need to access this data. In this case you can store it encrypted with keys that only the corresponding authorities have. In this case you would ask them e.g. to generate a public-private pair key and share with you the public key so that you can encrypt something that only they can decrypt.

So in general you don't need to encrypt other data. It's more that you might rather not collect it.

Another aspect of privacy protection is that you're not supposed to store user personal information more than the time you need it. A good pattern to manage this is to use pseudonymisation. Basically, the idea is that you generate identifiers that are not traceable back to the personal data. Once you stop needing the personal data, you remove it, but the pseudonym that you use as identifier remains, thus becoming an anonymous user.