Security measures checklist (TOMs)
Art. 32 GDPR requires technical and organisational measures appropriate to the risk of the processing — plus a process that regularly tests whether they actually work. This checklist walks the protection goals of the article, from encryption through confidentiality to restorability, and shows you where the largest gaps sit. It does not replace a risk assessment, but it gives your own measures documentation a defensible structure.
No signup · runs in your browser · nothing you enter is transmitted
Art. 32(1)(a) GDPR — named expressly as an example measure.
Art. 32(1)(b) GDPR — physical access, system access, data access and separation.
Art. 32(1)(b) GDPR — protection against unauthorised alteration, and traceability.
Art. 32(1)(b) GDPR — systems have to withstand disruption and attack on an ongoing basis.
Art. 32(1)(c) GDPR — availability and access must be restored in a timely manner after an incident.
Art. 32(1)(d) GDPR — requires a process, not a one-off stocktake.
Obligations that sit alongside Art. 32 and without which the technical measures do not hold.
Not proof of conformity
Art. 32(1) GDPR does not require a maximum of measures but a level of security appropriate to the risk — weighing 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 risk. 100 % on this list can be too little for health or employee data, while a plain contact form needs considerably less. The percentage only describes how much of this list you have ticked.
Gaps by protection goal
Sorted by open items — the largest need for action sits at the top.
Next steps
Your open items, in the order of Art. 32(1) GDPR.
- Pseudonymisation and encryption: Encryption in transit
- Pseudonymisation and encryption: Encryption at rest
- Pseudonymisation and encryption: Full-disk encryption on endpoints
- Pseudonymisation and encryption: Managed key handling
- Pseudonymisation and encryption: Pseudonymisation in test and analytics environments
- Confidentiality: Physical access control
- Confidentiality: Individual system accounts
- Confidentiality: Multi-factor authentication
- Confidentiality: Password policy and password manager
- Confidentiality: Access control on a documented authorisation concept
… and 26 more open measures on this list
Then document it
Measures only count if you can evidence them: described in general terms in the record of processing activities under Art. 30(1)(g) GDPR, set out in full in a standalone measures document for the accountability duty in Art. 5(2) GDPR, and annexed to every data processing agreement, because Art. 28(3)(c) GDPR binds the processor to all measures required by Art. 32. A list that is never reviewed goes stale — and is then a defect in itself.
Art. 32(1) GDPR obliges controllers and processors alike to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. What is appropriate follows from the state of the art, the costs of implementation, the nature, scope, context and purposes of the processing, and the risk of varying likelihood and severity for the rights and freedoms of natural persons. The article lists as examples the pseudonymisation and encryption of personal data (point a), the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services (point b), the ability to restore availability and access in a timely manner after an incident (point c), and a process for regularly testing, assessing and evaluating the effectiveness of the measures (point d). Under Art. 32(2) the assessment must in particular account for the risks of destruction, loss, alteration, unauthorised disclosure of, or access to personal data; infringements of Art. 32 can be fined up to EUR 10 million or 2 % of total worldwide annual turnover under Art. 83(4)(a) GDPR.
Orientation only — not legal advice. This list is a cross-industry suggestion, not a statutory catalogue: Art. 32 GDPR requires measures appropriate to the specific risk of your processing, so depending on the case individual items may be dispensable and others may be additionally required. The completion rate shown is therefore expressly not proof of conformity and replaces neither a risk assessment nor a case-by-case review. Your entries stay in your browser and are neither stored nor transmitted.
Frequently asked
- What are technical and organisational measures?
- Technical measures act on the system, the device or the building — encryption, physical access control, logging, backups. Organisational measures act on people and processes — authorisation concepts, training, confidentiality undertakings, contingency and deletion concepts. Art. 32(1) GDPR requires both together and gives as examples pseudonymisation and encryption, the ongoing assurance of confidentiality, integrity, availability and resilience, the ability to restore access in a timely manner after an incident, and a process for regularly testing effectiveness.
- Is there a statutory list of mandatory measures?
- No. Art. 32(1) GDPR introduces its examples expressly as measures included "inter alia as appropriate". What governs is a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the varying likelihood and severity of the risk. A medical practice handling health data therefore needs different measures than a trade business holding plain customer records — and no percentage on a checklist can substitute for that balancing exercise.
- Where do the measures have to be documented?
- In two places. The record of processing activities must contain, under Art. 30(1)(g) GDPR and where possible, a general description of the measures referred to in Art. 32(1). Separately, the accountability principle in Art. 5(2) read with Art. 24(1) GDPR requires you to be able to demonstrate the measures you took and why you chose them, which is normally done in a fuller standalone measures document that the record cross-references. Undocumented measures effectively do not exist as far as a supervisory authority is concerned.
- Why are the measures an annex to a data processing agreement?
- Because under Art. 28(1) GDPR a controller may only use processors providing sufficient guarantees of appropriate technical and organisational measures, and the contract must bind the processor to take all measures required pursuant to Art. 32 under Art. 28(3)(c) GDPR. In practice this is implemented by making the processor's measures an annex to the contract — that is the only way what it committed to can be checked at all. If the provider materially changes its measures, the annex has to be updated accordingly.
- How often do the measures have to be reviewed?
- Art. 32(1)(d) GDPR requires a process for regularly testing, assessing and evaluating the effectiveness of the measures, but names no fixed interval. In practice an annual review plus an event-driven review on new systems, material process changes or after a security incident has become the norm. A measures list written once and never touched again is not evidence but a defect in itself — it describes the systems you once had, not the ones you run.
- What does "state of the art" mean?
- A moving target: what has proven effective in practice and is available on the market — more than the generally accepted rules of technology, less than the state of scientific research. Useful reference points are the BSI IT-Grundschutz methodology, ISO/IEC 27001 with its control set in Annex A, and the TeleTrusT guidance on the state of the art. Because the benchmark shifts, a measure that is adequate today may be insufficient in two years — think outdated TLS versions or cipher suites that have since been considered broken.