Skip to content
AuditFront
Art.32 GDPR

GDPR Art.32: Security of Processing

What This Control Requires

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 risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: (a) the pseudonymisation and encryption of personal data; (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

In Plain Language

Security is the backbone of GDPR compliance, and Article 32 spells out what regulators expect you to actually do about it. Both controllers and processors must implement technical and organisational safeguards that match the risk level of their processing activities. The article calls out four specific types of measures: pseudonymisation and encryption, confidentiality, integrity, availability and resilience controls, disaster recovery and business continuity, and regular testing of your defences.

What counts as "appropriate" depends on a risk-based assessment. You weigh the current state of security technology, cost of implementation, the nature and scope of your processing, and the potential impact on individuals. A hospital handling medical records needs a very different security posture from a small retailer processing customer orders - but both need measures that fit their specific risk profile.

Responsibility is shared. Controllers must secure their own processing and choose processors that offer strong security guarantees. Processors must implement the measures set out in the data processing agreement and maintain them throughout the engagement. Staff on both sides need to be bound by confidentiality obligations.

How to Implement

Start with a thorough information security risk assessment focused on personal data. Map out every processing activity, identify the data involved, catalogue threats (both internal and external), pinpoint system vulnerabilities, estimate likelihood, and assess potential severity of impact on data subjects. Use the results to set the right level of security for each activity.

Put technical controls in place that match the risks you have identified. At a minimum, cover encryption of personal data at rest and in transit using current algorithms, access controls including multi-factor authentication and role-based permissions, network security such as firewalls, intrusion detection, and segmentation, endpoint protection including anti-malware, device management, and patching, and data loss prevention tooling to block unauthorised exfiltration.

Layer in organisational measures alongside the technical ones. Write and enforce policies covering acceptable use, access management, incident response, and change management. Run a security awareness training programme for all staff. Assign clear security responsibilities across the organisation. Build a vendor security assessment process and conduct background checks for anyone handling sensitive data.

Build and test your business continuity and disaster recovery capabilities with personal data front of mind. Set up regular backups with proven restoration procedures. Define recovery time objectives (RTO) and recovery point objectives (RPO) for every system that processes personal data. Run disaster recovery exercises regularly to confirm you can actually restore access after an incident.

Set up an ongoing security testing programme - Article 32(1)(d) explicitly requires it. Run vulnerability scans at regular intervals and after any significant system change. Carry out penetration testing at least annually, more often for high-risk systems. Commission independent security audits for critical processing systems. Track every finding through to remediation.

Evidence Your Auditor Will Request

  • Information security risk assessment documentation for personal data processing
  • Technical security controls inventory (encryption, access controls, network security, etc.)
  • Information security policies and procedures documentation
  • Business continuity and disaster recovery plans with test results
  • Penetration testing, vulnerability assessment, and security audit reports

Common Mistakes

  • Security measures not proportionate to risk - either inadequate for high-risk processing or overly complex for low-risk processing
  • No regular testing of security measures as required by Article 32(1)(d)
  • Business continuity and disaster recovery plans that exist but have never been tested
  • Encryption not applied to personal data at rest or in transit
  • Security risk assessments not conducted or not updated when processing activities change

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.8.24 Related
ISO 27001 A.5.15 Related
ISO 27001 A.8.1 Related
NIS2 Art.21.2a Related

Frequently Asked Questions

What specific security standards does the GDPR require?
The GDPR deliberately avoids naming specific standards or technologies. It asks for measures "appropriate to the risk", factoring in current technology and implementation costs. That said, aligning with recognised frameworks like ISO 27001, SOC 2, or NIST gives you solid evidence of appropriate security. Supervisory authorities regularly reference these standards in their guidance, so they carry real weight in practice.
Is ISO 27001 certification sufficient to meet Article 32?
It is strong evidence and will get you most of the way there, but it is not an automatic pass. Article 32 demands a specific focus on personal data risks, which may go beyond the scope of a general ISMS. Make sure your ISO 27001 implementation explicitly addresses personal data protection risks and you will be in a strong position.
How often should we test our security measures?
Article 32(1)(d) says "regularly" but does not pin down a frequency. In practice, aim for vulnerability scanning at least quarterly, penetration testing at least annually, and security audits once a year. Always run ad-hoc tests after significant system changes. If you handle higher-risk data, increase the cadence. Document your testing schedule and the reasoning behind it.

Track GDPR compliance in one place

AuditFront helps you manage every GDPR control, collect evidence, and stay audit-ready.

Start Free Assessment