> ## Content Index
> Fetch the complete content index at: https://www.thedelatorrereview.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# GDPR Data Security Explained: A Practical Guide to Technical and Organizational Measures
- URL: https://www.thedelatorrereview.com/gdpr-data-security-explained-a-practical-guide-to-technical-and-organizational-measures/
- Published: 2019-03-15T11:56:00.000Z
- Updated: 2026-08-13T13:34:26.000Z
- Description: A practical guide to GDPR data security requirements, including risk assessments, technical and organizational measures, encryption, pseudonymization, resilience, processor oversight, staff training, authentication, and the ongoing testing needed to protect personal data.
- Author: Lydia
- Tags: GDPR, Integrity and Confidentiality, Cybersecurity, Encryption, Pseudonymization, EU, Multi-factor authentication (MFA), Passwords, ePrivacy Directive, NIS Directive, Technical and Organizational Measures (TOMs), CIA triad, Risk Assessment, Access Controls, Password Security, Privacy Enhancing Technologies (PETs), Anonymization, Data Protection Law

## Key points

Security is a core principle of EU data protection law. Under the GDPR’s integrity and confidentiality principle, personal data must be processed in a manner that ensures appropriate security, including protection against unauthorized or unlawful processing and against accidental loss, destruction, or damage. Organizations must implement appropriate technical and organizational measures to achieve this level of protection.

The GDPR does not prescribe a single set of security controls. Instead, organizations must adopt a **risk-based approach**, taking into account the nature of the processing, the risks to individuals, and the circumstances of the organization. Key requirements include:

1. **Consider the state of the art and implementation costs.** When selecting security measures, organizations must consider the state of the art, the costs of implementation, and the nature, scope, context, and purposes of the processing.
2. **Protect confidentiality, integrity, and availability.** Security measures should ensure the ongoing confidentiality, integrity, availability, and resilience of systems and services that process personal data.
3. **Be able to restore access to data.** Organizations should have measures that allow them to restore the availability of and access to personal data in a timely manner following a physical or technical incident.
4. **Match security measures to the risk.** The appropriate level of security depends on the risks presented by the processing, including risks arising from accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.
5. **Use pseudonymization and encryption where appropriate.** The GDPR specifically identifies **pseudonymization and encryption** as measures organizations should consider when appropriate to the processing and its risks.
6. **Regularly test security controls.** Security is not a one-time exercise. Organizations should maintain processes for regularly testing, assessing, and evaluating the effectiveness of their technical and organizational measures and address weaknesses identified through that process.

**SECTOR-SPECIFIC REQUIREMENTS:** GDPR compliance may be only one part of an organization's security obligations. Businesses operating in regulated industries or handling particular types of information should determine whether additional sector-specific security standards or legal requirements apply. For example, organizations that handle payment-card data may need to comply with the Payment Card Industry Data Security Standard (PCI DSS).

**OTHER APPLICABLE EU LAWS:** Organizations should also consider whether their activities are subject to cybersecurity or security requirements imposed by other EU legislation. Depending on the organization and its activities, relevant frameworks may include the **ePrivacy Directive** and the **NIS2 Directive**, which replaced the original NIS Directive and significantly expanded EU cybersecurity requirements for covered entities.

# What Is Information Security?

**Information security (IS)** is the practice of protecting information systems and the data they process against unauthorized access, use, alteration, disclosure, loss, or destruction. Its central objective is to preserve three fundamental characteristics of information: **confidentiality, integrity, and availability**.

Together, these principles are commonly known as the **“CIA triad”**:

- **Confidentiality:** Information should be accessible only to individuals, systems, or entities that are authorized to access it.
- **Integrity:** Information should remain accurate, complete, and protected against unauthorized or accidental alteration or destruction.
- **Availability:** Information and systems should be accessible and usable by authorized users when needed.

A failure in any one of these areas can have significant consequences for both organizations and the individuals whose personal data they process. Information security measures therefore seek to protect the CIA triad both at the system leveland for the data processed within those systems.

### Resilience and Recovery

Information security also involves maintaining the resilience of systems and services. Resilience refers to an organization's ability to:

- continue operating during adverse conditions, including physical or technical incidents; and
- recover systems, services, and access to information following an incident.

In practice, resilience includes measures such as **business continuity planning, disaster recovery, backups, incident response, and cyber-resilience measures**.

These concepts are particularly important under the GDPR. [**Article 32**](https://gdpr-info.eu/art-32-gdpr/?ref=thedelatorrereview.com) expressly requires appropriate technical and organizational measures that, where appropriate, include the ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services, as well as the ability to restore the availability of and access to personal data in a timely manner following a physical or technical incident.

# Why Does Information Security Matter?

Information security is important not only because it is a legal requirement under the GDPR, but also because **it supports good data governance and helps organizations demonstrate complianc**e with their broader data protection obligations. Security failures can also have significant enforcement consequences: when deciding whether to impose an administrative fine and determining its amount, supervisory authorities may consider the technical and organizational measures implemented by the controller or processor.

Poor information security can expose systems, services, and personal data to unauthorized access, loss, misuse, or disclosure. The consequences are not limited to technical or operational disruption—a security failure can cause **significant financial, physical, and emotional harm to individuals**.

Depending on the nature of the personal data compromised, potential harms may include:

- identity theft and fraud;
- fraudulent credit card transactions and other financial losses;
- targeted scams and social engineering, made more convincing through the use of compromised personal information;
- tax, benefits, or mortgage fraud using another person's identity;
- physical harm, intimidation, or harassment, particularly where information about witnesses, victims, or other vulnerable individuals is exposed; and
- personal safety risks resulting from the disclosure of home addresses or other sensitive information relating to law-enforcement personnel, service members, prison officers, victims of domestic violence, or others whose location requires protection.

The potential consequences illustrate why GDPR security obligations are risk-based. Organizations should consider not only the likelihood of a security incident, but also the **severity of the potential consequences for individuals** if the confidentiality, integrity, or availability of their personal data is compromised.

### Assessing Security Risk: Probability and Impact

Risk, in general, is assessed by considering **two fundamental factors: probability and impact**. 

- **Probability** refers to the **likelihood that a particular event or harm will occur**. When assessing probability, organizations should consider how realistic it is that a threat will materialize, taking into account the nature of the processing, existing safeguards, known vulnerabilities, and the circumstances in which the personal data is processed.
- **Impact** refers to the **severity of the consequences if the event occurs**. The potential impact may vary considerably depending on the nature of the personal data and the individuals affected. Relevant consequences may include financial loss, identity theft, discrimination, reputational damage, loss of confidentiality, physical harm, or other significant economic or social disadvantages.

In other words, probability asks how likely it is that an event will occur, while impact considers how serious the consequences would be if it does. This basic approach to risk assessment is also reflected in the GDPR, which evaluates risks to individuals by reference to their likelihood and severity.

Both elements must be considered because **probability alone does not determine the level of risk**. An event may be unlikely to occur but have extremely serious consequences if it does. Conversely, an event may occur relatively frequently but result in only limited harm. A meaningful risk assessment therefore considers both the likelihood of harm and the severity of its potential consequences.

![](https://storage.ghost.io/c/54/ef/54efeb65-4f2f-479e-b4bb-a9ee526feeaa/content/images/2026/08/ChatGPT-Image-Aug-13--2026-at-05_20_31-AM.png)

The picture above illustrates this relationship. A shallow hole represents a relatively low-impact event, while a deep and dangerous hole represents a high-impact event. The likelihood of falling into each hole represents probability. The greatest risk arises where the individual is both likely to encounter the hazard and likely to suffer serious consequences if the event occurs.

# GDPR Security Requirements

Article [5(1)(f) of the GDPR](https://gdpr-info.eu/art-5-gdpr/?ref=thedelatorrereview.com) establishes the GDPR's “[integrity and confidentiality](https://the-de-la-torre-review.ghost.io/ghost/?ref=thedelatorrereview.com#/editor/post/6a524576e6e846000145d57b)” principle, commonly referred to as the security principle. It requires personal data to be:

> *“Processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures.”*

The security principle encompasses the broader concept of information security. This includes cybersecurity—such as protecting networks and information systems against cyberattacks—but extends beyond cybersecurity to include physical and organizational security measures.

The security principle in [Article 5(1)(f)](https://gdpr-info.eu/art-5-gdpr/?ref=thedelatorrereview.com) of the GDPR should be read together with [Article 32 of the GDPR](https://gdpr-info.eu/art-32-gdpr/?ref=thedelatorrereview.com), which builds on this general obligation and establishes more specific requirements regarding the security of processing. Article 32 requires controllers and processors to implement technical and organizational measures appropriate to the risks presented by their processing activities.

Under [Article 32(3) of the GDPR](https://gdpr-info.eu/art-32-gdpr/?ref=thedelatorrereview.com), adherence to an **approved code of conduct or certification mechanism** may be used as an element to demonstrate compliance with the GDPR's security requirements. However, codes and certifications do not establish compliance on their own. Organizations must still assess their risks and implement appropriate technical and organizational security measures.

In addition to implementing the requirements imposed by the GDPR and other EU Data Protection laws, **Member State Law may include additional requirements**. This may include a mandate to create certain organizational (i.e. specific security policies) and technical measures (i.e. specific requirements for online passwords etc). Organizations must be aware of the requirements at the Member State level and comply with them.

### What Is “Appropriate” Security Under the GDPR?

The GDPR does not prescribe a universal set of security controls. Instead, it requires organizations to implement a **level of security appropriate to the risk** presented by their processing activities.

When determining which technical and organizational measures are appropriate, organizations must consider factors including:

- the **state of the art**;
- the **costs of implementation**;
- the **nature, scope, context, and purposes of the processing**; and
- the **likelihood and severity of the risks to individuals' rights and freedoms**.

As a result, there is **no “one-size-fits-all” approach to GDPR security**. The measures appropriate for one organization or processing activity may be insufficient—or unnecessarily burdensome—for another. Security measures should therefore be tailored to the organization's processing activities and risks and reassessed as technologies, threats, and circumstances evolve.

In practical terms, organizations must implement appropriate safeguards to prevent personal data from being accidentally or deliberately compromised, including through unauthorized access or disclosure, unlawful processing, loss, destruction, alteration, or damage.

### Security Applies to All Processing

The GDPR's security principle **extends beyond the storage and transmission of personal data and is broader than cybersecurity alone**. Appropriate security should be maintained throughout the entire lifecycle of personal data and across all processing activities.

In practice, an effective security program should seek to ensure that:

- **Confidentiality:** Personal data can be accessed, altered, disclosed, or deleted only by authorized individuals—and only within the scope of their authority.
- **Integrity:** Personal data is protected against unauthorized or accidental alteration and remains accurate and complete for the purposes for which it is processed.
- **Availability:** Personal data remains accessible and usable when required. If data or access to it is lost or disrupted following an incident, the organization should be able to restore availability and access in a timely manner.

Together, these concepts form the foundation of information security and are reflected in the GDPR's obligations for controllers and processors.

## Assessing Information Security Risk under the GDPR

Before determining which security measures are appropriate, organizations should conduct an information security risk assessment. The assessment should identify the personal data the organization processes, evaluate its sensitivity and confidentiality, and consider the likelihood and severity of the harm that could result if the data were compromised.

The assessment should take into account the organization's particular circumstances, including:

- the **nature and extent of its premises, systems, and IT infrastructure**;
- the **number of employees and other personnel with access to personal data**, including the nature and extent of that access;
- the **nature, volume, and sensitivity of the personal data** being processed;
- potential threats and vulnerabilities that could result in unauthorized access, disclosure, alteration, loss, or destruction; and
- personal data processed by **processors or other service providers on the organization's behalf**, including the security risks associated with that processing.

The purpose of the assessment is to understand the organization's **actual security risks and select technical and organizational measures proportionate to those risks**. As the organization's processing activities, technologies, and threat environment change, the assessment should be revisited to ensure that its security measures remain appropriate.

## GDPR Organizational and Technical Security Measures

![](https://storage.ghost.io/c/54/ef/54efeb65-4f2f-479e-b4bb-a9ee526feeaa/content/images/2026/08/ChatGPT-Image-Aug-13--2026-at-05_36_43-AM.png)

ChatGPT generated from ICO organizational measures Checklist

### **Organizational measures:**

The objective of organizational security measures is to create a **culture of security awareness** in which protecting personal data is part of an organization's day-to-day operations. As mentioned above, conducting an information security risk assessment is an important organizational measure, but it is only one component of an effective security program.

**Assigning Responsibility for Information Security**: Organizations should clearly assign responsibility for information security. Identifying an individual with day-to-day responsibility for security—and ensuring **that person has sufficient authority, resources, and organizational support to perform the role effectively**—is good practice and may, depending on the organization and applicable law, be required.

Clear responsibility also helps ensure that security is not treated solely as an IT issue. Information security may require coordination among management, IT, legal, privacy, human resources, procurement, facilities, and other functions.

> **Example**  
>  
> The Chief Executive of a medium-sized organization assigns responsibility for information security to the Director of Resources and requires regular reporting to the board.  
>  
> The Resources Department oversees the organization's security program, including developing security policies and procedures, providing staff training, monitoring compliance with security requirements, and coordinating the investigation and response to security incidents.

**Information Security Policies**: An information security policy is another important organizational measure. The appropriate level of formality will depend on factors such as the size and complexity of the organization, the nature and volume of personal data processed, the risks associated with the processing, and how the data is used.

Not every organization will require the same collection of detailed policies and procedures. However, documenting security requirements can help establish consistent practices, communicate responsibilities to personnel, and demonstrate compliance with the GDPR's security obligations.

Whether security requirements are contained in a formal policy or addressed through other documented procedures, organizations should consider matters such as:

- **internal coordination** between personnel responsible for security and other business functions, including the acquisition, maintenance, and secure disposal of IT equipment;
- **third-party access** to premises, systems, or equipment—for example, access provided to maintenance providers—and the additional security controls that may be necessary;
- **business continuity and disaster recovery arrangements**, including how personal data will remain protected and how availability and access will be restored following an incident;
- **employee awareness and training**, so that personnel understand their security responsibilities and applicable policies and procedures; and
- **periodic reviews and testing** to confirm that security measures remain effective, appropriate, and up to date.

Ultimately, organizational measures should ensure that information security becomes an ongoing organizational responsibility rather than a one-time compliance exercise.

### **Technical Security Measures:**

There is **no single set of technical measures that will be appropriate for every organization**. Security controls should be tailored to the organization's business practices, systems, processing activities, and the nature and sensitivity of the personal data involved. Organizations must consider the state of the art, costs of implementation, and the nature, scope, context, and purposes of the processing, as well as the likelihood and severity of risks to individuals.

The GDPR therefore does not necessarily require organizations to implement every available security technology. Instead, it requires technical and organizational measures appropriate to the particular risks presented by the processing—and those measures should evolve as technologies, threats, and organizational circumstances change.

Technical measures extend beyond cybersecurity and the protection of personal data stored on computers and networks. Security incidents can also result from stolen or lost devices, improperly discarded equipment, unauthorized physical access, or paper records that are lost, stolen, or inadequately destroyed. An effective security program should therefore address both **physical security and cybersecurity**.

**Physical Security:** Physical security measures protect the premises, equipment, and physical records through which personal data may be accessed. Appropriate measures will depend on the organization and its particular risks but may include:

- **Premises security:** appropriate doors, locks, alarms, security lighting, CCTV, or other measures designed to prevent unauthorized physical access;
- **Access controls:** procedures for controlling access to offices and restricted areas, including appropriate supervision of visitors and contractors;
- **Secure disposal:** procedures for securely destroying or disposing of paper records, electronic media, and equipment containing personal data; and
- **Equipment security:** measures to protect computers, servers, laptops, mobile devices, removable media, and other equipment against loss, theft, or unauthorized use.

**Cybersecurity:** Cybersecurity measures should protect the networks, systems, applications, devices, and personal data used by the organization. Relevant areas include:

- **System security:** protecting networks and information systems against unauthorized access, attacks, vulnerabilities, and other security threats;
- **Data security:** protecting personal data within those systems through measures such as appropriate access controls, authentication, permissions, and secure storage;
- **Online security:** protecting websites, portals, cloud services, applications, and other online services used to process personal data; and
- **Device security:** securing computers and mobile devices, including appropriate controls for remote working and **Bring Your Own Device (BYOD)** arrangements.

# Processors and Information Security

**Processors can introduce additional security risks, but they can also strengthen an organization's security program.** A controller that engages a processor remains responsible for complying with its GDPR obligations and must ensure that the processor provides sufficient guarantees that the processing will meet the GDPR's requirements. At the same time, processors may provide technical expertise, infrastructure, or security capabilities that the controller does not have internally.

When engaging a processor, **controllers must**:

- **Select processors that provide sufficient guarantees** that they will implement appropriate technical and organizational measures to ensure processing complies with the GDPR and protects individuals' rights.
- **Enter into a written data processing agreement** requiring the processor to implement the security measures required by **Article 32 of the GDPR**, among other mandatory contractual provisions.
- **Require processors to demonstrate compliance**, including by making available the information necessary to demonstrate compliance with Article 28 and allowing for and contributing to **audits and inspections** conducted by the controller or an auditor mandated by the controller.
- **Monitor processor security as appropriate**, rather than treating security due diligence as a one-time exercise performed only when the processor is selected.

Importantly, GDPR security requirements do not apply to processors solely because of their contracts with controllers. [Article 32](https://gdpr-info.eu/art-32-gdpr/?ref=thedelatorrereview.com) applies directly to both controllers and processors. Processors therefore have their own legal obligation to implement technical and organizational measures that provide a level of security appropriate to the risk.

In practice, engaging a processor does not transfer the controller's responsibility for security. Instead, security becomes a shared compliance responsibility: the controller must select, contract with, and appropriately oversee its processors, while processors must independently comply with the GDPR security obligations that apply directly to them.

# Testing the Effectiveness of Security Measures

![](https://storage.ghost.io/c/54/ef/54efeb65-4f2f-479e-b4bb-a9ee526feeaa/content/images/2026/08/ChatGPT-Image-Aug-13--2026-at-05_48_57-AM.png)

Implementing security measures is not enough. [Article 32 of the GDPR](https://gdpr-info.eu/art-32-gdpr/?ref=thedelatorrereview.com) requires organizations to maintain a process for regularly testing, assessing, and evaluating the effectiveness of their technical and organizational security measures. Security must therefore be treated as an ongoing process rather than a one-time compliance exercise.

The GDPR does not prescribe a particular testing method or specify how frequently testing must occur. The **nature, scope, and frequency of testing should be appropriate to the organization's circumstances and the risks presented by its processing activities**. Importantly, the requirement applies to the organization's security measures as a whole—not simply its cybersecurity controls.

Depending on the organization and its risks, testing may include:

- **vulnerability scanning** to identify known weaknesses in systems, applications, and infrastructure;
- **penetration testing** to identify vulnerabilities that could potentially be exploited;
- **testing backup and recovery procedures** to confirm that personal data can be restored following an incident;
- **reviewing access controls and permissions** to ensure that access remains appropriately restricted;
- **incident-response and business-continuity exercises** to evaluate the organization's ability to respond to security events; and
- **audits and reviews of organizational measures**, including security policies, procedures, and staff practices.

Testing may be conducted internally, by independent external specialists, or through a combination of both, depending on the organization's risks, resources, and technical capabilities.

Organizations should document testing activities, findings, and remediation efforts. Where testing identifies weaknesses, appropriate corrective measures should be taken and their effectiveness verified. If a recommended measure is not implemented, the organization should document the reasons for that decision and consider whether alternative safeguards are necessary.

The objective is not simply to identify vulnerabilities, but to establish a continuous cycle of testing, remediation, and improvement so that security measures remain appropriate and effective as technologies, threats, and processing activities evolve.

# Data Availability and Recovery Under the GDPR

Availability is a core component of information security under the GDPR. [Article 32 ](https://gdpr-info.eu/art-32-gdpr/?ref=thedelatorrereview.com)requires controllers and processors, where appropriate, to implement measures that provide the ability to **restore the availability of and access to personal data in a timely manner following a physical or technical incident**.

The GDPR does not define what constitutes a “timely manner.” The appropriate recovery time will depend on the particular circumstances, including:

- the **nature of the organization and its activities**;
- the **systems and services involved**;
- the **nature and importance of the personal data** being processed; and
- the **risk to individuals if the data or processing systems are unavailable** for a particular period of time.

For example, an interruption affecting a system containing information that is immediately necessary to provide critical services may require much faster recovery than an interruption involving data that is rarely accessed.

### Planning for Availability and Recovery

Organizations should consider availability and recovery requirements as part of their information security risk assessment and when selecting appropriate technical and organizational measures.

An appropriate **backup and recovery strategy** is one way to address this requirement. However, simply creating backups is not enough. Organizations should consider whether backups are appropriately protected, sufficiently current, isolated from threats affecting primary systems, and capable of being successfully restored when needed.

Backup and recovery procedures should also be regularly tested to confirm that they operate as intended.

> **Example**  
>  
> An organization regularly backs up its systems and the personal data stored within them. As part of its resilience strategy, it follows the commonly used 3-2-1 backup approach: maintaining three copies of the data, using two different types of storage, with one copy maintained off-site or otherwise appropriately isolated.  
>  
> The organization is subsequently affected by a ransomware attack that encrypts its systems and prevents access to personal data. The loss of availability may itself constitute a personal data breach under the GDPR, even if the attacker has not accessed or disclosed the data.  
>  
> The ransomware also affects two of the organization's available copies. However, an isolated backup remains unaffected and allows the organization to restore its systems and regain access to the personal data within the recovery period identified as appropriate through its risk assessment.  
>  
> Some data may still be lost depending on when the last recoverable backup was created. Nevertheless, the example illustrates why **resilience depends not merely on having backups, but on maintaining a backup and recovery strategy capable of restoring availability when an incident actually occurs**.

The key point is that **availability must be planned for before an incident occurs**. Organizations should understand how long their systems and personal data can reasonably remain unavailable, implement measures capable of meeting those recovery needs, and periodically test whether those measures actually work.

# Encryption and GDPR Security

![](https://storage.ghost.io/c/54/ef/54efeb65-4f2f-479e-b4bb-a9ee526feeaa/content/images/2026/08/ChatGPT-Image-Aug-13--2026-at-06_02_43-AM.png)

ChatGPT generated based on ICO checklist for encryption

**Encryption transforms data into a form that cannot be read without the appropriate cryptographic key.** It can help protect personal data against unauthorized or unlawful access and is specifically identified in [Article 32(1)(a) of the GDPR](https://gdpr-info.eu/art-32-gdpr/?ref=thedelatorrereview.com) as an example of a security measure that organizations should consider where appropriate.

Encryption can protect personal data both:

- **at rest:** protecting data stored on servers, computers, mobile devices, databases, and other storage media; and
- **in transit:** protecting data while it is transferred across networks or between systems against unauthorized interception.

Encryption should not be confused with **cryptographic hashing**. Although both use cryptographic techniques, they serve different purposes. Encryption is designed to be reversible with the appropriate key, while secure hashing is generally intended to produce a one-way representation of data.

### Is Encryption Required Under the GDPR?

The GDPR does **not require encryption in every circumstance**. Whether it is appropriate depends on the nature, scope, context, and purposes of the processing and the risks to individuals.

Organizations should therefore consider encryption as part of their security risk assessment and document their conclusions. Where encryption is appropriate, implementation should address factors such as:

- the **encryption algorithm**;
- the **strength and size of cryptographic keys**;
- the **software and implementation** used; and
- appropriate **key management and protection**.

Encryption should also be **periodically reviewed**. Cryptographic standards and threats evolve, and an encryption method considered secure today may become inadequate as vulnerabilities are discovered or computing capabilities change.

# Pseudonymization and GDPR Security

The GDPR defines **pseudonymization** as processing personal data so that it **can no longer be attributed to a specific individual without the use of additional information**, provided that the additional information is kept separately and protected by appropriate technical and organizational measures.

In practical terms, pseudonymization separates identifying information from the data being processed. For example, an organization might replace a person's name or other direct identifier with a unique code and maintain the information needed to connect that code to the individual in a separate, appropriately protected system.

Importantly, **pseudonymized data remains personal data under the GDPR** because the information can still be linked back to an identifiable individual using additional information. Pseudonymization is therefore different from **anonymization**, where individuals can no longer be identified and the data falls outside the GDPR.

## Is Pseudonymization Required?

Pseudonymization is a **privacy-enhancing technique** specifically identified in[ Article 32(1)(a) of the GDPR](https://gdpr-info.eu/art-32-gdpr/?ref=thedelatorrereview.com) as an example of a measure that may be appropriate to protect personal data. It also appears elsewhere in the GDPR as an important safeguard supporting data protection by design and risk reduction.

[Article 4](https://gdpr-info.eu/art-4-gdpr/?ref=thedelatorrereview.com) of the GDPR defines ‘pseudonymization’ as:

> (5) ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;

The GDPR does **not require pseudonymization in every case**. Whether it is appropriate depends on the nature, scope, context, and purposes of the processing and the risks presented to individuals.

Organizations should therefore:

- **assess whether pseudonymization is appropriate** as part of their security risk analysis;
- **document the assessment and resulting decisions**;
- keep the information necessary to re-identify individuals **separate and appropriately secured**; and
- **periodically review the effectiveness** of the pseudonymization technique as technologies, processing activities, and re-identification risks evolve.

De-identification exists along a **spectrum of identifiability**, rather than as a simple distinction between personal and anonymous data. At one end is fully identifiable personal data, which can be readily linked to an individual. As identifiers are removed, replaced, masked, or otherwise transformed, the data may become pseudonymized or increasingly de-identified, reducing—but not necessarily eliminating—the possibility of identifying an individual. At the other end is anonymous data, where individuals are no longer identifiable and the risk of re-identification has been sufficiently addressed. 

The visual below, developed by the [**Future of Privacy Forum**](https://fpf.org/?ref=thedelatorrereview.com), provides a helpful illustration of this continuum and the safeguards associated with different levels of identifiability.

![](https://storage.ghost.io/c/54/ef/54efeb65-4f2f-479e-b4bb-a9ee526feeaa/content/images/2026/08/ChatGPT-Image-Aug-13--2026-at-06_10_40-AM.png)

****Source & Attribution:** This visual is based on ****A Visual Guide to Practical Data De-Identification**, an original resource developed and published by the ****Future of Privacy Forum (FPF)**. The content has been visually adapted by ****ChatGPT for The De La Torre Review** to align with the blog’s design and aesthetic; the underlying concepts and original resource are attributable to FPF. View the original resource at: [https://fpf.org/2016/04/25/a-visual-guide-to-practical-data-de-identification/](https://fpf.org/2016/04/25/a-visual-guide-to-practical-data-de-identification/?ref=thedelatorrereview.com)

The key benefit is risk reduction: if pseudonymized data is compromised without the separately protected information needed to reconnect it to individuals, the potential consequences of the incident may be significantly reduced.

# Staff Training and Security Awareness

Employees and other personnel are an important part of an organization's security program. Under the GDPR, **any person acting under the authority of a controller or processor who has access to personal data may process that data only on instructions from the controller**, unless otherwise required by law.

Organizations should therefore ensure that personnel understand their responsibility for protecting personal data, are familiar with applicable security policies and procedures, and know how to apply them in their day-to-day work.

### What Should Security Training Cover?

Organizations should provide appropriate initial and refresher training, tailored to employees' roles and their access to personal data. Depending on the organization, training should address:

- the respective **responsibilities of controllers and processors**;
- employees' **responsibility for protecting personal data**, including the consequences of intentionally accessing, using, or disclosing information without authorization;
- appropriate procedures for **verifying the identity of individuals** before disclosing personal data;
- recognizing and responding to **phishing, social engineering, impersonation, and other attempts to obtain personal data through deception**;
- procedures for responding to requests to **access, disclose, or alter personal data**;
- applicable restrictions on the **personal use of organizational systems, devices, email, and internet access**; and
- how to **identify and report suspected security incidents or personal data breaches**.

Training should not be treated as a one-time exercise. Regular refresher training and ongoing security awareness help ensure that personnel remain familiar with organizational requirements and are prepared to respond as technologies, threats, and business practices evolve.

## Passwords and Online Authentication

One of the fundamental challenges of information security is ensuring that **only authorized individuals can access systems and personal data**. Authentication controls are therefore an important component of an organization's security program.

Authentication generally relies on one or more factors:

- **something the individual knows**, such as a password or PIN;
- **something the individual has**, such as a security key or authentication device; or
- **something the individual is**, such as a biometric characteristic.

Using more than one type of factor can provide **multi-factor authentication (MFA)** and significantly strengthen protection against unauthorized access.

### Password Security Under the GDPR

The GDPR does not prescribe specific password rules. Instead, the general security requirements apply: organizations must implement **technical and organizational measures appropriate to the risks** associated with their processing.

Where passwords are used, organizations should follow current security practices rather than relying on rigid or outdated password rules. Appropriate measures may include:

- allowing and encouraging **long passwords or passphrases**;
- screening proposed passwords against **commonly used and known-compromised passwords**;
- permitting password managers and appropriate password-generation tools;
- implementing **multi-factor authentication where appropriate to the risk**;
- protecting authentication credentials during transmission using appropriately secured connections; and
- **never storing passwords in plaintext**, instead using appropriate password-hashing and related protections.

Password controls should also account for human behavior. Excessively complicated composition requirements can encourage predictable patterns, password reuse, or insecure methods of recording credentials and therefore do not necessarily produce stronger security.

![](https://storage.ghost.io/c/54/ef/54efeb65-4f2f-479e-b4bb-a9ee526feeaa/content/images/2026/08/ChatGPT-Image-Aug-13--2026-at-06_24_00-AM.png)

Like other security controls, authentication mechanisms should not be implemented and forgotten. Organizations should periodically review their authentication practices against evolving technologies, threats, and recognized security guidance and update them when necessary.

## Sector-Specific Security Requirements

Certain industries are subject to **specific security standards, regulatory requirements, or industry frameworks**. Organizations should identify the requirements applicable to their sector and incorporate them into their broader security program.

For example, organizations that process payment-card information may be required to comply with the **Payment Card Industry Data Security Standard (PCI DSS)**. PCI DSS compliance does not, by itself, establish compliance with the GDPR. However, compliance with relevant industry standards may be an important consideration when evaluating whether appropriate technical and organizational measures were in place—particularly following a security incident.

### Security and NIS2

EU cybersecurity requirements also extend beyond the GDPR. The original NIS Directive (Directive (EU) 2016/1148)established the EU's first horizontal cybersecurity framework and has since been replaced by the NIS2 Directive (Directive (EU) 2022/2555).

NIS2 significantly expands cybersecurity requirements for covered organizations across critical and important sectors. Among other things, it requires covered entities to implement appropriate cybersecurity risk-management measuresand imposes incident-reporting and governance obligations.

The GDPR and NIS2 have different focuses: the GDPR protects personal data, while NIS2 addresses the cybersecurity of networks and information systems and the continuity of covered services. Nevertheless, the two frameworks frequently overlap. A cyber incident involving personal data, for example, may trigger obligations under both regimes.

### Security and the ePrivacy Directive

Organizations providing certain electronic communications services may also be subject to security requirements under the ePrivacy Directive. The Directive supplements the EU data protection framework in areas involving electronic communications, including confidentiality of communications, cookies and similar technologies, and direct marketing.

### 

## Additional Resources

### Legal Citations

- [Article 32](https://gdpr-info.eu/art-32-gdpr/?ref=thedelatorrereview.com) of the GDPR
- [Recital 75- Risks to the Rights and Freedoms of Natural Persons](https://gdpr-info.eu/recitals/no-75/?ref=thedelatorrereview.com)
- [Recital 76- Risk Assessment](https://gdpr-info.eu/recitals/no-76/?ref=thedelatorrereview.com)
- [Recital 77- Risk Assessment Guidelines](https://gdpr-info.eu/recitals/no-77/?ref=thedelatorrereview.com)
- [Recital 78- Appropriate Technical and Organisational Measures](https://gdpr-info.eu/recitals/no-78/?ref=thedelatorrereview.com)
- [Recital 79- Allocation of the Responsibilities](https://gdpr-info.eu/recitals/no-79/?ref=thedelatorrereview.com)
- [Recital 83- Security of Processing](https://gdpr-info.eu/recitals/no-83/?ref=thedelatorrereview.com)

### Additional Resources: EU

### [**European Union Agency for Network and Information Security**](https://www.enisa.europa.eu/?ref=thedelatorrereview.com) **(ENISA)**

- ENISA’s 2014 report into ‘[Algorithms, key size and parameters](https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014?ref=thedelatorrereview.com)’;
- [Data protection section](https://www.enisa.europa.eu/topics/data-protection?ref=thedelatorrereview.com) at ENISA’s website
- ENISA [NIS Directive tool](https://www.enisa.europa.eu/topics/nis-directive/nis-visualtool?ref=thedelatorrereview.com)
- ENISA [Opinion Paper on ISAC cooperation](https://www.enisa.europa.eu/publications/enisa-position-papers-and-opinions/enisas-opinion-paper-on-isac-cooperation/?ref=thedelatorrereview.com) (March 2019): On this brief paper, ENISA shares its opinion is support of the on the ongoing developments and traction of Information Sharing and Analysis Centers (ISACs).

[**Information Commissioner’s Office (ICO)** ](https://ico.org.uk/?ref=thedelatorrereview.com)**&** [**National Cybersecurity Center (NCSC)** ](https://www.ncsc.gov.uk/?ref=thedelatorrereview.com)**— UK**

- The NCSC’s[ password guidance](https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-your-approach?ref=thedelatorrereview.com);
- Additional NCSC guidance on the use of [multi-factor authentication in online services](https://www.ncsc.gov.uk/guidance/multi-factor-authentication-online-services?ref=thedelatorrereview.com). Although primarily aimed at large organizations, this guidance summaries the considerations involved in implementing an ‘extra factor’ for authentication, including the options for those factors.
- The ICO and NCSC have jointly produced[ guidance on security outcomes](https://ico.org.uk/for-organisations/security-outcomes/?ref=thedelatorrereview.com).
- The NCSC has detailed[ technical guidance](https://www.ncsc.gov.uk/guidance?ref=thedelatorrereview.com) in a number of areas. Some examples include:

[10 Steps to Cyber Security](https://www.gov.uk/government/publications/cyber-risk-management-a-board-level-responsibility/10-steps-summary?ref=thedelatorrereview.com)– The 10 Steps define and communicate an Information Risk Management Regime which can provide protection against cyber-attacks.

[The Cyber Essentials scheme](https://www.cyberessentials.ncsc.gov.uk/?ref=thedelatorrereview.com) — this provides a set of basic technical controls that you can implement to guard against common cyber threats.

[Risk management collection](https://www.ncsc.gov.uk/guidance/risk-management-collection?ref=thedelatorrereview.com) — a collection of guidance on how to assess cyber risk.

**ENISA**: [What is “state of the art” in IT security?](https://www.enisa.europa.eu/news/enisa-news/what-is-state-of-the-art-in-it-security?ref=thedelatorrereview.com)

**Other:**

- The International Working Group on Data Protection in Telecommunications (the ‘Berlin Group’) published a [Working Paper on biometrics in online authentication](https://www.datenschutz-berlin.de/fileadmin/user%5Fupload/pdf/publikationen/working-paper/2016/23112016%5Fen.pdf?ref=thedelatorrereview.com) in 2016 (PDF);
- [Guidance on cryptographic algorithms](http://www.europeanpaymentscouncil.eu/index.cfm/knowledge-bank/epc-documents/guidelines-on-cryptographic-algorithms-usage-and-key-management/epc342-08-v60-guidelines-on-cryptographic-algorithms-usage-and-key-management/?ref=thedelatorrereview.com) from the European Payments Council;
- [OWASP cheat sheet on password storage](https://www.owasp.org/index.php/Password%5FStorage%5FCheat%5FSheet?ref=thedelatorrereview.com);
- Cynosure Prime’s [analysis of 320 million leaked passwords from the HaveIBeenPwned website](https://cynosureprime.blogspot.co.uk/2017/08/320-million-hashes-exposed.html?ref=thedelatorrereview.com).
- The European Payments[ Council’s guidance on the use of cryptographic algorithms](http://www.europeanpaymentscouncil.eu/index.cfm/knowledge-bank/epc-documents/guidelines-on-cryptographic-algorithms-usage-and-key-management/epc342-08-v60-guidelines-on-cryptographic-algorithms-usage-and-key-management/?ref=thedelatorrereview.com)provides additional information if your organisation is part of this sector.
- Microsoft’s[ password guidance](http://www.microsoft.com/en-us/research/wp-content/uploads/2016/06/Microsoft%5FPassword%5FGuidance-1.pdf?ref=thedelatorrereview.com) contains advice on passwords in the context of several Microsoft platforms.
- [Analysis](https://nakedsecurity.sophos.com/2016/08/17/why-you-still-cant-trust-password-strength-meters/?ref=thedelatorrereview.com) from Sophos on password strength as well as the[ significant amount of research](http://cups.cs.cmu.edu/passwords.html?ref=thedelatorrereview.com) from Carnegie Mellon University.

The UK government has produced relevant guidance on cybersecurity:

- [CyberAware](https://www.cyberaware.gov.uk/?ref=thedelatorrereview.com) — a cross-government awareness campaign developed by the Home Office, the Department for Digital, Culture, Media and Sport (‘DCMS’) and the NCSC.
- [‘Cybersecurity — what small businesses need to know’](https://www.gov.uk/government/publications/cyber-security-what-small-businesses-need-to-know?ref=thedelatorrereview.com) — produced by DCMS and the department for Business, Enterprise, Innovation and Skills (‘BEIS’).

First two NIS Directive notifications in Spain: [https://www.garrigues.com/en\_GB/garrigues-digital/garrigues-advises-first-two-notifications-relating-cyberattacks-operators](https://www.garrigues.com/en%5FGB/garrigues-digital/garrigues-advises-first-two-notifications-relating-cyberattacks-operators?ref=thedelatorrereview.com)

EDPS:

- [TechDispatch #2/2020: Quantum Computing and Cryptography](https://edps.europa.eu/data-protection/our-work/publications/techdispatch/techdispatch-22020-quantum-computing-and%5Fen?ref=thedelatorrereview.com)

### Additional Resources (US)

**National Institute of Standards in Technology (NIST)**

NIST’s[ Special Publication 800–63 on digital identity guidelines](https://pages.nist.gov/800-63-3/sp800-63-3.html?ref=thedelatorrereview.com);

- NIST’s[ policy on hashing functions](https://csrc.nist.gov/Projects/Hash-Functions/NIST-Policy-on-Hash-Functions?ref=thedelatorrereview.com);
- Information on the status of a number of hashing functions can be found in NIST Special Publication 800–131A Revision 1 [— Transitions: Recommendations for transitioning the use of cryptographic algorithms and key lengths](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf?ref=thedelatorrereview.com) (2015).

#### **Federal Trade Commission (FTC)**

- FTC’s[ advice about the potential issues with password](https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes?ref=thedelatorrereview.com).
- FTC’s [Privacy and data security udpate 2018](https://www.ftc.gov/system/files/documents/reports/privacy-data-security-update-2018/2018-privacy-data-security-report-508.pdf?ref=thedelatorrereview.com)

#### Journals

[International Journal of Cyber-forensics and advanced thread investigations.](https://conceptechint.net/index.php/CFATI/issue/view/2?ref=thedelatorrereview.com)

#### Other

- Willkie: [Recent State data privacy laws and court decisions impose extensive obligations in companies that process personal information](https://www.willkie.com/~/media/Files/Publications/2008/10/Recent%20State%20Data%20Privacy%20Laws%20and%20Court%20Decisio%5F%5F/Files/RecentStateDataPrivacyLawspdf/FileAttachment/Recent%5FState%5FData%5FPrivacy%5FLaws.pdf?ref=thedelatorrereview.com)
- [The Jeff Bezos hack could happen to anyone](https://www.vox.com/recode/2020/1/22/21077747/jeff-bezos-whatsapp-hack-saudi-prince-mohammed-bin-salman?ref=thedelatorrereview.com) article by Sara Morrison for Recode Jan. 2020

![](https://storage.ghost.io/c/54/ef/54efeb65-4f2f-479e-b4bb-a9ee526feeaa/content/images/2026/08/Screenshot-2026-07-04-at-4.45.19---PM-1.png)