Přeskočit na obsah
_CORE
AI & Agentic Systems Core Informační Systémy Cloud & Platform Engineering Data Platforma & Integrace Security & Compliance QA, Testing & Observability IoT, Automatizace & Robotika Mobile & Digital Banky & Finance Pojišťovnictví Veřejná správa Obrana & Bezpečnost Zdravotnictví Energetika & Utility Telco & Média Průmysl & Výroba Logistika & E-commerce Retail & Loyalty
Reference Technologie Blog Knowledge Base O nás Spolupráce Kariéra
Pojďme to probrat

GDPR a IT systémy — technická příprava na nařízení

10. 05. 2018 4 min čtení CORE SYSTEMSai
  1. května 2018 vstupuje v platnost GDPR — General Data Protection Regulation. Dva týdny před deadlinem shrnujeme konkrétní technická opatření, která musí IT systémy splňovat. Žádná právnická teorie, jen kód, architektura a nástroje.

Proč je GDPR technický problém

GDPR není jen záležitost právního oddělení. Články 25 (Data Protection by Design) a 32 (Security of Processing) explicitně vyžadují technická opatření. Pokud váš systém neumí smazat osobní údaje konkrétního uživatele, máte problém — bez ohledu na to, kolik consent formulářů máte na webu.

Pokuty až 20 milionů EUR nebo 4 % celosvětového obratu nejsou teoretická hrozba. Irský a francouzský úřad pro ochranu údajů už oznámily, že budou aktivně kontrolovat. Česká republika sice avizovala „měkký start”, ale to neznamená, že můžete ignorovat technické požadavky.

Mapování osobních údajů

Prvním krokem je data inventory — zmapování, kde všude se osobní údaje nacházejí. Typický enterprise systém má data roztroušená v:

  • Relační databáze — primární úložiště, tabulky customers, users, orders
  • Full-text indexy — Elasticsearch, Solr často indexují jméno, email, adresu
  • Cache vrstvy — Redis, Memcached mohou držet session data s PII
  • Logy — aplikační logy běžně obsahují IP adresy, user-agent, někdy i jména
  • Zálohy — databázové dumpy obsahují kompletní kopii dat
  • Message queues — Kafka topics, RabbitMQ fronty s business events

Doporučujeme vytvořit data flow diagram, který ukáže cestu osobních údajů celým systémem. Bez tohoto diagramu nemůžete spolehlivě implementovat právo na výmaz.

Právo na výmaz — technická implementace

Článek 17 GDPR dává subjektům právo na vymazání jejich osobních údajů. Technicky to znamená:

-- Soft delete s anonymizací
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;

-- Kaskádová anonymizace v souvisejících tabulkách
UPDATE orders SET
    shipping_name = 'DELETED',
    shipping_address = 'DELETED'
WHERE customer_id = :customer_id;

Proč ne hard delete? V mnoha systémech existují referenční integritní vazby, účetní záznamy a audit trail, které nemůžete jednoduše smazat. Anonymizace je GDPR-kompatibilní alternativa — data přestanou být osobní.

Nezapomeňte na propagaci výmazu do všech subsystémů: Elasticsearch index, Redis cache, Kafka consumer groups. Implementujte asynchronní „deletion event”, který všechny systémy odebírají.

Šifrování dat — at rest i in transit

GDPR výslovně zmiňuje šifrování jako příklad vhodného technického opatření (článek 32, odstavec 1a).

  • In transit — TLS 1.2+ pro veškerou komunikaci, včetně interních služeb. Mutual TLS mezi mikroslužbami (viz náš článek o Istio).
  • At rest — Transparent Data Encryption (TDE) na úrovni databáze. PostgreSQL podporuje pgcrypto, MySQL má InnoDB tablespace encryption.
  • Application-level encryption — pro zvlášť citlivá data (rodné číslo, zdravotní záznamy) šifrujte na aplikační úrovni s dedikovaným key management systémem (HashiCorp Vault, AWS KMS).

Pseudonymizace

GDPR explicitně zmiňuje pseudonymizaci jako technické opatření, které snižuje riziko pro subjekty údajů. Pseudonymizovaná data stále spadají pod GDPR, ale riziko při úniku je výrazně nižší.

# Pseudonymizace pomocí HMAC
import hmac, hashlib

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

# Originál: jan.novak@firma.cz
# Pseudonym: a3f8b2c1d4e5f6a7

Klíč pro reverzní mapování uchovávejte odděleně od pseudonymizovaných dat — ideálně v HSM nebo key management systému. Bez klíče jsou data nevratně anonymní.

Audit logy a Data Processing Records

Článek 30 vyžaduje záznamy o zpracování. Implementujte audit log, který zaznamenává každý přístup k osobním údajům:

  • Kdo přistupoval (user ID, role)
  • Kdy (timestamp s timezone)
  • K čemu (jaká data, jaký subjekt)
  • Proč (právní základ — souhlas, plnění smlouvy, oprávněný zájem)
  • Co udělal (read, update, delete, export)

Audit log musí být immutable — append-only storage. Doporučujeme dedikovaný log store (Elasticsearch s write-once indexy, nebo blockchain-inspired hash chain).

Technicky potřebujete systém, který:

  • Uchovává granulární souhlasy — zvlášť pro marketing, analytics, third-party sharing
  • Zaznamenává verzi podmínek, se kterými uživatel souhlasil
  • Umožňuje odvolání souhlasu s okamžitou propagací do všech zpracovávajících systémů
  • Poskytuje API pro kontrolu platnosti souhlasu před každým zpracováním

Data portability — export ve strojově čitelném formátu

Článek 20 dává subjektům právo na přenositelnost údajů. Implementujte export endpoint:

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

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

JSON nebo CSV formát je dostatečný. Export musí být dostupný do 30 dnů od žádosti.

Retence dat — automatická expirace

GDPR vyžaduje, aby osobní údaje nebyly uchovávány déle, než je nutné. Implementujte retention policies:

  • TTL na databázových záznamech
  • Automatický cronjob pro mazání/anonymizaci expired dat
  • Různé retention periody pro různé typy dat (účetní záznamy 10 let, marketingové souhlasy do odvolání)

Breach notification — detekce a reporting

Článek 33 vyžaduje oznámení úniku do 72 hodin. To znamená, že potřebujete:

  • Detekci — SIEM systém (ELK Stack, Splunk) s alerty na anomální přístupy k PII
  • Klasifikaci — automatické určení, zda únik zahrnuje osobní údaje
  • Incident response playbook — zdokumentovaný postup pro notifikaci ÚOOÚ a subjektů

GDPR je příležitost, ne jen povinnost

Technická implementace GDPR nutí organizace konečně řešit problémy, které odkládaly roky — data governance, šifrování, audit trail, čisté API. Systémy, které projdou GDPR přípravou, budou robustnější a bezpečnější. A to je hodnota, která přesahuje compliance.

V CORE SYSTEMS pomáháme klientům s technickou implementací GDPR — od data mappingu přes anonymizační pipeline až po audit logging. Ozvěte se, pokud potřebujete pomoc před 25. květnem.

gdprcompliancesecuritydata protection