GDPR Article 32 requires both controllers and processors to implement appropriate technical and organisational measures that provide security appropriate to the risk. It does not prescribe the same encryption cipher, log-retention period or test calendar for every organisation. The official Regulation instead asks decision-makers to consider the state of the art, implementation cost, the nature, scope, context and purposes of processing, and risks of varying likelihood and severity to people’s rights and freedoms. Security must be chosen for the processing that actually occurs, then maintained and evaluated.
The four examples in Article 32(1) are pseudonymisation and encryption; ongoing confidentiality, integrity, availability and resilience; timely restoration of availability and access after a physical or technical incident; and a process to test, assess and evaluate effectiveness regularly. The European Commission’s obligations guide and the CNIL’s 2024 personal-data security guide explain the risk-based approach. The CNIL guide is practical authority guidance, not an EU-wide fixed checklist.
Identify the harm before choosing a control
Begin with the personal data and the people affected. Could unauthorised access expose medical details, financial credentials or employee allegations? Could alteration produce a wrong decision? Could an outage deny timely access to information needed for care or essential services? Article 32(2) explicitly highlights risks from accidental or unlawful destruction, loss, alteration, unauthorised disclosure and access. A risk assessment should cover these outcomes and the ways they could occur, including staff error, compromised accounts, unreliable backups, supplier access and physical loss.
The same control may have different value in different settings. A customer newsletter list and an emergency care system both contain personal data, but loss of availability has different consequences. A small business may have modest infrastructure and a large supplier may have complex systems; neither size alone determines the answer. Write down the likely scenarios, existing measures, their limitations and who owns the remaining risk. Reassess when the dataset, service, supplier or threat changes. The DPIA guide explains the separate Article 35 trigger for processing likely to result in high risk; not every Article 32 assessment is a full DPIA.
Avoid the false binary that a breach proves security was inadequate and no breach proves compliance. A well-run system can suffer a sophisticated incident; a system with poor controls may remain undiscovered for years. An authority examines the measures that were appropriate at the relevant time, not simply the outcome. Keep the design rationale, configurations, risk decisions and test results so that an independent reviewer can understand what protection actually existed.
Protect confidentiality without losing sight of integrity and availability
Confidentiality concerns who can see data. Access controls, authentication, encryption, separation of duties and supplier restrictions can help. Integrity concerns whether records are accurate and resistant to unauthorised or accidental changes; change logs, validation and controlled recovery can help. Availability concerns whether authorised people can use data when needed; backups, capacity planning and restoration procedures can help. Resilience concerns whether a processing service can continue or recover under stress. Select measures for all relevant harms, not only for external theft.
For example, consider a small payroll provider. It may restrict payroll files to named staff, require strong authentication for remote access, encrypt stored files, log exports and review access after role changes. It also needs a way to detect altered bank details and restore a correct version after error or attack. The exact technology and frequency of review depend on its architecture, workload and risk. A cloud supplier’s certificate may support due diligence, but it does not show how the provider’s own employee roles are configured.
The Article 25 design guide can help decide what data and access exist by default. Article 32 then asks whether the remaining processing is secured. Minimising collection can reduce harm but does not replace security; encrypting a record does not justify an excessive collection purpose. The ROPA guide can connect a processing activity to its systems and general safeguards, without requiring a duplicate technical manual in every record.
Decide where encryption and pseudonymisation help
Article 32 names encryption and pseudonymisation as measures that may be appropriate. Encryption can protect data at rest, in transit or in backup, but the result depends on where keys are stored, who can decrypt, and whether data is exposed while in use. An encrypted laptop with its key written beside it offers a different protection level from one whose key is independently controlled. Protecting a database at rest does not prevent an authenticated account from exporting plaintext. Choose controls that address the actual route of compromise.
Pseudonymisation under Article 4(5) reduces attribution by separating additional information needed to identify a person and protecting that information. It is not anonymisation: if the controller can reconnect an identifier, the pseudonymised information remains personal data. A research team might replace names with coded identifiers in its working dataset and keep the mapping under limited access. That can reduce exposure if the working copy leaks, but only when the mapping is genuinely separated and staff do not reintroduce direct identifiers through free-text notes.
For highly sensitive records, strong encryption may be an important measure, yet Article 32 does not state “AES-256 at rest is mandatory for every health record.” Assess the applicable processing, contemporary options and other controls. Record why encryption was implemented, unavailable or supplemented, and revisit the choice when technology or threat changes. The special-category guide covers the separate legal condition for processing sensitive categories; an Article 9 basis does not dispense with Article 32 security.
Make access control a lifecycle decision
Assign access according to tasks. A role called “manager” is not evidence of least privilege if it can download every customer file. Check onboarding, role changes, contractor accounts, emergency access and departure. Restrict service accounts and integration tokens as well as human users. Give a process owner a way to review who can see or export their records and to correct access promptly. For a larger system, use logs that can show unusual access; for a smaller system, a disciplined account and permission review may address a material part of the risk.
Article 32(4) requires both controller and processor to take steps so that natural persons acting under their authority with access to personal data process it only on their instructions, unless Union or Member State law requires otherwise. Give staff clear, usable instructions and appropriate training, supported by technical permissions. Do not tell staff they may never access data for an urgent task if the lawful workflow requires it; design a controlled emergency path instead. An instruction does not transfer the organisation’s accountability to an employee or erase the need to monitor how the system behaves.
If a supplier handles data, the Article 28 agreement guide helps define instructions and obligations. Article 32 applies to the processor in its own right. Ask which entity runs the infrastructure, who can administer the tenant, whether sub-processors have access and how security incidents are escalated. Review evidence for the service and processing at issue. A certificate for the supplier’s corporate office or a different product is not conclusive evidence for this deployment.
Clarify security work across controller and processor
A controller needs to know which measures it configures and which the processor operates. In a hosted service, the provider might manage data-centre access, infrastructure patching and backups, while the customer manages user roles, account recovery and what information its staff upload. A contract that says only “industry-standard security” does not answer whether either party can detect an unauthorised export or restore the right tenant after an outage. List the boundary by function, evidence owner and incident contact. The controller-versus-processor guide helps identify the roles before allocating tasks.
Review shared controls at the interface. A provider may offer multifactor authentication that the customer has not enabled; the customer may expect audit logs that its purchased plan does not retain. Inspect the actual tenant and written service scope. Agree how the processor will notify the controller without undue delay if it becomes aware of a personal data breach, while leaving the controller to assess its own Article 33 notification duty. If the service changes, repeat the allocation. A contract signed at purchase does not prove the current allocation remains accurate.
Plan restoration before an incident
Article 32(1)© expressly mentions the ability to restore availability and access to personal data in a timely manner after a physical or technical incident. A backup is useful only if the organisation can recover the right data within a time appropriate to the harm of being without it. Identify critical records, dependencies, backup locations, access to recovery keys and the order in which services must return. A restore procedure that depends on the same compromised account or network may fail at the moment it is needed.
Test a restoration, not merely the presence of backup files. Use a representative dataset, verify that recovered records are complete and readable, and check whether recent lawful corrections or deletions are respected. Record recovery time and unresolved gaps. The interval between tests should reflect the service’s change rate and risk; Article 32 does not mandate a universal monthly test or thirty-day backup retention. Backup retention itself needs a purpose and access rule. An old copy can create exposure if it contains personal data that should no longer be readily accessible.
An incident response plan should connect containment to the Article 33 authority-notification decision. The fact of an incident does not automatically require notification, and a successful restore does not automatically remove risk to people. Preserve evidence that helps determine what data was compromised, when the controller became aware and what harms are plausible. The breach-handling guide shows how to coordinate that work without confusing system repair with legal assessment.
Test whether measures work in the real service
Article 32(1)(d) calls for a process of regular testing, assessment and evaluation of effectiveness. A single prelaunch approval is insufficient if settings, users and threats change. Select a mix of checks that matches the risks: restore a backup, sample access rights, inspect whether a former employee’s account is disabled, verify that an exposed endpoint requires authentication, review supplier evidence, or commission a focused security assessment. A penetration test can be useful, but the Regulation does not prescribe annual penetration testing for every controller.
Define what success looks like before each test. “MFA enabled” is weaker than demonstrating that every privileged path, including emergency and API access, is covered or has an assessed exception. “Logs retained” is weaker than showing that staff can identify a relevant export and that the log is protected from alteration. “Patching policy exists” is weaker than evidence that supported systems receive fixes within a risk-appropriate time. Record findings, owner, due date, remediation and retest. The CNIL’s 2024 guide provides practical topics for such a review and should be applied to the specific system, not copied into an unowned universal checklist.
At a supplier review, ask what changed since the last assessment. New hosting, remote support, subcontractors or data flows may invalidate earlier assumptions. Review the ISO 27001 and GDPR comparison as a reminder that management-system evidence and the GDPR’s processing-specific assessment answer different questions. Certification can inform the evidence, but neither a badge nor a questionnaire alone demonstrates that the actual data is secure enough.
Record a decision another person can verify
A concise security record identifies the processing activity, affected people and data, material threats, chosen measures, rejected alternatives, test evidence, exceptions and the next review trigger. It should link to the system owner and supplier, not contain sensitive credentials. If a control is planned but not installed, label it as planned; do not describe it as a current safeguard in a DPIA, contract or notice. A reviewer should be able to ask “what happens if this account is stolen?” and find a testable answer.
Article 83(4)(a) lists Article 32 among provisions in a statutory administrative-fine tier, but it does not assign a fixed penalty to each missing control. The Article 83 fine-structure guide explains how authorities assess an infringement. Earlier versions of this article asserted an EU-wide technical floor, mandatory algorithm and review cadence, and named sanctions without case-specific support. Those claims obscure the real task: make a risk-based choice, implement it, prove it works and revisit it as the processing changes. Read Article 32 on EUR-Lex alongside the CNIL security guide for the law and an authority’s practical guidance.