GDPR and IT Systems — Technical Preparation for the Regulation

On May 25, 2018, GDPR — General Data Protection Regulation — comes into effect. Two weeks before the deadline, we summarize the specific technical measures that IT systems must comply with. No legal theory, just code, architecture, and tools.

Why GDPR is a Technical Problem¶

GDPR is not just a matter for the legal department. Articles 25 (Data Protection by Design) and 32 (Security of Processing) explicitly require technical measures. If your system cannot delete personal data of a specific user, you have a problem — regardless of how many consent forms you have on your website.

Fines up to 20 million EUR or 4% of global turnover are not a theoretical threat. Irish and French data protection authorities have already announced they will actively monitor compliance. The Czech Republic has announced a “soft start,” but this doesn’t mean you can ignore technical requirements.

Personal Data Mapping¶

The first step is data inventory — mapping where personal data is located throughout your systems. A typical enterprise system has data scattered across:

• Relational databases — primary storage, customers, users, orders tables
• Full-text indexes — Elasticsearch, Solr often index names, emails, addresses
• Cache layers — Redis, Memcached may hold session data with PII
• Logs — application logs commonly contain IP addresses, user-agent, sometimes names
• Backups — database dumps contain complete copies of data
• Message queues — Kafka topics, RabbitMQ queues with business events

We recommend creating a data flow diagram that shows the path of personal data through the entire system. Without this diagram, you cannot reliably implement the right to erasure.

Right to Erasure — Technical Implementation¶

Article 17 of GDPR gives data subjects the right to erasure of their personal data. Technically, this means:

-- Soft delete with anonymization
UPDATE customers SET
    first_name = 'DELETED',
    last_name = 'DELETED',
    email = CONCAT('deleted_', id, '@removed.local'),
    phone = NULL,
    address = NULL,
    deleted_at = NOW(),
    deletion_reason = 'GDPR_REQUEST'
WHERE id = :customer_id;

-- Cascading anonymization in related tables
UPDATE orders SET
    shipping_name = 'DELETED',
    shipping_address = 'DELETED'
WHERE customer_id = :customer_id;

Why not hard delete? In many systems, there are referential integrity constraints, accounting records, and audit trails that you cannot simply delete. Anonymization is a GDPR-compliant alternative — data ceases to be personal.

Don’t forget about deletion propagation to all subsystems: Elasticsearch index, Redis cache, Kafka consumer groups. Implement an asynchronous “deletion event” that all systems subscribe to.

Data Encryption — At Rest and In Transit¶

GDPR explicitly mentions encryption as an example of appropriate technical measures (Article 32, paragraph 1a).

• In transit — TLS 1.2+ for all communication, including internal services. Mutual TLS between microservices (see our article on Istio).
• At rest — Transparent Data Encryption (TDE) at the database level. PostgreSQL supports pgcrypto, MySQL has InnoDB tablespace encryption.
• Application-level encryption — for particularly sensitive data (social security numbers, health records) encrypt at the application level with a dedicated key management system (HashiCorp Vault, AWS KMS).

Pseudonymization¶

GDPR explicitly mentions pseudonymization as a technical measure that reduces risk for data subjects. Pseudonymized data still falls under GDPR, but the risk in case of a breach is significantly lower.

# Pseudonymization using HMAC
import hmac, hashlib

def pseudonymize(value, key):
    return hmac.new(
        key.encode(),
        value.encode(),
        hashlib.sha256
    ).hexdigest()[:16]

# Original: [email protected]
# Pseudonym: a3f8b2c1d4e5f6a7

Store the key for reverse mapping separately from pseudonymized data — ideally in an HSM or key management system. Without the key, data is irreversibly anonymous.

Audit Logs and Data Processing Records¶

Article 30 requires records of processing activities. Implement an audit log that records every access to personal data:

• Who accessed (user ID, role)
• When (timestamp with timezone)
• What (which data, which subject)
• Why (legal basis — consent, contract performance, legitimate interest)
• What they did (read, update, delete, export)

The audit log must be immutable — append-only storage. We recommend a dedicated log store (Elasticsearch with write-once indexes, or blockchain-inspired hash chain).

Consent Management¶

Technically, you need a system that:

• Stores granular consents — separately for marketing, analytics, third-party sharing
• Records the version of terms the user consented to
• Enables consent withdrawal with immediate propagation to all processing systems
• Provides an API for checking consent validity before each processing operation

Data Portability — Export in Machine-Readable Format¶

Article 20 gives data subjects the right to data portability. Implement an export endpoint:

GET /api/v1/users/{id}/data-export
Accept: application/json

Response:
{
  "personal_data": {
    "name": "Jan Novák",
    "email": "[email protected]",
    "created_at": "2017-03-15T10:00:00Z"
  },
  "orders": [...],
  "preferences": {...},
  "consent_history": [...]
}

JSON or CSV format is sufficient. Export must be available within 30 days of the request.

Data Retention — Automatic Expiration¶

GDPR requires that personal data not be kept longer than necessary. Implement retention policies:

• TTL on database records
• Automatic cronjob for deleting/anonymizing expired data
• Different retention periods for different data types (accounting records 10 years, marketing consents until withdrawal)

Breach Notification — Detection and Reporting¶

Article 33 requires breach notification within 72 hours. This means you need:

• Detection — SIEM system (ELK Stack, Splunk) with alerts for anomalous PII access
• Classification — automatic determination of whether a breach involves personal data
• Incident response playbook — documented procedure for notifying the supervisory authority and data subjects

GDPR is an Opportunity, Not Just an Obligation¶

Technical GDPR implementation forces organizations to finally address problems they’ve been postponing for years — data governance, encryption, audit trail, clean APIs. Systems that undergo GDPR preparation will be more robust and secure. And that’s value that goes beyond compliance.

At CORE SYSTEMS, we help clients with technical GDPR implementation — from data mapping through anonymization pipelines to audit logging. Contact us if you need help before May 25th.