GDPR — Technical Measures for IT Systems

GDPR comes into effect on May 25, 2018. Lawyers handle consents and contracts. But who handles the technical implementation? Data encryption at rest, audit logs, right to erasure in a system with 30 interconnected tables — that’s our world.

What GDPR Actually Requires Technically¶

Article 25 speaks of “data protection by design and by default.” Article 32 requires “appropriate technical and organizational measures.” What does this mean in practice? The regulation is intentionally vague — it doesn’t prescribe specific technologies. But audit practices will quickly stabilize.

From our experience preparing enterprise systems for GDPR, we identify 5 key technical areas that every IT system processing personal data must address.

1. Encryption — At Rest and In Transit¶

In transit: TLS 1.2 minimum, ideally TLS 1.3. No self-signed certificates in production. mTLS for service-to-service communication. Let’s Encrypt eliminates the excuse “certificates are expensive.”

At rest: AES-256 for databases and storage. Azure SQL has Transparent Data Encryption (TDE) by default. PostgreSQL requires pgcrypto or filesystem-level encryption. Don’t forget backups — encrypted production and unencrypted backup is like locked doors with an open window.

2. Pseudonymization and Anonymization¶

GDPR explicitly mentions pseudonymization as a recommended measure. The difference is crucial: pseudonymization is reversible (a key exists), anonymization is irreversible (data ceases to be personal data).

In practice: production database uses pseudonymized identifiers. Mapping table (pseudonym → real identity) is in separate storage with stricter access. Analytical systems work with anonymized data — k-anonymity, l-diversity for statistical outputs.

3. Right to Erasure — Technical Horror¶

Article 17 — right to be forgotten. Sounds simple. Implementation is a nightmare. A user in CRM system has records in 15 tables, 3 microservices, 2 analytical systems, 5 backups and an Elasticsearch index.

Our approach: Data Subject Registry — central registry of all places where personal data of a specific subject is located. Each system implements a DELETE endpoint. Orchestrator goes through the registry and calls deletion in the correct order (respects foreign keys).

For backups: don’t delete from backups (technically impossible with tape/immutable storage). Instead “crypto shredding” — data in backups is encrypted with per-subject key. Delete the key = data becomes unreadable.

4. Audit Logs and Demonstrability¶

GDPR requires the ability to demonstrate compliance. This means logging: who accessed what personal data, when, why and what they did with it. But beware — audit log itself contains personal data (who = employee, what = subject data).

Solution: structured audit logs with reference to data subject (not copy of data). Central log management (ELK stack, Splunk). Immutable storage — logs cannot be retroactively modified. Log retention matches purpose — typically 1-3 years.

• Every API call logs: user_id, action, resource_type, resource_id, timestamp
• Sensitive values are not logged — only references
• Export logs for DPA (Data Protection Authority) in machine-readable format

5. Data Portability — Machine-Readable Export¶

Article 20 — subject has the right to obtain their data in “structured, commonly used and machine-readable format.” In practice: JSON or CSV export of all personal data. API endpoint that generates complete data package for specific subject.

Implement as asynchronous operation — generating export for user with rich history can take minutes. Email notification with download link. Link with limited validity (24-48h) and single use.

Consent Management — Technical Side¶

Consents aren’t just checkboxes on websites. Technically you need: consent records with timestamp and text version, API for checking valid consent before processing, mechanism for consent withdrawal with propagation to all systems.

Consent store as separate microservice. Every personal data processing first verifies valid consent. Withdrawn consent triggers event — downstream systems react by stopping processing.

Privacy by Design in Practice¶

Data minimization: collect only what you need. Every field in database should have documented purpose. Date of birth instead of national ID (if you don’t need national ID). Email instead of phone number (if you won’t call).

Data retention: automatic data deletion after purpose expires. Order fulfilled → delete personal data after legal archival period (typically 10 years for accounting documents). Scheduler that daily checks expired records.

GDPR Isn’t a Project — It’s a Process¶

Technical GDPR implementation isn’t a one-time task. It’s an architectural principle that must permeate every new system and every change to existing ones. Privacy by design means thinking about data protection from the first line of code — not adding it as an afterthought before audit.