Article 32 GDPR: documenting security measures clearly

Technical and organisational measures under Article 32 GDPR are not a one-off IT document. Organisations must be able to show which risks they identified for their actual processing activities, which safeguards address those risks and when effectiveness was last tested. A list saying “firewall, backup and password rules” is usually not enough.

This article explains how controllers and processors can document security measures so that the link between processing, risk, safeguard, responsibility and evidence remains clear. The focus is not an abstract security catalogue, but whether the measures are appropriate for the specific organisation and can be tested in practice.

Article 32 GDPR requires a level of security appropriate to the risk. The choice of safeguards must take account of the state of the art, implementation costs, and the nature, scope, context and purposes of processing. The likelihood and severity of risks to the rights and freedoms of individuals also matter. The provision therefore does not impose one identical checklist on every organisation.

Article 32(1) GDPR refers, among other things, to pseudonymisation and encryption, the continuing confidentiality, integrity, availability and resilience of systems and services, and the ability to restore availability in a timely manner after an incident. It also requires regular testing, assessment and evaluation of effectiveness. The record should make this connection between selection and ongoing control visible.

Article 5(2) GDPR is important for accountability. A controller must not only comply with the GDPR, but also be able to demonstrate compliance. Article 24 GDPR requires appropriate measures and their review and updating where necessary. Documentation is therefore not an administrative end in itself. It shows how the organisation exercises its responsibility.

A security record starts with the processing activity, not the product in use. First ask which data are processed, who can access them, where they are transferred and what a loss, alteration or unauthorised disclosure could cause. Health data, credentials, personnel files or large customer datasets may require a different level of protection than a simple public contact list.

Risk cannot be dismissed by calling a process “standard”. Consider the number of individuals, the duration of possible access, dependence on a single system, the ability to restore data and the ability to detect an incident quickly. Processing with a high protection need requires correspondingly robust measures and evidence.

Record assumptions and residual risks as well. If a safeguard cannot be fully implemented immediately for technical or economic reasons, the record should show which alternative was selected, why it appears proportionate for the interim period and when the situation will be reassessed. That turns an assertion into a reasoned decision.

A useful record does not have to be one single document. In practice, the records of processing activities, policies, access concepts, provider documents, test protocols and training evidence may be linked. What matters is that a reviewer can understand the connection without an extensive search.

For each important activity, record at least the purpose and data categories, affected groups, systems and providers, access roles, protection needs, material risks, assigned safeguards, responsible persons and available evidence. Add implementation status, known exceptions, the date of the last review and the next control date.

The measures themselves must be described with enough precision. “Access protection exists” says very little. A more useful record explains which role may access which data, how access is granted and withdrawn, how privileged access is logged and when permissions are reviewed. Technical detail can be placed in an annex if the main record points to it clearly.

Article 32 GDPR requires more than selecting suitable measures. Organisations must regularly test, assess and evaluate their effectiveness. The interval depends on risk and the speed of change. An unchanged low-risk system needs a different testing plan from a cloud processing operation with many external users and frequent releases.

A test record should identify the measure, scope, method, date, responsible person, result and deviations. Examples include a backup restoration test, user-rights review, controlled phishing exercise, patch and vulnerability report, encryption check or an exercise for responding to a security incident.

A negative result is not by itself proof of non-compliance if the organisation deals with it properly. Deviations should be assessed, prioritised and assigned to an owner with a realistic date. A follow-up test should show whether the problem was actually fixed. The record need not contain every technical detail, but it must not hide the decisive result.

The controller remains responsible for selecting and reviewing appropriate measures. Where a processor carries out processing, the Article 28(3)(c) GDPR contract must also reflect the duty to implement suitable technical and organisational measures. A controller should therefore not rely on the provider simply saying that it is “certified” or has a security badge.

Check which evidence the provider actually supplies, where the processing takes place, how sub-processors are involved and how incidents are reported. Article 28(3)(h) GDPR provides for information needed to demonstrate compliance and for audits or inspections. Those rights must also be practical in day-to-day operations.

Clear internal roles are helpful. IT may perform technical controls, privacy coordination may support the risk assessment and documentation logic, and management may decide on material residual risks and priorities. Responsibility does not mean that one person performs every task. It must be clear who prepares, approves, tests and follows up each decision. The overview of processors and service providers provides further context.

A security record often becomes outdated through change rather than on a fixed date. A new CRM, a different cloud provider, additional remote access, a new interface or a changed retention period can alter the risk assessment. Set a simple change process: who reports the change, who assesses it, which documents are updated and when the measure is tested.

Security incidents show whether the documented measures work in practice. After an incident, do not address only the immediate cause. Also ask whether the risk assessment was accurate, whether alerts worked, whether responsibilities functioned and whether recovery was possible. The overview of data breaches and notification duties explains the further assessment after a personal data breach.

Keep earlier decisions traceable when the record is updated. Version, reason for change, approval and effectiveness of the change belong in a clear history. This allows the organisation to explain how it learned from a test or incident without rewriting the complete record in an unstructured way.

A pure product list is a common mistake. Names of software, firewalls or cloud services do not show whether the relevant risk is reduced appropriately. A general policy is also weak evidence if no one checks whether it is followed. The record should always show a concrete processing activity and a verifiable control path.

Unmaintained access lists, untested backups and test protocols without results create similar problems. A backup that has never been restored proves the ability to restore data only to a limited extent. A training policy without attendance or update evidence does not show that it has reached the organisation in practice.

Avoid rigid promises as well. Article 32 GDPR requires proportionality and regular review, not an assertion that every risk is excluded. State honestly which risk a measure reduces, which limits remain and how residual risk is treated. That is more reliable and makes later decisions easier.

A first reliable structure can be a manageable working table. Select the key processing activities, describe their protection needs and map the existing measures. Do not mark gaps as completed. Assign an owner and a next date instead. Then check whether an independent reader can understand the evidence.

Start with processing that could cause serious consequences after an incident or that depends on many people and providers. Then compare internal policies, contracts and technical controls. Contradictions between documents are often more useful than another general security statement because they identify concrete work to do.

An annual basic check is not always enough for ongoing maintenance. Add event-driven reviews when systems, providers, incidents or material processing details change. The page on privacy governance and compliance places these tasks in organisational responsibility. The role check can help structure the initial allocation.