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

Appropriate Technical and Organisational Measures

Also known as: TOMs, Technical and Organisational Measures, Appropriate TOMs, Security measures (Article 32)
Simply put

Appropriate technical and organisational measures are the safeguards an organisation puts in place to keep personal data secure and to show it is complying with data protection law. 'Technical' measures typically cover things like IT systems and controls, while 'organisational' measures cover things like internal policies, procedures, and staff arrangements. What counts as 'appropriate' depends on the risk involved, so there is no single fixed checklist that applies to every organisation.

Formal definition

Under the GDPR and UK GDPR, both controllers and processors are required to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk (Article 32). The concept is risk-based rather than prescriptive: 'appropriate' generally means the measures should be calibrated to the nature, scope, context, and risks of the processing, as well as to the organisation's capacity to mitigate those risks. The requirement also operates within the broader accountability framework, where controllers are expected to adopt internal policies and implement measures demonstrating compliance (as reflected in Recital 78). Because the standard is context-dependent and assessed against evolving risk, no static set of controls guarantees compliance, and the specific measures considered adequate may vary and should be evaluated case by case and against current regulatory guidance. Article numbers and recital references should be verified against the current official text, and readers should note that the UK GDPR position may diverge from the EU GDPR over time.

Why it matters

Appropriate technical and organisational measures sit at the heart of the GDPR's security obligation. Under Article 32, both controllers and processors are required to ensure a level of security appropriate to the risk, and failure to do so is one of the most common triggers for regulatory scrutiny following a personal data breach. Because the obligation is framed around risk rather than a fixed list of controls, organisations cannot simply point to a certificate or a single tool and treat the matter as settled; they are expected to be able to justify why the measures chosen are appropriate to the specific processing.

The concept is also tied to the broader accountability framework. As reflected in Recital 78, controllers are expected to adopt internal policies and implement measures that demonstrate compliance, meaning TOMs are not only a defensive security requirement but also part of how an organisation shows it takes its obligations seriously. This dual function, protecting data and evidencing compliance, makes TOMs relevant both to day-to-day operations and to how an organisation would respond to a regulator's questions.

Because the standard is context-dependent and assessed against evolving risk, what is considered adequate can change over time and may be judged differently by different regulators. There is no static set of controls that guarantees compliance, and the specific measures expected should be evaluated case by case and against current regulatory guidance. Readers should verify the relevant article and recital references against the current official text and note that the UK GDPR position may diverge from the EU GDPR over time.

Who it's relevant to

Data Protection Officers and Compliance Leads
DPOs and compliance teams typically own the process of assessing risk and documenting why chosen measures are appropriate. Because TOMs form part of the accountability framework, they are central to demonstrating compliance to regulators and to internal governance, and should be reviewed against current guidance rather than treated as fixed.
Controllers
Controllers bear the primary responsibility for ensuring a level of security appropriate to the risk and, as reflected in Recital 78, for adopting internal policies and measures that demonstrate compliance. They generally need to justify their choices by reference to the nature, scope, context, and risks of their processing.
Processors
Processors are also directly subject to the Article 32 obligation to implement appropriate technical and organisational measures. Their security arrangements are often addressed contractually with controllers, but the underlying requirement applies to them in their own right.
Engineers and IT/Security Teams
Technical teams typically implement the 'technical' side of TOMs, such as system controls and safeguards, and support the organisational measures where they intersect with systems. Because 'appropriate' is risk-based, engineering choices should be tied to a documented risk assessment rather than to a standalone checklist.
Legal and Contracting Teams
Lawyers and contract managers frequently allocate security responsibilities between controllers and processors and describe TOMs in agreements. They should be mindful that the standard is context-dependent, may vary between the EU GDPR and UK GDPR over time, and should be verified against current official text and guidance.

Inside TOMs

Technical measures
Safeguards implemented within systems and infrastructure, such as pseudonymisation, encryption of personal data, access controls, and measures ensuring the ongoing confidentiality, integrity, availability, and resilience of processing systems and services. The specific measures appropriate in any case depend on assessment.
Organisational measures
Governance and process-based safeguards, such as internal policies, staff training, role-based access management, vendor oversight, and procedures for restoring availability and access to personal data in a timely manner following a physical or technical incident.
Risk-based calibration
The Regulation frames appropriateness by reference to the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing, weighed against the varying likelihood and severity of risk to the rights and freedoms of individuals. There is generally no fixed checklist; measures are calibrated to the assessed risk.
Regular testing and evaluation
A process for regularly testing, assessing, and evaluating the effectiveness of the measures adopted. This treats security as an ongoing obligation rather than a one-time configuration, subject to review as risks and the state of the art evolve.
Applicability to controllers and processors
The obligation to implement appropriate technical and organisational measures applies to both controllers and processors, though the precise responsibilities differ according to role and should be reflected in the arrangements between them.

Common questions

Answers to the questions practitioners most commonly ask about TOMs.

Is encryption always required to satisfy 'appropriate technical and organisational measures'?
No. Encryption is named in the GDPR as an example of a measure that may be appropriate, but it is not a universal mandate. The standard is risk-based and context-dependent: the appropriate measures depend on factors such as the state of the art, costs of implementation, the nature, scope, context and purposes of processing, and the risks to individuals. Encryption is frequently useful and often expected in higher-risk scenarios, but the assessment turns on whether it is appropriate for the specific processing rather than on any blanket requirement.
Does having a documented security policy mean an organisation is fully compliant with this obligation?
Not on its own. A written policy is evidence of intent but does not by itself demonstrate that measures are appropriate or effective in practice. Compliance is context and risk dependent and generally requires that measures are actually implemented, tested, and kept under review, and that they respond to the specific risks presented by the processing. Documentation supports the accountability principle, but a policy that is not operationalised or reviewed may fall short of the standard.
How does an organisation decide which measures are 'appropriate' for a given processing activity?
The assessment is typically a proportionality exercise weighing the risks to individuals against factors such as the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing. In practice organisations often document a risk assessment identifying the likelihood and severity of harm, then select and justify measures proportionate to that risk. Where processing is likely to result in high risk, a more formal assessment process may be indicated. Because what is appropriate evolves with technology and threats, the reasoning should be recorded and revisited.
How should the effectiveness of these measures be tested and reviewed over time?
The GDPR contemplates a process for regularly testing, assessing and evaluating the effectiveness of measures. In practice this can involve activities such as periodic reviews, testing of controls, and reassessment following material changes to processing, systems, or the threat landscape. Because the standard references the state of the art, measures that were appropriate at one point may need to be updated. The frequency and depth of review generally scale with the level of risk, and organisations should be prepared to demonstrate that review actually takes place.
How do these obligations apply between a controller and a processor?
Both controllers and processors have obligations to implement appropriate technical and organisational measures. Where a controller engages a processor, the arrangement is typically governed by a contract or other legal act (commonly a data processing agreement under Article 28) that addresses the security measures the processor must implement. Controllers are generally expected to use processors that provide sufficient guarantees regarding appropriate measures. The specific allocation of responsibilities should be verified against the terms of the engagement and the applicable provisions.
What is the relationship between these measures and personal data breach obligations?
The measures are relevant both before and after an incident. Robust measures aim to reduce the likelihood and impact of a personal data breach, and the presence or absence of appropriate measures can be relevant to how a breach and any resulting risk to individuals are assessed. Certain measures may affect whether particular notification or communication steps are triggered, subject to assessment of the specific facts. Breach handling has its own distinct requirements, so organisations should treat these obligations as related but separate and verify the applicable provisions.

Common misconceptions

Appropriate technical and organisational measures mean a specific, mandated set of security controls that apply uniformly to every organisation.
The standard is generally risk-based and contextual rather than a prescriptive checklist. What is appropriate depends on factors such as the state of the art, cost, the nature and purposes of processing, and the likelihood and severity of risk to individuals, so measures adequate for one organisation may not suffice for another.
Encryption or another single measure, once in place, satisfies the requirement permanently.
Encryption is one example of a possible measure, not a guaranteed solution, and no single control makes processing fully compliant in all cases. The obligation typically includes regularly testing, assessing, and evaluating effectiveness, and measures may need to be updated as risks and the state of the art change.
Only technical, IT-focused controls are needed to meet the standard.
The term expressly covers both technical and organisational measures. Governance elements such as policies, training, and oversight of processors are typically as important as technical safeguards, and the appropriate balance is subject to assessment.

Best practices

Conduct and document a risk assessment that considers the nature, scope, context, and purposes of processing alongside the likelihood and severity of risk to individuals, and use it to justify the measures selected.
Treat security as an ongoing obligation by scheduling regular testing, assessment, and evaluation of the effectiveness of implemented measures, and revisiting them as risks and the state of the art evolve.
Combine technical safeguards (such as access controls, pseudonymisation, or encryption where appropriate) with organisational safeguards (such as policies, staff training, and processor oversight) rather than relying on either alone.
Clearly allocate responsibilities between controllers and processors, reflecting each party's role in the relevant contractual arrangements, and verify that processors implement their own appropriate measures.
Maintain records of the measures adopted and the reasoning behind them, so the appropriateness of choices can be demonstrated and reviewed.
Verify specific technical, organisational, and legal requirements against the current official text and applicable regulatory guidance, since positions can vary and evolve.