Data protection vs. data security

GDPR has focussed everyone’s attention on data protection. But often, people get confused between data security and data protection. Read on to learn the difference.
Data protection vs. data security
GDPR has focussed everyone’s attention on data protection. But often, people get confused between data security and data protection. Read on to learn the difference.

As CEO of a company specialising in data protection, I often find myself explaining the difference between data protection and data security. In the following blog, I explain the difference and show how they are both required when you are handling sensitive data such as health records.


Data protection and data security are closely linked. Data security is the process of securing data so that only authorised people can access or modify it. Typically, you are protecting your data against physical theft, attacks over the network and theft by employees/trusted people. Data protection is defined as “legal control over access to and use of data”. More specifically, GDPR refers to “the protection of natural persons with regard to the processing of personal data”. Data security can be seen as one key element in achieving data protection. However, data protection is far wider-ranging.

data protection and security requirements -

Data protection

GDPR focuses on the protection of “personal data”, defined as:

“any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such  as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.”

Achieving data protection takes a combination of administrative and technical measures. Administrative measures include legal aspects (privacy policies, terms and conditions, etc.).

One of the most important aspects of GDPR is the legal basis for processing a subject’s data. In many cases, the basis will be “informed consent”, which can be withdrawn at any time. However, there are several other legal bases, some of which may well apply in a healthcare context (e.g. GDPR art. 9(2.i) "processing is necessary for ... public health").

Rights of data subjects

GDPR  grants data subjects 8 fundamental rights:

List of GDPR data subject rights
  1. Right to be informed: Ensure your users have been told what personal data you are collecting and how you will use it (how it will be processed). This includes using their data for automated decision making or profiling. See GDPR art. 13-14.
  2. Right of access: Give users control over whether their personal data is being processed, and, if requested, provide a full copy of all their data within a reasonable time. This must include additional information relating to how the data has been processed as set out in GDPR art. 15.
  3. Right to rectification: If a user requests rectification, you must update/correct the data you hold about them without undue delay.
  4. Right to erasure (right to be forgotten): When a user asks, you must delete all the data you hold on them without undue delay if there is no overarching reason to continue processing it. This is problematic if you are storing backups.
  5. Right to restrict processing: In certain circumstances, such as while awaiting a decision relating to rectification or erasure, a user can ask you to “quarantine” their data and no longer process it.
  6. Right to data portability: When asked, you must provide the user with a full copy of all their data in a structured, commonly used and machine-readable format such as JSON.
  7. Right to object: Where you are processing data on the basis of a) public interest or official authority vested in you or b) your legitimate interests (or those of a 3rd party), the user has a right to object to this which you must consider. This also applies to use of their data for direct marketing purposes.
  8. Rights in relation to automated decision making and profiling: A user may deny you permission to make decisions solely on the basis of automatic processing or profiling which has any legal effects or affects them significantly. Importantly, you can only carry out this type of decision-making where the decision is: 1) necessary for the entry into or performance of a contract; 2) authorised by Union or Member state law applicable to you; 3) based on the individual’s explicit consent.

Technical requirements

Many of these rights, such as the right to erasure and the right to data portability, require technical measures to implement them. GDPR also has strict rules relating to breach notification (informing users and data protection authorities as soon as you suspect a data breach). Following any reported breach, the DPA has a right to inspect all your systems and will want to see detailed logs relating to data access, consent, etc.

GDPR is careful to avoid being over-prescriptive about how you should protect personal data. This is for two reasons. Firstly, not all businesses have equal resources and may be storing data in very different forms. Secondly, data security is an ever-evolving field, so if GDPR mandated a given approach it would quickly be outdated. NB, this is in stark contrast to HIPAA, which makes very precise recommendations relating to data security.

Data Security

There are three main forms of data security. Firstly, you need to be able to authenticate users and check what data they are allowed to access. Secondly, you need to actually secure that data, typically using some form of encryption. Thirdly, you need to protect your network, usually with a firewall.

AAA (authentication, authorisation and accounting) is used to control who has access to data, what they are allowed to do with that data and keeping records of every access/change.

Encryption involves securing your data with a cryptographic algorithm and a key. Data should be encrypted at rest (storage) and in flight (e.g. when you transfer it from the user device to the backend).

Firewalls help protect against network threats such as unauthorised access, ransomware and viruses.

There are also several other techniques that help secure your data. One of the best-known is pseudonymization. This involves storing the user IDs separately from the actual data.

Protecting sensitive data

Some data is inherently more sensitive and so the GDPR states that certain types of personal data should receive special protections. These include many types of data relevant to eHealth apps such as health data, genetic data, biometrics and data relating to sexuality. In order to process such data, you need to meet one of the conditions in Article 9(2) of the GDPR.

Sensitive data like this must be stored securely and protected from unauthorised access. GDPR specifies that this must be done taking account of the state of the art. This is where data protection and data security come together. Advice and guidance relating to technical issues are provided by the European Data Protection Board (formerly the Article 29 Working Party). The EDPB suggest that, as a minimum, sensitive data must be stored using record-level encryption, pseudonymization and proper AAA controls. Achieving this properly is not a trivial task, especially if you need to be able to analyse and search the data. Clearly, for most eHealth applications, both analysis and searching are essential. service and technology

How helps

Here at, we have developed a secure API that makes it easy to store your data in a compliant manner. We offer a simple OAuth2 user management API which makes it easy to implement fine-grained access control. Our system allows you to pseudonymize data effortlessly, without losing the ability to search the data. All data is stored using record-level encryption by default. Every action is recorded in an immutable audit log. Overall, using our API will save you months of development effort and gives you peace of mind that your data storage is compliant.