SecurityMarkdown

Encryption, layer by layer

Customer data is encrypted in transit: HRHive is served over HTTPS only, with HTTP Strict Transport Security. Date of birth, National Insurance number and bank details are also encrypted individually, with a separate key for each organisation, and documents are downloaded through signed links that expire. Other data is protected by access controls rather than by additional encryption in the application.

Encryption makes information unreadable to anyone without the right key. HRHive uses it in three layers. This page says exactly where each layer applies, and where encryption is not used.

The facts

  • HRHive is served over HTTPS only, with HTTP Strict Transport Security.
  • Date of birth, National Insurance number and bank details are encrypted individually with AES-256-GCM, using a separate key for each organisation.
  • Documents are downloaded through signed links that expire, not through public addresses.
  • Each organisation's data is kept apart in the database by row-level security, which applies to every table that holds organisation data.
  • There are eight roles (owner, admin, HR, manager, payroll, compliance, employee and a read-only auditor), and sensitive fields such as bank, salary, National Insurance and medical details are shown only to the roles that need them.
  • Downloads of documents, views of right to work evidence and bank details, views of cases and most exports are recorded in the audit log.

Layer 1: the connection

HRHive is served over HTTPS only, with HTTP Strict Transport Security (HSTS). HTTPS encrypts the connection between your browser and HRHive, so what you send and receive is encrypted in transit. HSTS tells your browser to use only secure connections to HRHive, so it does not fall back to an unencrypted one.

Layer 2: the most sensitive details

Date of birth, National Insurance number and bank details are encrypted individually with AES-256-GCM, using a separate key for each organisation.

  • Individually means each of these values is stored in encrypted form on its own.
  • AES-256-GCM is a widely used encryption standard.
  • A separate key for each organisation means one organisation's key does not unlock another organisation's data.

Bank and National Insurance details are also shown only to the roles that need them.

Layer 3: document downloads

Documents are downloaded through signed links that expire, not through public addresses. A document does not sit at a permanent web address that anyone who had the link could open later.

What HRHive does not encrypt itself

Only the three fields above are encrypted by the application. Everything else, including uploaded documents such as right to work evidence, is not encrypted individually by HRHive. It is protected by access controls and by our hosting platform, rather than by additional encryption in the application:

  • each organisation's data is kept apart in the database by row-level security;
  • eight roles decide who sees what, and sensitive fields are shown only to the roles that need them;
  • downloads of documents and views of right to work evidence are recorded in the audit log.

The access controls page explains these in full.

What we do not claim

  • That all data is encrypted by HRHive. It is not. The three fields named above are.
  • Encryption at rest by our hosting providers. We have not yet confirmed it with each provider, so we do not rely on it here.

Frequently asked questions

Is our data encrypted in transit?
Yes. HRHive is served over HTTPS only, with HTTP Strict Transport Security, so the connection between your browser and HRHive is encrypted.
Are passport copies and other uploaded documents encrypted?
Not individually by HRHive. Uploaded documents are protected by access controls, they are downloaded through signed links that expire, and views of right to work evidence are recorded in the audit log.
Does each organisation have its own key?
Yes, for the fields HRHive encrypts itself. Date of birth, National Insurance number and bank details are encrypted with AES-256-GCM, using a separate key for each organisation.

Change history

  1. First published.