OVG NRW (20 Feb 2025): no general obligation for end-to-end encryption

On 20 February 2025, the OVG North Rhine‑Westphalia (Münster) held there is no “general obligation” to use end‑to‑end encryption (E2E) for transmitting personal data: a properly configured transport encryption can be sufficient depending on risk (case 16 B 288/23). Here is how to implement “just‑enough” and robust encryption with audit‑ready evidence.

The facts

The court (ref. 16 B 288/23) rejected a claim for mandatory E2E and the argument that TLS 1.2 would be non‑compliant merely because TLS 1.3 exists. It reiterates that GDPR Article 32 requires “appropriate measures” based on risks and state of the art, without mandating a single mechanism; transport encryption may suffice context‑dependently. The reasoning references BSI IT‑Grundschutz (module CON.9 – Informationsaustausch).

Official source (full decision, German): NRW Justiz – OVG NRW, 16 B 288/23, 20.02.2025. News analysis: WBS Legal – OVG Münster: no general E2E obligation. Referenced BSI module: BSI IT‑Grundschutz – CON.9 Informationsaustausch.

Applicable legal framework

GDPR – Article 32: requires “appropriate” technical and organisational measures, considering state of the art, costs, context and risk. The OVG confirms adequacy is evidenced through documented risk analysis, correct protocol configuration and periodic reassessment. For a refresher, see the GDPR reference.

Luxembourg – CSSF 22/806 (outsourcing & cloud): the circular mandates confidentiality controls (encryption, key management) with clear responsibility split between entity and provider. Current version (Apr 2025): CSSF – Circular 22/806 and FAQ: CSSF FAQ 22/806.

Practical takeaway: the obligation is not “E2E everywhere” but proportionate, evidenced encryption: up‑to‑date in‑transit/TLS, sound at‑rest with key management, and E2E/overlay where risk warrants it.

The technical solution to deploy

Objective: demonstrate that your encryption is “appropriate” under GDPR Art. 32 and compatible with CSSF 22/806.

• In‑transit encryption: standardise TLS 1.3, harden suites (ECDHE + AES‑GCM/CHACHA20‑POLY1305), enable HSTS and OCSP stapling; for email, enforce MTA‑STS and DANE. The OVG recognises that state‑of‑the‑art transport encryption can suffice depending on context.
• At‑rest encryption: AES‑256 (or equivalent) for databases, disks and objects; network segmentation; key management with HSM/KMS, rotation, controlled escrow, and logging (aligned with ISO 27001 Annex A.8.24).
• Targeted E2E/overlay: S/MIME/PGP for high‑risk correspondence (health, trade secrets, HR), application tunnels (mTLS), client‑side encrypted mailboxes if threat model requires.
• Crypto governance: crypto and key management policy, crypto usage register, periodic reviews and threat watch (e.g., EPC guidance: EPC342‑08/2025). Governance can be led by an outsourced CISO to structure and evidence controls.

Control references: ISO/IEC 27001:2022 Annex A.8.24 (cryptography); NIST SP 800‑57 (key lifecycle); CIS Controls v8 – Control 3. Anticipate post‑quantum standardisation (NIST PQC 2024) and plan for crypto‑agility.

How Luxgap delivers this

• ISO 27001 governance: crypto policy, usage register, minimums (TLS 1.3, AES‑256, mTLS, MTA‑STS/DANE), E2E triggers, PQC migration plan.
• Outsourced DPO and CISO: processing mapping, GDPR Art. 32 risk assessment and DPIA, cloud shared responsibility (22/806) and contractual clauses (KMS, location, logs).
• Managed SOC (if required): certificate supervision, cipher drift, mTLS failures, detection of unencrypted exfiltration, and continuous compliance of gateways. Explore our managed SOC.

Pragmatic path: prioritise high‑risk flows, produce proofs on email gateways and application interconnects, then roll out in stages with measurable acceptance criteria.

Case study in Luxembourg/EU

For a Luxembourg financial institution (CSSF 22/806 scope) handling sensitive correspondence, we:

• Enforced TLS 1.3 (web/API), HSTS, and for email MTA‑STS/DANE on critical domains.
• Rolled out S/MIME for high‑risk use cases, with certificate management and training.
• Consolidated the cloud KMS (rotation, role separation, immutable logs) and created an auditable crypto register.

Outcome: demonstrable compliance with GDPR Art. 32 and CSSF 22/806, controlled operational load, and measurable maturity.

First concrete steps

1. Map data flows with personal data and qualify risk.
2. Harden in‑transit: enable TLS 1.3, remove weak ciphers, HSTS; for email, publish MTA‑STS and TLS‑RPT, assess DANE.
3. Secure at‑rest: AES‑256 (or equivalent), central KMS/HSM, rotation and least‑privilege access.
4. Define the crypto policy (ISO 27001 A.8.24): approved algorithms, key sizes and lifetimes, E2E triggers, exception process.
5. Address cloud outsourcing (CSSF 22/806): clarify encryption/key responsibilities in contracts, test reversibility, and record evidence (TLS reports, key inventory, access logs).

Official sources

• Decision: OVG Nordrhein‑Westfalen, 16 B 288/23, 20.02.2025.
• Analysis: WBS Legal – OVG Münster: no general E2E obligation.
• BSI reference: BSI IT‑Grundschutz – CON.9 Informationsaustausch.
• Luxembourg (regulatory): CSSF – Circular 22/806 and FAQ 22/806.
• Crypto best practices: EPC342‑08/2025 – Guidelines on Cryptographic Algorithms & Key Management.

Key message (May 2026): post‑OVG Münster, the expectation is not “E2E everywhere” but evidence that encryption is proportionate, up‑to‑date and governed — a programme that outsourced CISOs can drive in line with the GDPR.