Module 5: GDPR Security, Accountability, and Enforcement

Step 1 – Why GDPR Security and Accountability Matter for Cybersecurity

Under the GDPR (in force since 2018 and still the core EU data protection law as of early 2026), security is not an optional add‑on. It is a legal obligation and part of a broader accountability framework.

In this module you will:

• Connect GDPR security duties to your cybersecurity practice
• See how risk-based measures work in practice
• Understand how documentation and governance prove compliance
• Review recent enforcement trends where weak security led to major fines

Key Articles we will focus on:

• Article 5 – Principles (integrity & confidentiality; accountability)
• Article 24 – Responsibility of the controller
• Article 25 – Data protection by design and by default
• Article 32 – Security of processing
• Articles 33 & 34 – Personal data breach notification (to authorities and individuals)

Keep in mind the comparison to U.S. frameworks from Modules 3–4:

• Like the FTC Act and state security laws, GDPR expects “reasonable” security.
• Unlike the U.S. patchwork, GDPR is a comprehensive, EU‑wide regime with strong supervisory authorities and high potential fines (up to 20 million EUR or 4% of global annual turnover, whichever is higher).

Step 2 – Core GDPR Security Provisions (Articles 5, 24, 25, 32, 33, 34)

Think of GDPR security obligations in layers:

1. Principles (Article 5)

• Integrity and confidentiality (Art. 5(1)(f)): personal data must be processed in a way that ensures appropriate security, including protection against unauthorized or unlawful processing and against accidental loss, destruction, or damage.
• Accountability (Art. 5(2)): the controller is responsible for, and must be able to demonstrate, compliance with all principles.

1. Overall responsibility (Article 24)

Controllers must implement appropriate technical and organizational measures (TOMs) and review and update them when necessary. Documentation is key.

1. Privacy by design and by default (Article 25)

Security must be built into systems and processes from the start, not bolted on later.

1. Security of processing (Article 32)

Requires risk-based TOMs, such as:

• Pseudonymization and encryption
• Ensuring ongoing confidentiality, integrity, availability, and resilience
• Ability to restore data after an incident
• Regular testing and evaluating of security measures

1. Breach notification (Articles 33 & 34)

• Art. 33: Notify the supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms.
• Art. 34: Notify affected individuals without undue delay if the breach is likely to result in a high risk to their rights and freedoms.

These provisions work together: design + controls + monitoring + incident response + documentation.

Step 3 – Visualizing Risk-Based Security Measures (Article 32)

Imagine a simple risk matrix for personal data processing:

| Impact on individuals (rights & freedoms) | Likelihood of incident | Risk level | Example GDPR security expectations |

|------------------------------------------|------------------------|-----------|-----------------------------------|

| Low | Low | Low | Basic access controls, passwords, backups |

| Medium | Medium | Medium | Strong authentication, staff training, vendor security clauses |

| High (e.g., health, location, finance) | Medium–High | High | Encryption at rest & in transit, strict access control, logging & monitoring, regular penetration tests, DPIA |

Example scenario

A health‑tech start‑up processes:

• Names, contact details, and detailed health data
• Via a cloud-based web app

Under Article 32, a risk assessment might identify:

• High impact: health data can cause discrimination or stigma
• Medium likelihood: web app is internet‑facing, multiple third‑party components

Resulting measures (non‑exhaustive):

• Technical: end‑to‑end TLS, database encryption, role‑based access control, MFA for staff, security logging and alerts, regular vulnerability scanning.
• Organizational: security policies, staff training, incident response plan, vendor due diligence and DPAs.
• Process: periodic risk review; change management so new features are security‑reviewed.

This is what “appropriate” TOMs look like in practice: proportionate to risk, not a fixed checklist.

Step 4 – Apply the Risk-Based Approach

You are the security analyst for an EU‑based e‑commerce platform that:

• Stores customer names, emails, shipping addresses
• Processes payment data via a third‑party payment processor (you never see full card numbers)
• Sends marketing emails to customers who opted in

Task: In your notes, list at least three security measures you would prioritize under Article 32, and briefly justify each in terms of risk.

Use this template:

1. Measure: `...`

• Risk addressed: `...`
• Why proportionate: `...`

1. Measure: `...`

• Risk addressed: `...`
• Why proportionate: `...`

1. Measure: `...`

• Risk addressed: `...`
• Why proportionate: `...`

Then, compare mentally to a U.S. context (e.g., FTC “reasonable security”): would your list look very different, or mostly the same? Where does GDPR add extra pressure (e.g., documentation, DPIAs, DPO)?

Step 5 – Accountability: Proving You Did the Right Thing (Articles 5(2), 24, 25)

Under GDPR, good security is not enough; you must be able to prove it.

Core elements of accountability related to security:

1. Documentation of measures (Art. 24)

• Security policies and standards
• Risk assessments and rationale for chosen controls
• Records of security testing, audits, and improvements

1. Data protection by design and by default (Art. 25)

• By design: security and privacy integrated into architecture and development lifecycle (e.g., secure SDLC, threat modeling).
• By default: only the minimum necessary data is processed (data minimization, limited retention, conservative default settings).

1. Records of processing activities (RoPA – Art. 30)

Not a security article, but crucial for it:

• Helps you see where personal data lives
• Supports risk analysis and incident response

1. Data Protection Impact Assessments (DPIAs – Art. 35)

Required when processing is likely to result in a high risk (e.g., large‑scale monitoring, sensitive data).

DPIAs must:

• Describe processing and purposes
• Assess necessity and proportionality
• Identify risks to individuals
• Describe measures to address risks (including security controls)

In enforcement practice since 2018, supervisory authorities often ask:

> Show us your risk assessment, DPIA, policies, and testing reports.

If you cannot, they may conclude you failed the accountability requirement, even if you had some technical controls.

Step 6 – DPIA and Breach Response in Practice

Mini‑case 1: Facial recognition in a shopping mall

A mall deploys cameras with facial recognition to analyze customer demographics.

High‑level DPIA elements:

• Description: continuous video capture + biometric analysis; profiling of visitors.
• Risks: surveillance concerns, misidentification, discrimination, chilling effect on behavior.
• Measures: limit retention, avoid unique identification, strong access controls, local processing where possible, encryption, clear signage, opt‑out if feasible, regular bias testing.
• Outcome: either proceed with enhanced safeguards or reconsider deployment.

Mini‑case 2: Breach response timeline (Articles 33 & 34)

A controller discovers on Monday morning that an attacker accessed a database containing:

• Names, emails, password hashes (strongly hashed), and some purchase history.

A realistic GDPR‑aligned response:

1. T0 – Discovery: Security team confirms there was unauthorized access.
2. Within hours: Start internal investigation and risk assessment.
3. Within 72 hours of awareness (Art. 33): Notify the supervisory authority unless you can clearly justify that risks to individuals are unlikely. You may give information in phases if still investigating.
4. Art. 34 decision: If you conclude there is a high risk (e.g., weak hashing or additional sensitive data), notify affected individuals with:

• Nature of the breach
• Likely consequences
• Measures taken and what they can do (e.g., change passwords).

1. Afterwards: Document everything: root cause, impact, remediation, lessons learned.

Authorities across the EU have repeatedly fined organizations for:

• Late or missing breach notifications
• Incomplete or unclear information
• No evidence of prior risk assessment or adequate security.

Step 7 – Quick Check: Security vs. Accountability

Answer this question to test your understanding of how security and accountability interact under the GDPR.

Step 8 – Enforcement Trends (2018–2025): What Gets Organizations Fined?

Since GDPR enforcement began in 2018, data protection authorities (DPAs) across the EU/EEA have issued thousands of decisions. Many of the largest and most frequent fines involve security and accountability failures.

Common patterns seen up to 2025:

1. Inadequate security controls (Art. 32)

• Weak or missing access controls (e.g., shared accounts, no MFA for privileged users)
• Outdated or unpatched systems exploited by known vulnerabilities
• Unencrypted databases or portable devices containing large volumes of personal data
• Poor segregation of test and production data (real data used in insecure test environments)

1. Lack of risk assessment and DPIAs (Arts. 24, 25, 35)

• Deploying invasive technologies (e.g., large‑scale monitoring, biometrics) without a DPIA
• DPIAs that are superficial, not updated, or not linked to actual security measures

1. Breach handling failures (Arts. 33, 34)

• Late notifications (beyond 72 hours) without justification
• Not notifying individuals when high risk was clear
• Incomplete or misleading breach reports

1. Accountability gaps

• No or poor documentation of TOMs, policies, or risk assessments
• Lack of clear roles (e.g., no DPO where required, or DPO without independence)

Key takeaway for cybersecurity practice:

DPAs do not only ask “Did you have a firewall?”

They ask: “Did you understand your risks, choose appropriate controls, maintain them, and document your reasoning?”

This aligns closely with modern security frameworks (e.g., NIST CSF, ISO/IEC 27001) but with legal consequences if you fall short.

Step 9 – Map a Security Failure to GDPR Articles

Consider this scenario:

> A mid‑size EU retailer suffers a ransomware attack. Investigation shows:

> • Servers were running unpatched software with known critical vulnerabilities.

> • Backups existed but were not regularly tested; recovery took weeks.

> • No documented incident response plan; staff were unsure whom to notify.

> • Breach notification to the DPA was sent 6 days after discovery, with minimal details.

> • There is no written risk assessment or DPIA for the affected systems.

Task: In your notes, match each failure to specific GDPR provisions:

• Unpatched software and lack of tested backups → Which article(s)?
• No incident response plan or clear roles → Which article(s)?
• Late and incomplete breach notification → Which article(s)?
• No risk assessment or DPIA → Which article(s)?

Then, write one sentence on how you would explain these failures to a CISO in terms of both legal and technical risk.

Use this format:

• Legal mapping: `...`
• Explanation for CISO: `...`

Step 10 – Flashcard Review: Key GDPR Security Concepts

Use these flashcards to reinforce core terms and articles before you move on.