ANSSI risk analysis on encryption: actions for GDPR Art. 32 and CSSF 22/806

On 27 May 2026, ANSSI released a new “Encryption and Cryptography — Risk Analysis” for non‑specialist decision‑makers, with concrete recommendations. Here is how to translate them into an at‑rest and in‑transit encryption architecture aligned with GDPR (Art. 32) and CSSF 22/806 for cloud. (ANSSI, IT Social)

Key facts

On 27 May 2026, ANSSI published an encryption risk analysis explicitly targeting organizations that use cryptographic solutions without being experts. The paper structures decisions (algorithm choices, key sizes, key governance, operational constraints) and sets a priority: prepare the post‑quantum transition in a controlled way, avoiding a big‑bang and keeping interoperability with current systems. It recalls risk prioritization criteria and measures in operational annexes. Official source: ANSSI, 27/05/2026. Press coverage: IT Social, 02/06/2026.

Earlier in 2026, ANSSI also published guidance on the evolution of TLS 1.3 to post‑quantum, confirming a gradual shift (hybrid approaches) with documented governance. (DataGuidance, 02/02/2026)

Applicable legal framework

GDPR — Article 32 (security of processing): controllers and processors must implement “appropriate technical and organizational measures,” including encryption where relevant. It is a risk‑based duty: state of the art, costs, processing nature, and risks to individuals. See GDPR Article 32 and the CNPD reference: CNPD — Chapter IV, Art. 32.

CSSF — Circular 22/806 (outsourcing and cloud): requires risk management and proportionate controls for ICT outsourcing, notably in cloud, including data‑in‑transit and at‑rest protection, key governance, data location, and continuous oversight. Official text: CSSF 22/806.

In short: ANSSI provides the updated technical baseline, GDPR Art. 32 sets the security level (including encryption), and CSSF details the operational expectations for outsourced/cloud environments.

The technical solution to deploy

Goal: document and deploy a coherent encryption architecture aligned with ANSSI, GDPR Art. 32 and CSSF 22/806, covering data at‑rest, in‑transit, and the key lifecycle.

• In‑transit encryption: standardize on TLS 1.3 with strong cipher suites, PFS enabled, and post‑quantum hybrid preparation on exposed endpoints (web fronts, APIs, VPN), per ANSSI guidance. Map critical flows (B2B interop, mainframe, IoT) and plan protocol upgrades. (ANSSI via DataGuidance)
• At‑rest encryption: combine envelope encryption (object/table‑level DEKs encrypted by a KMS‑KEK) with certified HSMs for trust anchoring. Use native encryption of RDBMS, virtual volumes and object storage, with role separation (secops ≠ DBA ≠ cloud admin). See CSSF 22/806 for cloud outsourcing. (CSSF 22/806)
• Key governance (KMS): key classes, sizes, lifetimes, rotation, revocation, encrypted backups and tamper‑evident logging for usage (forensics). Restrict key export, enforce least privilege on KMS APIs.
• Trust zone segmentation: isolate the crypto control plane (KMS/HSM) from the data plane, with dedicated network and IAM controls (restricted service accounts, mTLS between services).
• Inventory and evidence: CMDB of encrypted data and flows, configuration attestation (TLS scanners, KMS baselines), and restore/readability tests for encrypted archives.
• Post‑quantum roadmap: inventory cryptographic dependencies, prefer hybrid mechanisms when available, and prepare pilots (e.g., PQC‑hybrid TLS endpoints) with fallback criteria. Aligned with ANSSI. (ANSSI 27/05/2026)

Standards references: ISO/IEC 27001 Annex A (A.8.24 cryptography, A.5.15 access control, A.8.9 secret management), NIST CSF 2.0 (PR.DS‑1/2, PR.PS‑3), and ENISA best practices on data at‑rest/in‑transit protection (encryption, key management, resilience). (ENISA, 2025 — technical guidance)

How Luxgap implements this

• Our ISO 27001 governance: a “crypto policy” (algorithms, sizes, uses), a cryptographic asset register, and compliance evidence (TLS config reviews, KMS/HSM status, access reports). Our Lead Implementers orchestrate risk → control → evidence, as required by GDPR Art. 32 and CSSF 22/806.
• Our outsourced DPO and outsourced CISOs: legal‑to‑technical translation; documenting “state‑of‑the‑art” choices, DPIAs where needed, outsourcing clauses (key access, location, incident assistance), and verification of cloud right‑to‑audit.
• Our Managed SOC: monitoring crypto components (KMS/HSM), detecting key/token abuse, TLS configuration controls, and timestamped evidence useful in incidents (GDPR Art. 33, sector regulatory reporting).

In practice: we start with crypto discovery (where, what, how), then an ANSSI‑aligned decision matrix (risks/constraints/interop), and a prioritized technical batch: TLS hardening, KMS baselines, role separation, then targeted post‑quantum pilots.

Realistic EU/Luxembourg case

Realistic example: a Luxembourg management company (subject to CSSF 22/806) runs a cloud analytics data lake and EU partner APIs. In 6 weeks:

1. Map flows and sensitive datasets; document the “crypto everywhere” requirement under GDPR Art. 32.
2. Uniform TLS 1.3 on APIs, disable weak suites, mTLS between internal microservices.
3. Deploy envelope encryption with managed KMS and HSM anchoring, automatic KEK rotation, and SOC‑monitored key usage logs.
4. Update outsourcing contracts (key access, logs, notification assistance), aligned with CSSF 22/806.
5. Run PQC‑hybrid pilots on exposed endpoints (partner API fronts) with acceptance and rollback criteria.

Outcome: demonstrable compliance (evidence files, config registers), reduced attack surface (secrets, keys, network paths), and a credible post‑quantum trajectory without service disruption.

First concrete steps

• This week, run external/internal TLS scans: inventory hosts, versions, suites. Prioritize upgrades to TLS 1.3.
• Establish a simple crypto policy (algorithms, sizes, roles, rotations, logging) based on ANSSI’s analysis.
• Enable envelope encryption for sensitive stores (databases, objects, volumes) with a KMS and centralized usage logs.
• Separate control/data planes: dedicated IAM for KMS/HSM, limited service accounts, mTLS between critical services.
• Appoint a post‑quantum lead: map crypto dependencies, target 1–2 hybrid pilots (e.g., exposed TLS endpoints), and define evaluation criteria.

Official sources

• ANSSI — “Encryption and Cryptography” Risk Analysis (27 May 2026)
• CSSF — Circular 22/806 (outsourcing/Cloud)
• CNPD — GDPR, Chapter IV (incl. Article 32 Security of processing)
• DataGuidance — ANSSI: TLS 1.3 post‑quantum transition guide (02/02/2026)
• IT Social — ANSSI: start the post‑quantum transition (02/06/2026)
• ENISA — Technical implementation guidance on cybersecurity risk management measures (2025)