Skip to main content
Guidance

Security principles for protecting the most sensitive personal information in datasets

How to identify and protect against the risks associated with sensitive personal information in your data holdings.

Page 10 of 10

Principle 9. Keep access controls to SPI separate from routine data access controls

You should aim to ensure that the process which authorises access to, or decodes data containing, SPI is kept as a separate process from routine database access processes. In this way inappropriate access to SPI only occurs if more than one access control is caused to fail.

For example, if access to SPI in a person's record depends on other obvious data in that record, an adversary only needs access to one database to obtain the SPI - because the access control is integrated with the data, not separated. 

A better approach is to encrypt the SPI data in the database, which would require an additional processing step for the adversary to access the SPI.

Better still, if the SPI data is encrypted in a different database with separate access control credentials, the adversary has to overcome multiple security barriers to access the SPI.

Below are some examples of sensitive data access controls and typical techniques that would allow an attacker to gain access to the sensitive data. Many of the techniques below are not mutually exclusive and combining some can further improve the security of the data.

Type of Access ControlWhat an attacker needs to do to access the SPI
Flag showing sensitive records – this is not recommended, but is included for illustration only

A malicious attempt only needs to:

  • access the data
Encoded/encrypted flag describing why records are sensitive

A malicious attempt needs to:

  • access the data and
  • break encoding/encryption

to know which records are sensitive – and potentially why.

Database access controls or stored procedure algorithms on sensitive records

A malicious attempt needs to:

  • exploit database access controls or
  • exploit stored procedures (row-level security or in-line table-value functions) or
  • gain privileged access to the database or 
  • get a bulk copy of the data.  

The records' access criteria would indicate which records or data are sensitive – and potentially why.

Independent process controlling access to sensitive records

A malicious attempt needs to:

  • access the database to access the data and
  • exploit the independent process 

to find out which records are sensitive – and potentially why.

Database native cryptography for protected sensitive fields 

A malicious attempt needs to:

  • gain privileged access to the database, or achieve privileged processing 

to discover which records are sensitive and to decrypt that data.

Sensitive fields secured through independent cryptography

A malicious attempt needs to: 

  • access the database to access the data and
  • exploit the independent cryptography – or the cryptographic process

to know which data are sensitive and to decrypt that data.

Independent cryptographic protection for all personal data

A malicious attempt needs to:

  • access the database and 
  • exploit the independent cryptography 

to access any personal data and to know which data are sensitive.

Published

Reviewed

Version

1.0

Written for