GDPR and Cybersecurity: A Practical Guide to Article 32, DPIA, Encryption and Breach Response

GDPR and Cybersecurity: A Practical Guide

Introduction: Why GDPR Is About Technology, Not Just Law

The GDPR (known in Polish as RODO) took effect in May 2018 and changed the rules of the game. Personal data protection stopped being "paperwork" for lawyers. It became a concrete technical challenge for IT and security teams.

The key provision is Article 32 of the GDPR, which requires organizations to implement "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk. This is where the law meets cybersecurity.

This guide is for Data Protection Officers (DPOs), IT managers and CISOs: anyone who has to turn GDPR requirements into real technical safeguards.

GDPR Article 32: The Foundation of Technical Security

From Rigid Requirements to "Appropriate Measures"

The GDPR changed the underlying philosophy. Instead of mandating specific technologies ("you must have a firewall"), it says: "implement measures appropriate to the risk."

What does that mean in practice?

You have to demonstrate due diligence. Saying "we have safeguards" isn't enough. You need to show WHY you chose those particular safeguards
"State of the art" is a moving target. What was considered secure in 2018 (e.g., SHA-1) may not be good enough today
Risk analysis is an ongoing process. You can't do it once and leave it on the shelf

CIA + Resilience: The 4 Pillars of Security Under the GDPR

The GDPR extends the classic CIA triad with a fourth pillar: Resilience.

1. Confidentiality

What it means: Only authorized people can see the data
Threats: SQL database leaks, theft of an unencrypted laptop, an employee seeing data they shouldn't
Solutions: Encryption, access control (RBAC), DLP

2. Integrity

What it means: Data is complete, accurate and unaltered
Threats: Ransomware, malicious modification of records, write errors
Solutions: Checksums (hashing), digital signatures, change logs

3. Availability

What it means: Data is accessible when it's needed
Threats: DDoS attacks, data center outages, loss of an encryption key
Solutions: Redundancy (HA), load balancing, tested backups

4. Resilience

What it means: Systems survive an incident and recover quickly
Threats: Advanced persistent threats (APTs), pandemics, natural disasters
Solutions: Penetration testing, BCP/DR, fault-tolerant architecture

Pseudonymization: Simple but Effective

Pseudonymization (Art. 32(1)(a)) means processing data so it can't be linked to a specific person without additional information. Practical methods:

1. Tokenization

Instead of "John Smith" → "TOKEN_X7F9B2"
The real data is stored in a separate, protected database

2. Keyed encryption

Data is unreadable without the decryption key
The key is stored separately from the data

3. Salted hashing

A hash function plus a random value (the salt)
Cannot be reversed

NOTE: Pseudonymization ≠ anonymization! Pseudonymized data is still subject to the GDPR because it CAN be linked back to an individual (if you have the key or mapping).

Accountability: Prove You're Not Asleep at the Wheel

The accountability principle (Art. 5(2)) requires you not only to comply with the GDPR but also to be able to PROVE it.

In practice, you need:

Security policies, signed by employees
Audit reports, both internal and external
Incident logs, with every breach documented
A risk analysis trail showing why these specific safeguards were implemented

The motto: "If it isn't documented, it doesn't exist" (from the point of view of the Personal Data Protection Office, UODO)

Risk Analysis and DPIA: When and How?

Risk Management in 5 Steps

The process (based on ISO 27005 or ENISA guidance) looks like this:

Step 1: Context

What are we processing? Where? For what purpose?

Step 2: Inventory Your Assets

Hardware, software, people, paper files, locations

Step 3: Threats

Hackers, fire, system failure, accidental leaks

Step 4: Vulnerabilities

Unpatched systems, weak passwords, lack of training

Step 5: Assess the Risk

IMPORTANT: You assess the harm to the INDIVIDUAL, not just to the company!
"Damage to the company's reputation" isn't enough. You have to think in terms of "violation of the customer's privacy"

DPIA: When Is It Mandatory?

A Data Protection Impact Assessment (DPIA) is an in-depth risk analysis. You must carry one out (Art. 35 GDPR) when processing is "likely to result in a high risk."

Do you need a DPIA? (2 or more of the following = YES)

✅ Scoring/profiling (e.g., credit scoring) ✅ Automated decision-making (AI deciding on hiring or credit) ✅ Systematic monitoring (CCTV, location tracking) ✅ Sensitive data at large scale (health, sexual orientation, religion) ✅ Large-scale processing (millions of records) ✅ Combining datasets from different sources ✅ Data on vulnerable individuals (children, employees) ✅ New technologies (AI, IoT, biometrics) ✅ Data transfers outside the EEA

How to Conduct a DPIA in 6 Steps

Describe the processing: what, where, why and for how long?
Assess necessity: do we really need to process this?
Assess proportionality: are we collecting too much?
Identify the risks: what could go wrong?
Plan mitigation measures: how do we minimize the risk?
Consultation:
- DPO opinion (mandatory)
- Prior consultation with UODO (if the risk remains high after mitigation)

When to Run a DPIA? The Earlier, the Better

Privacy by Design means doing the DPIA at the START of a project, not at the end. Why?

At the concept stage, fixes are cheap (a change in the documentation)
At the implementation stage, fixes are expensive (rewriting code, changing the database)
After go-live, fixes may be impossible (architecture constraints)

Example: You're planning an HR system that uses AI to screen résumés. A DPIA at the start means changing the algorithm. A DPIA after deployment means rewriting the entire system.

Cryptography: Practical, No-Nonsense Guidance

Why Is Encryption So Important?

The simple fact: a leak of encrypted data (with a secure key) = no obligation to notify UODO.

Without encryption: a leak = notification within 72 hours + a potential fine + a reputation in ruins.

Which Algorithms Should You Use? (BSI/ENISA Recommendations)

Symmetric Encryption (the same key encrypts and decrypts)

Algorithm: AES
Key length: At least 128 bits (256 bits preferred)
Mode: GCM or CBC (do NOT use ECB!)

Asymmetric Encryption (a key pair: public + private)

RSA: At least 2048 bits (3072 or 4096 preferred). 1024 bits = broken, don't use it!
ECC (elliptic curves): P-256, P-384, Curve25519 (at least 256 bits)

Passwords and Hash Functions

Hashing: SHA-2 (SHA-256, SHA-512) or SHA-3
User passwords: Argon2id, bcrypt, PBKDF2 (always salted!)
DO NOT USE: MD5, SHA-1 (broken)

Encryption in Transit and at Rest

Data in transit (sent over the network):

TLS 1.2 or 1.3 (disable older SSL/TLS versions!)
HSTS (forces HTTPS in the browser)

Data at rest (stored on disk):

Laptops/phones: Full-disk encryption (BitLocker, FileVault, LUKS)
Databases: TDE (Transparent Data Encryption) or column-level encryption
Backups: Always encrypted!

The Future: Quantum Computers

The "Store Now, Decrypt Later" threat: someone steals encrypted data today, waits 10 years for a quantum computer, then decrypts it.

If you process data with long retention periods (e.g., medical records kept for 20 years), start planning your migration to post-quantum algorithms now:

ML-KEM (Module-Lattice-Based Key Encapsulation)
ML-DSA (Module-Lattice-Based Digital Signature)

Identity and Access Management (IAM): Who, What and When?

MFA: No Longer a Luxury, Now the Standard

Username + password = too weak. Period. Under the GDPR, MFA (Multi-Factor Authentication) is now "state of the art."

The 3 authentication factors:

Something you know (password, PIN)
Something you have (phone, USB token, smart card)
Something you are (fingerprint, face, iris)

MFA = at least 2 of the 3. The most common combination: password + SMS or authenticator app code.

Password Policies: What Works (and What Doesn't)

❌ Bad practices (outdated):

Forcing password changes every 30 days: people end up with "Password1", "Password2", "Password3"
Requiring special characters: "P@ssw0rd!" is no more secure than "correct horse battery staple"

✅ Good practices (2025):

Long passphrases instead of complexity: "ILoveEating PizzaOnFridayNights" > "P@$$w0rD!"
Change passwords only after an incident or a suspected breach
A password manager for employees (1Password, Bitwarden, Dashlane)

Least Privilege: Grant the Minimum, Not the Maximum

The principle: Everyone gets access only to what they need to do their job. Nothing more.

In practice:

Admin account ≠ everyday work account (even for IT staff)
Temporary privileges that expire automatically
Regular access reviews (who has left? who has changed roles?)

Infrastructure: Segmentation, Backups, Monitoring

Network Segmentation: Don't Put Everything in One Basket

A flat network is a disaster waiting to happen. Ransomware gets in through a single laptop and spreads across the entire company.

The solution: VLANs and segmentation

Office (employees): a separate network
Guests (customer Wi-Fi): a COMPLETELY separate network
IoT (printers, sensors, cameras): an isolated network
Production/critical systems: a dedicated segment

An NGFW (Next-Generation Firewall) controls traffic between segments.

Backups: Ransomware Will Put Them to the Test

The 3-2-1 rule:

3 copies of your data (the original + 2 backups)
2 types of media (disk + tape / cloud)
1 copy off-site (in a different location)

Key points:

Immutable (WORM) backups: cannot be deleted or encrypted
Offline backups: disconnected from the network (out of ransomware's reach)
TEST YOUR RESTORES: this is a GDPR requirement! "We have backups" ≠ "our backups work"

Logging and Monitoring: You Can't Detect an Incident Without Them

You have to detect and report a breach within 72 hours, and without logs that's impossible.

What to log:

Logins (successful and failed)
Access to personal data
Administrative actions (permission changes, data deletion)
System changes (software installation, configuration changes)

Where to store them: A SIEM (Security Information and Event Management) system, a central log repository with automated analysis and alerting.

Chapter VI: Privacy Engineering: Privacy by Design and Privacy by Default

6.1. Design Patterns (Hoepman's Strategies)

Data-oriented: Minimize, Separate, Abstract, Hide.
Process-oriented: Inform, Control, Enforce, Demonstrate.

6.2. Privacy by Default in Practice

Protection must be the default setting. Users shouldn't have to change any settings to protect their privacy (e.g., consent checkboxes left unticked, profiles set to private by default).

The 72-Hour Procedure: What to Do When "It" Happens

The 7 Phases of Incident Management

Phase 1: Preparation (BEFORE anything happens)

Create an Incident Response Plan (IRP)
Appoint a CSIRT (Computer Security Incident Response Team)
Compile your contacts (UODO, vendors, external experts)

Phase 2: Detection

Detect the incident (SIEM alerts, an employee report, a message from a customer)
CRITICAL: The moment you "become aware of the breach" starts the 72-hour clock!

Phase 3: Triage (is this really a data breach?)

Was personal data being processed?
Could the data have been leaked, modified or made unavailable?
Assess the risk to individuals

Phase 4: Containment

Isolate infected systems
Change passwords and revoke tokens
Block the attacker's access

Phase 5: Eradication and Recovery

Remove the malware
Restore from clean backups
Verify that the attack can't happen again

Phase 6: Notification (THIS IS WHERE THE CLOCK MATTERS)

To UODO: Within 72 hours of "becoming aware of the breach" (if the risk is more than low)
To affected individuals: Without undue delay (if the risk is high)

Phase 7: Post-Incident

Analyze "what went wrong?"
Implement fixes
Update procedures

The Biggest Pitfall: Documentation!

Every breach (even one you DON'T report to UODO) must be recorded in your Breach Register.

You need to record:

The date and time you became aware of it
A description of the incident
The risk assessment
The actions taken
Your justification for NOT reporting it (if you didn't)

UODO may come back a year later and ask, "Why didn't you report this incident?" Without documentation, you have no defense.

Chapter VIII: Specific Processing Contexts

8.1. Remote Work (Home Office)

Mandatory VPN.
No use of personal devices (unless using a containerization model).
Physical security of screens and documents.

8.2. Cloud and the Supply Chain

The shared responsibility model.
Verifying vendor certifications (ISO 27001).
Data location (EEA vs. USA).

Chapter IX: Sector-Specific Compliance

Financial sector: Recommendation D of the Polish Financial Supervision Authority (KNF): managing test environments and anonymizing production data.
Healthcare sector: Long retention periods (20 years) and a 24/7 business continuity requirement (ransomware can put lives at risk).

Summary: Key Takeaways

The 4 Pillars of GDPR Compliance

1. GDPR = IT, IT = GDPR Stop thinking of data protection as "legal paperwork." It comes down to concrete technical safeguards. A DPO without IT support will fail. IT without DPO support will fail.

2. The Basics Get You 90% of the Way Before you invest in fancy AI-powered security:

✅ MFA wherever possible
✅ Encryption (in transit + at rest)
✅ Updates and patches (regularly!)
✅ 3-2-1 backups (TESTED!)

Without these basics, fancy tools won't help.

3. People Are the Weakest Link The best firewall in the world won't help if an employee clicks a phishing link.

Regular training (practical examples, not boring slide decks!)
Simulated phishing attacks
A security culture ("Seen something odd? Report it!")

4. An Incident Will Happen. Be Ready. The question isn't "if" but "when." Prepare with:

An Incident Response Plan
A CSIRT
Contacts (UODO, external experts, vendors)
Regular drills (tabletop exercises)

One Final Piece of Advice

GDPR compliance is a marathon, not a sprint. You can't do it "once and for all." It's a process of continuous improvement.

Start with the basics, build systematically and document everything. And remember: a simple system that WORKS beats a sophisticated one that exists only on paper.

Sources and Further Reading

Risk analysis for assets that process personal data... (in Polish) Link
CJEU judgment of January 25, 2024 in Case C‑687/21 - Odoserwis (in Polish) Link
DKN.5112.35.2021 - Security of processing - UODO (in Polish) Link
UODO guidelines on personal data processing documentation - BHPEX (in Polish) Link
GDPR in outpatient clinics and other healthcare facilities - Dr. Tymoteusz Zych (in Polish) Link
GDPR compliance checklist - ODO 24 (in Polish) Download
Guidelines 07/2020 on the concepts of controller and processor in the GDPR, Version 2.0 (Polish version) PDF
What Is Privacy-by-Design and Why It's Important? Link
Privacy by Design & Default: Essential Guide for Businesses Link
Guidelines for SMEs on the security of personal data processing - ENISA PDF
Guidelines for SMEs on the security of personal data processing... Link
Compliance and digital risk management: GDPR, ENISA and vulnerability strategies in modern cybersecurity - Cibersafety Link
Risk analysis vs. data protection impact assessment - UODO (in Polish) PDF
Guidelines on Data Protection Impact Assessment (DPIA)... (in Polish) Link
DPIA (Data Protection Impact Assessment) - LexDigital (in Polish) Link
DPIA: Data protection impact assessment for AI systems | Wolters Kluwer (in Polish) Link
UODO wants even minor GDPR incidents reported: new guidelines on responding to personal data breaches - Doradcy365 (in Polish) Link
Cryptography Guidelines for Experts | BSI TR-02102-1 Link
BSI-Compliant Post-Quantum Key Exchange: Implementation Pitfalls – PQCryptography.de Link
European Cybersecurity Certification Group Sub-group on Cryptography Agreed Cryptographic Mechanisms PDF
Cybersecurity in the financial system: a supervisory perspective - Polish Financial Supervision Authority (KNF) (in Polish) PDF