Security principles for protecting the most sensitive personal information in datasets
Pages
Page 6 of 10
Principle 5. Avoid putting too much sensitive data together
Don’t make your data too attractive a target
Aggregating a lot of personal data increases the value of the dataset and its attractiveness to an attacker. It can also increase the severity of a data breach if the dataset is lost or stolen.
Don’t make your data too easy to exploit
Grouping together related data about individuals creates a richer digital picture of their lives. Even if data is not grouped together intentionally, having a broad range of data accessible in the same place or under the same access rights can allow an external attacker or inside threat user to piece together a rich digital picture of a person.
A name, address and NHS number are personal data. A bulk loss of such data by an organisation is already a serious issue. But if this lost data was grouped with a further dataset that detailed the medication prescribed to particular NHS numbers, there would be an increased risk to those individuals.
Considerations for technical implementation
Depending on your assessment of the impact and likelihood of risk to your SPI, you could take one or more of the following steps to reduce the risk of access to sensitive data:
- keep data separate by assigning different access rights to different datasets
- partition different data into different data tables in a database
- store different data on different database instances
- store different data on different computing machine instances
Data partitioning and separation techniques are expensive to implement so you should weigh them up against the impact of compromise of individuals' SPI. The chosen techniques should always be proportionate to the risk, considering the cost to implement them.
In cases where you have an elevated risk to individuals of a data breach, and the motivation and capability of attackers getting access to that data is high, you could separate storage of the most sensitive data using different access mechanisms, such as:
- different database systems or applications
- different encryption keys
- different authentication credentials, preferably separately held
The additional need to compromise more than one type of system, application or access control makes it much harder for an attacker to breach the data.
Splitting data
Splitting the same data into different data zones, tables or other ways of limiting access helps to constrain what data can be returned in a database query. This needs the addition of a database index lookup. An example of this is below, with a naïve index for illustration purposes only, and each table can be ascribed separate access rights:

Whilst splitting data can be effective and relatively inexpensive to implement, if all this data still resides in the same database, a more determined attacker – or weak access controls – could still allow full access to this sensitive data. More robust access controls can be achieved by using tokenisation or cryptography.
Tokenisation
A simple example of tokenisation is below, where the same sensitive data is replaced by tokens, and the rights to access the data represented by the token are subject to access controls such as person, machine or role-based accesses.

Encryption
Below is an example using encryption to protect the sensitive data items, where in this case each of the two data items is protected with a different key. If a person, role or machine needs access to all of the sensitive data, they need to be given both keys to do so.

Although encryption is an important technique in securing data, using a single key for encrypting multiple data can introduce unintended risks. For example, where a key is used to encrypt multiple fields or data items, there is a risk that a user could decrypt all artefacts that were encrypted with the corresponding encryption key, such as all Home Addresses. Similarly, encrypting identical data (such as identical dates of birth or occupation) with a single key can result in identical encrypted data, which then risks finding multiple people who share the same data even without that data being decrypted. Ideally you should use encryption software that has the ability to use defensive mechanisms – such as random initialisation vectors – to help protect against these risks.
Where possible you should encrypt different fields, or data items, using different keys, and then put an access control policy on those keys to ensure that only users with a valid need to decrypt those fields can do so. An access control policy on decryption keys also gives the benefit that requests to use decryption keys can be recorded and logged.
Encryption techniques and methods continue to be developed and you should keep abreast of these through the NCSC guidance portfolio such as Advanced Cryptography - NCSC.GOV.UK, particularly where emerging methods are directly applicable to protecting personal data in bulk datasets.