Security principles for protecting the most sensitive personal information in datasets

When considering data protections, you should ensure that users with SPI associated with them are not disadvantaged compared to those without. Whatever the sensitivities about an individual’s data, it is important that:

• everyone receives the same level of service
• an individual is neither disadvantaged nor placed at higher risk as a result of how data about them is stored, accessed or processed
• business processing of an individual’s data is not impeded by any sensitivities
• access to an individual’s personal data, especially that containing SPI, is limited only to those people with a specific business need to access it

There are occasions when it is necessary to differentiate processing on the basis of data sensitivity.  This is covered below in the section When there is a business need to differentiate the sensitive records in the dataset.

One of the most apparently intuitive ways to ensure that SPI for individuals is treated more carefully than other data is to label records of individuals with SPI as ‘sensitive’ – using a sensitive flag for instance – and then building access controls around the fact that the record is declared as being sensitive.

Although this can appear to be a cost-effective approach, the negative consequence in the event of data compromise is that it is much easier to find all the higher risk individuals in a dataset simply by looking for all records with the sensitive flag.

You should therefore avoid overtly labelling data records as ‘sensitive’ wherever possible.

Sometimes it’s necessary to differentiate some records from others.  In this case, use techniques that:

• don’t overtly describe a sensitivity
• don’t make individual records stand out as being different
• don’t group together types of sensitive data

You should make access to any sensitivity differentiators – for example, flags or codes – different from access to the main personal data. You could do this by:

• Ensuring that all records have a sensitivity marker – not just sensitive records – but that record-specific differentiators are implemented in a way to make it difficult to decode or uncover the sensitive information unless authorised to.  You can do this by implementing a form of cryptography on such a differentiator – but take care to ensure that the cryptography is applied to avoid the flag or code being encoded in exactly the same way for all similar records – see Principle 5 - Encryption.
• Putting sensitive differentiators for specific records into another database, application or system so that any compromise or loss of the data in one database doesn’t readily expose sensitive records.

If you have to mark records as sensitive, you should ensure that sensitive records don't look any different to other records so that they are harder to find in a bulk dataset.

Losing large amounts of data can be harmful, whether due to accidental loss or a cyber attack. If this data includes SPI, the risk to affected individuals can be significantly higher if it falls into the wrong hands. To mitigate against this, you should:

• make it difficult to discover or deduce the SPI by changing how it is represented or stored
• use techniques such as column-level encryption, tokenisation or storing SPI data in separated index-linked datasets