Technical and Organizational Security Measures (Article 32 GDPR) – A Comprehensive Guide
Why Article 32 Is Important
Article 32 of the General Data Protection Regulation (GDPR) is one of the most operationally significant provisions in the entire regulation. It imposes a direct legal obligation on both controllers and processors to implement appropriate security measures to protect personal data. Security breaches can lead to significant harm to data subjects — identity theft, financial loss, reputational damage, and discrimination — and can expose organizations to administrative fines of up to €10 million or 2% of annual global turnover (whichever is higher) under Article 83(4). Beyond fines, inadequate security can trigger notification obligations under Articles 33 and 34, erode public trust, and invite regulatory scrutiny. For the CIPP/E exam, Article 32 is a foundational topic because it intersects with data protection principles (integrity and confidentiality under Article 5(1)(f)), processor obligations (Article 28), data protection impact assessments (Article 35), and breach notification requirements (Articles 33–34).
What Article 32 Is
Article 32 is titled "Security of processing" and requires controllers and processors to implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. It does not prescribe a one-size-fits-all checklist; instead, it mandates a risk-based approach.
The article explicitly identifies several factors that must be taken into account when determining what measures are appropriate:
1. The state of the art — the current level of technological development and industry best practices.
2. The costs of implementation — security is not required to be limitless; organizations may weigh economic feasibility.
3. The nature, scope, context, and purposes of processing — the characteristics of the processing activity itself.
4. The risk of varying likelihood and severity — the probability and potential impact of harm to the rights and freedoms of natural persons.
Article 32(1) then provides a non-exhaustive list of measures that may be appropriate:
(a) Pseudonymisation and encryption of personal data — these are specifically named as examples of technical measures.
(b) The ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services — these four properties are central to information security.
(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 — this refers to disaster recovery and business continuity planning.
(d) A process for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing — this mandates ongoing review and improvement, not a one-time effort.
Article 32(2) adds that in assessing the appropriate level of security, account shall be taken in particular of the risks presented by processing, especially from accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data.
Article 32(3) provides that adherence to an approved code of conduct (Article 40) or an approved certification mechanism (Article 42) may be used as an element to demonstrate compliance with Article 32(1).
Article 32(4) states that both the controller and processor must take steps to ensure that any natural person acting under their authority who has access to personal data does not process them except on instructions from the controller, unless required by EU or Member State law. This addresses insider threats and access controls.
How Article 32 Works in Practice
In practice, compliance with Article 32 involves a structured, ongoing process:
Step 1: Risk Assessment
Organizations must identify and assess risks to the personal data they process. This involves cataloguing processing activities, identifying threats (e.g., cyberattacks, human error, natural disasters), and evaluating the likelihood and severity of potential harm to data subjects. This is distinct from, but related to, the DPIA under Article 35 — a DPIA is required in specific high-risk scenarios, whereas Article 32 risk assessment applies to all processing.
Step 2: Selection of Measures
Based on the risk assessment, organizations select technical and organizational measures. Technical measures include encryption, pseudonymisation, firewalls, access controls, intrusion detection systems, secure coding practices, multi-factor authentication, and data loss prevention tools. Organizational measures include security policies, staff training, background checks, clear roles and responsibilities, incident response plans, data classification schemes, clean desk policies, and contractual clauses with third parties.
Step 3: Implementation
The selected measures must be effectively implemented. This means deploying technologies, training staff, documenting procedures, and integrating security into the organization's culture and systems — aligned with the concepts of data protection by design and by default (Article 25).
Step 4: Testing and Review
Article 32(1)(d) explicitly requires regular testing, assessing, and evaluating. This includes penetration testing, vulnerability scanning, auditing access logs, tabletop exercises for incident response, and periodic review of policies. Security is not a one-time compliance exercise but an ongoing obligation.
Step 5: Documentation and Accountability
Under the accountability principle (Article 5(2)), organizations must be able to demonstrate compliance. This means maintaining documentation of risk assessments, security policies, training records, audit reports, and remediation efforts.
Key Concepts to Understand for the Exam
Risk-Based Approach: Article 32 does not require absolute security. It requires security that is appropriate to the risk. Higher-risk processing (e.g., health data, large-scale profiling) demands more robust measures. Lower-risk processing may justify lighter measures, provided the rationale is documented.
Both Controllers and Processors: Article 32 applies to both controllers and processors. This is a critical exam point. When a processor is selected, the controller must choose one that provides sufficient guarantees regarding Article 32 measures (see Article 28(1)).
Pseudonymisation and Encryption: These are the only specific technical measures explicitly named in Article 32. Pseudonymisation is also referenced in Article 4(5) (definition), Article 25 (data protection by design), and Recital 28. Encryption is a measure that can also mitigate breach notification obligations — under Article 34(3)(a), if encrypted data is breached and the encryption key is not compromised, communication to data subjects may not be required.
Confidentiality, Integrity, Availability, and Resilience (CIAR): These four properties reflect established information security principles. Resilience is a notable addition specific to the GDPR that goes beyond the traditional CIA triad.
Relationship with Other GDPR Provisions:
- Article 5(1)(f) — the integrity and confidentiality principle underpins Article 32.
- Article 25 — data protection by design and by default complements security obligations.
- Article 28 — processor agreements must address Article 32 requirements.
- Article 33 and 34 — security failures leading to breaches trigger notification obligations.
- Article 35 — DPIAs assess risks including security risks for high-risk processing.
- Article 40 and 42 — codes of conduct and certifications can help demonstrate Article 32 compliance.
Approved Codes of Conduct and Certification Mechanisms: Article 32(3) recognizes that adherence to approved codes of conduct or certification mechanisms can serve as evidence of compliance, though they do not guarantee it.
The "State of the Art" Factor: This means that what constitutes appropriate security evolves over time. Measures that were sufficient five years ago may no longer be adequate. Organizations must stay current with technological developments.
Exam Tips: Answering Questions on Technical and Organizational Security Measures (Article 32)
Tip 1: Remember the Four Factors
When a question asks what must be considered in determining appropriate security measures, recall the four factors: (1) state of the art, (2) cost of implementation, (3) nature, scope, context, and purposes of processing, and (4) risks of varying likelihood and severity to data subjects' rights and freedoms. Exam questions often test whether you can distinguish these factors from other GDPR criteria.
Tip 2: Know the Four Named Measures
Article 32(1)(a)–(d) lists four categories: pseudonymisation/encryption, ongoing CIAR, timely restoration of availability, and regular testing/evaluation. Be prepared to identify which category a specific measure falls under. For instance, a question about backup systems relates to (c) restoration of availability; a question about penetration testing relates to (d) regular testing.
Tip 3: Both Controllers and Processors
If a question asks who is obligated under Article 32, the answer is both controllers and processors. This distinguishes Article 32 from some other obligations that apply to controllers alone. Watch for answer choices that incorrectly limit the obligation to one party.
Tip 4: It Is Risk-Based, Not Absolute
Do not select answer choices suggesting that the GDPR requires the highest possible level of security or specific mandatory technologies. The GDPR takes a risk-based approach — what is appropriate depends on the specific processing context. An answer that references proportionality and risk assessment is likely correct.
Tip 5: Link to Breach Notification
Exam scenarios may describe a security incident and ask about obligations. Remember the link between Article 32 (preventing breaches through security) and Articles 33/34 (obligations after a breach occurs). Also remember that encryption can mitigate the obligation to notify data subjects under Article 34(3)(a).
Tip 6: Distinguish Technical from Organizational Measures
Some questions test whether you understand the difference. Technical measures are technology-based (encryption, firewalls, access controls, pseudonymisation). Organizational measures are process- and people-based (training, policies, contractual clauses, governance structures). Both are required.
Tip 7: Ongoing Obligation
Article 32 is not a one-time compliance task. The requirement to regularly test, assess, and evaluate (Article 32(1)(d)) means security must be continuously maintained. Questions that present a scenario where an organization implemented measures years ago but never reviewed them are likely testing this point.
Tip 8: Watch for Codes of Conduct and Certification
Article 32(3) allows adherence to approved codes of conduct or certification mechanisms as an element to demonstrate compliance. Note the word "element" — it is not a complete safe harbor. If a question asks whether certification alone guarantees compliance, the answer is no.
Tip 9: Article 32(4) — Personnel Controls
Do not overlook the requirement that persons acting under the controller's or processor's authority must process data only on the controller's instructions. This addresses insider risk and is relevant to questions about employee access management and authorization.
Tip 10: Read Scenarios Carefully
CIPP/E questions often present real-world scenarios. When you see a security-related scenario, systematically consider: What type of data is involved? What are the risks? What measures were or should have been in place? Who is responsible — controller, processor, or both? Was there a failure to assess, implement, or review? This structured approach will guide you to the correct answer.
Summary
Article 32 is a cornerstone of the GDPR's approach to data security. It reflects the regulation's risk-based philosophy by requiring controllers and processors to implement security measures that are appropriate to the specific risks of their processing activities. By understanding the four assessment factors, the four named categories of measures, the obligations on both controllers and processors, and the ongoing nature of the security obligation, you will be well-prepared to answer CIPP/E exam questions on this critical topic with confidence and accuracy.
