Encryption

Encryption is the technical foundation of any serious data protection strategy. We rely on multi-layered architectures with industry-proven methods to protect data at every stage of its lifecycle.

Encryption transforms readable data into an unreadable form that can only be restored with the correct key. It is the most fundamental technical safeguard against unauthorised access — and a non-negotiable component of every system we build at Parlant GmbH.

The regulatory framework and our methodological approach to data protection are described in a separate article. Here, we concentrate on the technical implementation.

Which Data Categories Do We Protect?

Not all data requires the same level of protection, but all data deserves a conscious decision about its treatment. In practice, we regularly encounter the following categories:

  • Personal data — Names, addresses, contact details, identification numbers. GDPR-relevant data requiring encryption and access control.
  • Health data — Particularly sensitive data under Art. 9 GDPR and HIPAA. The highest requirements for encryption and auditability apply here.
  • Financial data — Payment information, account data, transaction histories. Regulated by PCI DSS, among others.
  • Trade secrets — Strategic documents, algorithms, customer lists, pricing structures. Their protection serves not only compliance but economic survival.
  • Infrastructure credentials — API keys, database passwords, certificates. A compromised credential can open access to entire systems.

For each category, we define appropriate protection measures — from the choice of encryption method to the granularity of access control.

Symmetric Encryption with AES-256

AES-256 (Advanced Encryption Standard with 256-bit key length) is the industry standard for symmetric encryption and is recommended, among others, by the National Institute of Standards and Technology (NIST). With its 256-bit key length, AES-256 is considered resistant to brute-force attacks — even accounting for foreseeable advances in quantum computing.

We use AES-256 in Galois/Counter Mode (GCM), which ensures not only confidentiality but also the integrity and authenticity of the encrypted data. GCM produces an authentication tag with every encryption operation that can detect any tampering with the data.

Typical use cases in our projects include encrypting database fields, files, API payloads, and configuration values.

Envelope Encryption

Using individual keys for large volumes of data is neither secure nor practical. Envelope encryption solves this problem through a hierarchical key architecture:

Data Encryption Keys (DEK) — Each record is encrypted with its own DEK. The DEK is generated locally, is short-lived, and is stored alongside the encrypted data — but never in plaintext.

Key Encryption Keys (KEK) — The DEK is in turn encrypted (wrapped) with a higher-level KEK. Only those with access to the KEK can decrypt the DEK and thereby read the actual data.

This architecture offers several advantages:

  • Key isolation — If a single DEK is compromised, only the associated record is affected, not the entire system.
  • Efficient rotation — KEKs can be rotated without re-encrypting all data. Only the DEKs are wrapped with the new KEK.
  • Performance — The actual data encryption is performed locally with a symmetric key. The more expensive process of key decryption via the KEK involves only a few bytes.

We generate a new DEK for every write operation and never reuse the same DEK for data belonging to different users or tenants. This practice eliminates the need for DEK rotation and reduces the risk of key reuse to zero.

Key Management

The strongest encryption is worthless if the keys are poorly managed. Key management encompasses the entire lifecycle of cryptographic keys — from generation through use and rotation to secure destruction.

Key Management Systems (KMS) — We use dedicated KMS solutions that centralise all key operations. This enables uniform access policies, comprehensive auditing, and automated rotation. Depending on project requirements, we use cloud-native KMS services (e.g. Google Cloud KMS, AWS KMS) or self-hosted solutions.

Hardware Security Modules (HSM) — For use cases with the highest security requirements, root keys are stored in HSMs certified to FIPS 140-2 Level 3 or higher. HSMs ensure that keys never leave the protected boundary in plaintext.

Key rotation — KEKs are rotated regularly. Our system supports seamless rotation without downtime: new data is encrypted with the current KEK, while existing data can be re-encrypted asynchronously. If a compromise is suspected, an immediate rotation is triggered.

Access control — Access to keys is strictly limited to authorised services and personnel. We implement role-based access control (RBAC) and, for particularly critical keys, apply the split knowledge and dual control principles.

Auditing — Every key operation — generation, use, rotation, destruction — is logged without gaps. These audit trails are relevant not only for internal security but also fulfil reporting obligations towards regulators and auditors.

Encryption in Transit and at Rest

Data must be protected at every stage — both during transmission and during storage:

Encryption in transit — All data transmissions use TLS 1.3 or higher. For communication between internal services, we use mutual TLS (mTLS), where both parties authenticate each other. This prevents man-in-the-middle attacks even within the internal network.

Encryption at rest — Data is encrypted at the storage level as standard — at the database level, at the filesystem level, or both. The choice depends on the threat model: database-field encryption also protects against privileged database administrators, while filesystem encryption protects against physical theft.

Application-layer encryption — For particularly sensitive data, we encrypt at the application level before the data reaches the database. This way, data remains protected even if infrastructure encryption fails or is bypassed — defence in depth.

Our Approach in Practice

Encryption at Parlant GmbH is not an optional extra but an integral part of every project. In developing Formfix, we use envelope encryption with our own key management to protect application data in the public sector. In our cloud projects — from the platform for Openhealthtechnologies to the data mesh for Peek & Cloppenburg — the correct configuration of encryption at all levels is part of the infrastructure automation.

We navigate the right solution for every situation and data constellation — whether personal data, health data, or trade secrets. The combination of regulatory understanding and technical depth enables us to find the right architecture quickly, efficiently, and above all securely.

The overarching framework — which regulations apply, how we evaluate providers, and how data protection feeds into our development processes — is described in our article on Data Protection and Security.