Skip to main content
Privacy Track
Category: Security & Breach Notification

Technical Measures

Also known as: Technical safeguards, Technical controls
Simply put

Technical measures are the technology-based safeguards an organisation puts in place to protect personal data, such as security software, access controls, and secure storage. They are commonly discussed alongside organisational measures (the policies and procedures side) as part of a broader set often called 'technical and organisational measures'. Together they aim to keep personal data secure, though what is appropriate depends on the specific risks and context.

Formal definition

Technical measures are the system-, network-, and device-level controls implemented to protect personal data, typically encompassing information security features, secure data collection and storage, and protective software such as antivirus and access controls. In the GDPR context they form one half of the concept of 'technical and organisational measures' (TOMs), with organisational measures addressing governance, policy, and process. The specific measures considered appropriate are not fixed by a prescribed checklist but are assessed against the risk to individuals, the state of the art, implementation costs, and the nature, scope, context, and purposes of processing; readers should verify the applicable GDPR provisions and current regulatory guidance, as the required standard is risk-dependent and evolves. The term is distinct from unrelated technical-measurement concepts (for example, technical performance measurement or copyright-related standard technical measures) that appear under similar names in other fields.

Why it matters

Technical measures sit at the heart of the GDPR's security obligations, which generally require controllers and processors to implement appropriate safeguards to protect personal data. Because the Regulation does not prescribe a fixed checklist, technical measures matter precisely because they must be tailored: the same encryption or access-control approach that is adequate for low-risk processing may fall short where the risk to individuals is higher. Getting this balance wrong exposes organisations to regulatory scrutiny, and inadequate technical safeguards are frequently a contributing factor in the security incidents that draw enforcement attention.

The standard is deliberately risk-dependent. Regulators typically expect organisations to weigh factors such as the state of the art, the cost of implementation, and the nature, scope, context, and purposes of the processing against the likelihood and severity of risk to individuals. This means technical measures are not a one-time procurement exercise but an ongoing assessment that should be revisited as threats, technologies, and processing activities change. What is considered adequate today may be viewed as insufficient later as the state of the art advances.

Technical measures are also rarely sufficient on their own. They are commonly framed as one half of 'technical and organisational measures' (TOMs), and technology controls generally need to be supported by governance, policies, and processes to be effective. Readers should treat any list of controls as illustrative rather than definitive, and verify the applicable GDPR provisions and current regulatory guidance, since the required standard evolves.

Who it's relevant to

Data protection officers and compliance leads
DPOs and compliance teams generally need to confirm that technical measures are proportionate to the assessed risk and documented as part of the organisation's broader technical and organisational measures. Because the required standard is risk-dependent rather than a fixed checklist, they should periodically reassess whether existing controls remain appropriate against the state of the art and the current processing activities.
Engineers and security teams
Those implementing and maintaining systems are typically responsible for the practical controls, such as access controls, protective software, and secure storage, that address system-, network-, and device-level vulnerabilities. Their work should be informed by the risk assessment so that the technical safeguards deployed match the sensitivity and context of the personal data being processed.
Privacy and data protection lawyers
Legal advisers often assess whether an organisation's technical measures meet the applicable GDPR security standard and are correctly distinguished from organisational measures. They should note that the standard is qualitative and evolving, that no set of controls guarantees compliance, and that the precise obligations and any national variations should be verified against the current official text and guidance.
Controllers and processors managing vendor relationships
Where processing is outsourced, both parties typically need clarity on the technical measures in place, since these are commonly documented alongside the contractual arrangements governing processing. Reliance on a vendor's 'industry standard' security features should be evaluated against the specific risk to individuals rather than assumed to be sufficient by default.

Inside Technical Measures

Pseudonymisation
A processing technique, expressly referenced in the GDPR, by which personal data can no longer be attributed to a specific individual without the use of separately held additional information. It reduces risk but does not render data anonymous, so pseudonymised data generally remains personal data within scope of the Regulation.
Encryption
The transformation of data into a form unreadable without a decryption key, applied to data at rest and in transit. It is commonly cited among the measures that may be appropriate to secure personal data, though its adequacy depends on the specific risk assessment and implementation.
Access controls and authentication
Mechanisms that restrict who can access personal data, typically including role-based permissions, multi-factor authentication, and the principle of least privilege. These support the security of processing but form only part of a broader measures set.
Resilience, availability and recovery capability
Measures intended to maintain confidentiality, integrity, availability and resilience of processing systems, and to restore access to personal data in a timely manner following an incident. What is 'timely' or 'appropriate' is assessed against the risk to individuals.
Testing and evaluation
A process for regularly testing, assessing and evaluating the effectiveness of the technical measures in place. This reflects that security is an ongoing obligation rather than a one-time configuration.
Relationship to organisational measures
Technical measures generally sit alongside organisational measures (such as policies, training and governance) and are typically addressed together as 'technical and organisational measures'. Technical controls alone are rarely sufficient on their own.

Common questions

Answers to the questions practitioners most commonly ask about Technical Measures.

Are technical measures the same thing as security controls like encryption and firewalls?
Not exactly. Technical measures do include controls such as encryption, pseudonymisation, access controls, and network protections, but they are only one half of the phrase 'technical and organisational measures' (often abbreviated TOMs) referenced in the GDPR's security provisions. Technical measures generally concern the technology and system-level safeguards, while organisational measures address policies, governance, training, and processes. Both are typically required together, and technical measures alone are usually not sufficient to demonstrate appropriate security. The specific measures that are 'appropriate' depend on the state of the art, costs, and the nature, scope, context, and risk of the processing, so there is no fixed checklist.
Does implementing strong technical measures mean my organisation is compliant with the GDPR?
No. Technical measures address the security and data-protection-by-design dimensions of compliance, but compliance is broader and context dependent. You still need a valid legal basis, transparency, respect for data subject rights, lawful transfer mechanisms where relevant, and appropriate organisational measures, among other requirements. Strong technical measures can support an accountability posture but do not by themselves make processing lawful or fully compliant. Compliance is assessed against the whole of the applicable framework and the specific risks involved.
How do we decide which technical measures are 'appropriate' for a given processing activity?
Appropriateness is generally determined through a risk-based assessment that weighs the state of the art, implementation costs, and the nature, scope, context, and purposes of the processing against the likelihood and severity of risks to individuals. Higher-risk processing typically calls for more robust measures. Where a Data Protection Impact Assessment is conducted, its findings often inform the selection of technical measures. There is no single mandated set of controls, so document your reasoning to support accountability, and be aware that regulator expectations and guidance can evolve.
Should technical measures be built in from the start of a project?
Generally, yes. The principle often described as data protection by design and by default supports embedding technical measures into systems and processes at the design stage rather than retrofitting them later. In practice this can mean considering pseudonymisation, data minimisation, and access restrictions early in system architecture. The specific measures remain subject to assessment based on the risk and context of the processing, and the design choices should be documented.
Do technical measures need to be reviewed after they are implemented?
In most cases, technical measures should be treated as ongoing rather than a one-time exercise. Because appropriateness references the state of the art and the evolving risk landscape, measures typically need periodic review, testing, and updating to remain effective. Regularly evaluating the effectiveness of measures is generally considered part of maintaining an appropriate security posture. The frequency and depth of review will depend on the risk profile of the processing.
How should technical measures be documented for accountability purposes?
Technical measures are typically documented to demonstrate the accountability expected under the GDPR, showing not only which controls are in place but the reasoning behind their selection relative to the assessed risk. Documentation may be reflected in records of processing activities, security policies, and any Data Protection Impact Assessment where one applies. It is generally advisable to record how measures were chosen, tested, and reviewed, so the organisation can evidence its decisions if questioned. Verify documentation expectations against current official guidance, as regulator emphasis can differ.

Common misconceptions

Encrypting personal data makes it anonymous and takes it outside the scope of the GDPR.
Encryption is a security measure, not anonymisation. Where the data can still be attributed to an individual by anyone holding the key or additional information, it generally remains personal data and stays within scope. This distinction can be nuanced and readers should assess it case by case.
Pseudonymisation and anonymisation are the same thing.
They are distinct. Pseudonymised data can be re-linked to an individual using separately held information and generally remains personal data, whereas genuinely anonymous data falls outside the GDPR. The threshold for true anonymisation is high and subject to assessment.
Implementing a fixed checklist of technical measures guarantees compliance.
The Regulation frames measures as 'appropriate' to the risk, taking account of factors such as the state of the art, costs, and the nature and severity of risk to individuals. What is appropriate is context-dependent, may vary between organisations, and is expected to be reviewed and tested over time rather than treated as permanently sufficient.

Best practices

Select and document technical measures based on a risk assessment proportionate to the nature, scope, context and purposes of the processing, rather than adopting a generic checklist.
Treat technical measures as complementary to organisational measures, and address both together when documenting security of processing.
Apply pseudonymisation and encryption where appropriate, while recording that pseudonymised and encrypted data generally remain personal data and continue to be in scope.
Implement access controls following the principle of least privilege, and use strong authentication proportionate to the sensitivity of the data.
Regularly test, assess and evaluate the effectiveness of measures, and update them to reflect changes in risk, technology and the state of the art.
Maintain documentation of the measures chosen and the reasoning behind them, and verify specific requirements against the current official text of the applicable law and relevant regulator guidance.