GDPR Security Requirements: What Article 32 Actually Demands
GDPR says you need "appropriate security." Here's what that actually means for your systems — and what happens when regulators disagree with your definition.
Every organisation subject to GDPR must implement security measures for the personal data it holds. That obligation comes from Article 32, which requires "appropriate technical and organisational measures" to protect personal data. The problem: Article 32 never tells you exactly what those measures are. The word "appropriate" carries all the weight — and it's left entirely to interpretation.
This ambiguity is intentional. Regulators didn't want to prescribe a single security standard that would become obsolete as technology evolved. Instead, they created a risk-based framework. Your GDPR security requirements are proportionate to the harm that would result if the data you hold were compromised.
That sounds flexible. In practice, it creates uncertainty — especially for small and mid-sized organisations without dedicated security teams. This guide breaks down what Article 32 actually says, how "appropriate" is determined in practice, what technical and organisational measures satisfy the standard, and what enforcement looks like when organisations get it wrong.
What Article 32 Actually Says
Article 32(1) states that controllers and processors shall implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk," including:
- Pseudonymisation and encryption of personal data
- Ensuring ongoing confidentiality, integrity, availability, and resilience of processing systems and services
- The ability to restore availability and access to personal data in a timely manner in the event of a physical or technical incident
- A process for regularly testing, assessing, and evaluating the effectiveness of technical and organisational measures
Those are the four categories Article 32 explicitly mentions. Notice what's missing: specific standards, minimum encryption requirements, mandatory certifications, or defined testing frequencies. The regulation is deliberately technology-neutral.
Article 32(2) adds that in assessing the appropriate level of security, account shall be taken of "the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed."
Article 32(3) provides a compliance shortcut: adherence to approved codes of conduct or approved certification mechanisms may be used as an element to demonstrate compliance. ISO 27001, for example, won't guarantee GDPR compliance — but it's evidence of a structured approach that regulators notice.
The "Appropriate" Standard: Risk-Based and Proportionate
The core of GDPR security requirements is proportionality. What's appropriate for a hospital processing medical records is not the same as what's appropriate for a ten-person SaaS company storing email addresses and billing information.
Regulators assess "appropriate" by reference to several factors:
The nature of the data. Special category data — health records, biometric data, religious beliefs, political opinions, sexual orientation — demands more protection than a list of business email addresses. The more sensitive the data, the higher the security bar.
The volume of data processed. Processing records for 5,000 customers differs from processing records for five million. Scale amplifies the potential harm of a breach.
The state of the art. Security measures must be current. "We encrypt everything" was impressive in 2010; it's table stakes in 2026. Article 32 explicitly references "the state of the art" — meaning regulators will assess whether you're using modern, proven methods, not deprecated ones.
The costs of implementation. Article 32 acknowledges that security investments must be proportionate to available resources. A startup with €50,000 annual revenue isn't expected to spend €40,000 on a security program. But cost is not an excuse for ignoring basic measures.
The likelihood and severity of risk. If a breach would result in identity theft, financial loss, discrimination, or physical harm to individuals, the standard is higher. If a breach would expose publicly available contact information, the impact — and therefore the standard — is lower.
This risk-based framing means your GDPR security requirements aren't a fixed checklist. They're an ongoing assessment of what your threat environment demands, given what you process and who it belongs to.
How to Assess "Appropriate" in Practice
Before implementing security measures, you need to understand your risk profile. That means asking:
What personal data do we hold? Map your data categories — names, emails, payment details, health records, location data, behavioural data. Each category carries different risk if compromised.
Where does it live? Databases, cloud storage, employee laptops, third-party SaaS tools, backups. Every location is a potential attack surface.
Who can access it? Internal staff, contractors, suppliers, APIs. The more access points, the more risk.
What would happen if it were breached? Would individuals face identity theft? Financial harm? Reputational damage? Physical danger? The answer determines how much security is "appropriate."
What threats are realistic? Phishing, ransomware, misconfigured cloud storage, SQL injection, credential stuffing. Your controls should match your realistic threat landscape.
This assessment doesn't need to be a formal DPIA (though it often should be, for high-risk processing). It's the foundation for choosing which GDPR security requirements to implement and to what level.
Technical Measures That Satisfy GDPR Security Requirements
Encryption at Rest and in Transit
Article 32 explicitly mentions encryption as a measure to consider. In 2026, this is non-negotiable for any organisation processing personal data:
- In transit: TLS 1.2 minimum (TLS 1.3 preferred) for all data moving between systems, browsers, and APIs. Unencrypted HTTP for any page that handles personal data is a clear failure.
- At rest: Database encryption, encrypted storage volumes, and encrypted backups. If a database file is stolen without encryption, every record in it is exposed.
Encryption also has a direct benefit under GDPR's breach notification rules: if breached data is encrypted with keys the attacker doesn't have, notification obligations are substantially reduced.
Access Controls and Authentication
Who can access personal data is as important as how it's protected. GDPR security requirements include controlling and logging access:
- Principle of least privilege: Staff should only access the data they need for their specific role. A customer support agent doesn't need access to raw database exports.
- Multi-factor authentication (MFA): Required for any system that holds personal data. MFA is one of the single most effective controls against credential-based attacks. Regulators now treat the absence of MFA on production systems as a significant failing.
- Strong password policies: Enforced through tooling, not policy documents. Use a password manager and prohibit credential reuse.
- Access reviews: Regularly audit who has access to what. Remove access when employees leave or change roles.
Audit Logging
You cannot demonstrate compliance with GDPR security requirements if you have no record of who accessed what data and when. Audit logs serve two purposes: they detect intrusions, and they demonstrate due diligence to regulators.
Effective audit logging captures: login events, data access events, data exports, changes to user permissions, and administrative actions. Logs should be stored securely and retained long enough to support incident investigation.
Vulnerability Scanning and Patching
Unpatched software is one of the leading causes of data breaches. GDPR security requirements implicitly demand a patching process — the "state of the art" standard means your systems should be running current, supported software.
- Patch management: Critical security patches should be applied within days, not months. Have a defined process and someone accountable for it.
- Vulnerability scanning: Regular automated scans of your web applications, APIs, and infrastructure identify weaknesses before attackers do. OWASP ZAP, Qualys, and similar tools are accessible even to smaller organisations.
- Dependency management: For SaaS and development teams, regularly update libraries and dependencies. Outdated packages are a common attack vector.
Penetration Testing
Article 32(1)(d) explicitly requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing." For most organisations, this means penetration testing at least annually, and after significant changes to systems that process personal data.
Penetration testing doesn't need to be prohibitively expensive. A focused test of your primary application and infrastructure surfaces the highest-priority issues. Document your testing cadence — regulators look for evidence of systematic testing, not just a one-off exercise.
Data Minimisation at the System Level
Collecting less data is a security measure. If you don't hold it, you can't breach it. GDPR security requirements connect to the data minimisation principle: the less personal data you process, the lower your risk exposure.
Practically: remove data fields you don't use, implement data retention policies with automated deletion, and audit your analytics and tracking scripts to eliminate unnecessary data collection.
Backup and Disaster Recovery
Article 32's requirement to restore "availability and access to personal data in a timely manner" after an incident means backups and disaster recovery plans are part of your GDPR security requirements — not just good IT hygiene.
Backups should be: automated and frequent, tested regularly (untested backups are not backups), stored separately from primary systems (so ransomware can't encrypt both), and encrypted.
Organisational Measures
Technical controls alone don't satisfy GDPR security requirements. Article 32 explicitly requires organisational measures too.
Security Policies
Written policies aren't bureaucratic overhead — they're evidence that your organisation has thought systematically about security. Minimum policies include: an information security policy, an acceptable use policy, a password policy, a data handling policy, and a remote working policy.
Policies only count if they're actually followed. Keep them short enough to read, version them, and require annual acknowledgment from staff.
Staff Training
The majority of data breaches involve a human element — phishing emails, misconfigured systems, accidental disclosures. Security awareness training is a core GDPR security requirement. Train staff on: identifying phishing, handling personal data, reporting incidents, using company systems securely, and the organisation's security policies.
Training should be annual at minimum, documented, and role-specific for teams handling sensitive data.
Incident Response Plan
When a breach occurs, you have 72 hours to notify your supervisory authority. Without a documented incident response plan, that deadline is very hard to meet. Your plan should define: who is notified internally, how the scope of the breach is assessed, who contacts the regulator, how affected individuals are notified, and how evidence is preserved.
Test your incident response plan at least annually with a tabletop exercise. A plan that has never been tested is a plan that will fail when you need it most.
Supplier Security Assessments
Under GDPR, if you share personal data with a third party (a processor), you're responsible for ensuring they provide "sufficient guarantees" of appropriate security. That means due diligence on suppliers before onboarding them:
- Do they have a current security certification (ISO 27001, SOC 2)?
- Is a Data Processing Agreement in place?
- What is their breach notification process?
- Have they had significant security incidents?
Supplier security assessments should be documented and repeated when contracts renew or when suppliers have significant incidents.
NDAs and Confidentiality Agreements
Staff and contractors who access personal data should be bound by confidentiality obligations. This is both a GDPR security requirement and common sense — it establishes clear obligations and supports enforcement if data is mishandled internally.
Pseudonymisation and Anonymisation: The Distinction
Article 32 specifically mentions pseudonymisation as a measure to consider. These two concepts are often confused, and the distinction matters significantly:
Pseudonymisation replaces directly identifying information (name, email) with a non-identifying reference (a user ID or hash). The original data still exists and can be re-linked with additional information. Pseudonymised data is still personal data under GDPR, but it carries reduced risk — making it relevant to the "appropriate" security assessment.
Anonymisation irreversibly removes all identifying information such that re-identification is not possible. Truly anonymised data falls outside GDPR's scope entirely. The bar for genuine anonymisation is high — many datasets that appear anonymous can be re-identified from residual signals.
For most organisations, pseudonymisation is the practical tool: it reduces breach impact, may reduce notification obligations, and demonstrates a proactive approach to GDPR security requirements. Anonymisation is appropriate for analytics, research, and retention of historical data where individual identification is no longer needed.
Security Testing: Article 32(1)(d) in Detail
Article 32(1)(d) is the most overlooked part of the GDPR security requirements: the obligation to maintain "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures."
This is not a one-time activity. Regulators have cited the absence of regular testing as a failing in enforcement decisions. Your testing program should include:
- Penetration testing: At least annually, or after significant system changes
- Vulnerability scanning: Automated and continuous, ideally, with monthly reporting
- Security control reviews: Quarterly check that access controls, logging, and other controls are functioning correctly
- Phishing simulations: To test and reinforce staff awareness training
- Backup restoration tests: Verifying that backups can actually be restored
- Incident response exercises: Tabletop tests of your breach response plan
Document everything. The test, the findings, the remediation steps, and the re-test. This documentation is what you show regulators when they ask how you've satisfied GDPR security requirements.
The Breach-Security Connection: Why Article 32 Matters at Enforcement
Data breaches don't automatically result in GDPR fines. Breaches become enforcement matters when they demonstrate that Article 32's GDPR security requirements weren't met. Regulators look at whether the breach was preventable with appropriate measures, whether the organisation had implemented those measures, and whether the measures were tested and effective.
Almost every major GDPR enforcement action involving a data breach has cited Article 32 failures. The breach is the symptom; inadequate security is the violation.
What Regulators Have Fined For: Enforcement Examples
British Airways (2020)
The UK Information Commissioner's Office (ICO) fined British Airways £20 million — reduced from an initial £183 million penalty — after a breach that exposed the personal and financial data of approximately 400,000 customers. The breach resulted from a credential-stealing attack that went undetected.
Key Article 32 failures cited: inadequate access controls, failure to detect the attack, and insufficient monitoring of systems handling payment data. Basic security measures — MFA, anomaly detection, network segmentation — would have prevented or limited the breach.
Marriott International (2020)
The ICO fined Marriott £18.4 million after a breach originating in a 2014 compromise of Starwood Hotels' systems — which Marriott acquired in 2016 and failed to properly audit. The breach exposed data of approximately 339 million guest records.
Key Article 32 failure: Marriott acquired a company without conducting adequate security due diligence. The compromised systems continued operating for years after the acquisition. This case established that supplier security assessments and acquisition due diligence are GDPR security requirements, not optional.
These cases illustrate that the GDPR security requirements aren't aspirational. They're the standard against which breach response is measured.
Practical Checklist: 10 Security Measures That Satisfy Article 32 for Most Organisations
- TLS on all systems processing personal data (no unencrypted HTTP)
- Database encryption at rest for all databases holding personal data
- MFA enabled on all production systems, admin consoles, and SaaS tools
- Access control review completed in the last 12 months; least privilege enforced
- Audit logging active for all access to personal data, retained for 12 months
- Patch management process with critical patches applied within 7 days
- Annual penetration test completed and findings remediated
- Security awareness training completed by all staff in the last 12 months
- Documented incident response plan tested in the last 12 months
- Supplier DPAs and security assessments completed for all processors handling personal data
This is not an exhaustive list for all organisations. High-risk processing — healthcare, financial data, children's data, large-scale behavioural profiling — demands additional controls. But for most small and mid-sized organisations, these ten measures demonstrate a systematic approach to GDPR security requirements that regulators can recognise as good-faith compliance.
How Custodia Helps With GDPR Security Requirements
One of the most common security issues organisations overlook is what's happening on their own website. Third-party trackers, analytics tools, and advertising pixels can collect and transmit personal data to external servers — often without the organisation fully understanding which data is leaving and where it's going.
That's a GDPR security issue: if you don't know what data is being processed, you can't assess the risk, implement appropriate controls, or make accurate disclosures in your privacy policy.
Custodia scans your website to identify every tracker, pixel, and script that collects or transmits data — giving you a complete inventory of your actual data flows. It's the starting point for an accurate data mapping exercise, a prerequisite for a proper Article 32 risk assessment, and evidence of due diligence that regulators expect.
Scan your website free at app.custodia-privacy.com. No signup required. Results in 60 seconds.
Last updated: March 27, 2026. This post provides general information about GDPR security requirements under Article 32. It does not constitute legal advice. Consult a qualified privacy or information security professional for advice specific to your organisation.
Top comments (0)