What is encryption?
Encryption makes data unreadable with a key, and only someone holding the matching key can turn it back. Encryption protects the confidentiality of data in transit, at rest and when it is passed on. Article 32(1)(a) of Regulation (EU) 2016/679 (GDPR) lists “the pseudonymisation and encryption of personal data” among the measures for the security of processing.
How encryption is embedded in an information security management system is covered in the guide to ISMS implementation.
Symmetric for data, asymmetric for exchanging keys
Symmetric and asymmetric methods solve different problems, which is why they are combined.
| Feature | Symmetric | Asymmetric |
|---|---|---|
| Key | one shared key for encryption and decryption | a key pair of public and private key |
| Speed | high, suitable for large volumes of data | considerably slower |
| Core problem | exchanging the shared key securely | binding the public key to an identity |
| Use | storage media, databases, archives, backups | key exchange, signatures, certificates |
Transport protocols such as TLS combine the two: an asymmetric method negotiates a symmetric session key, which then encrypts the actual data.
Where does an organisation need to encrypt?
Encryption applies at three points, and each protects against a different risk:
- In transit, it protects connections between user and application and between systems, including inside your own network.
- At rest, it protects storage media, databases, backups and archives against theft and improper disposal as long as the system is switched off or locked; while it runs, access control decides.
- When data is passed on, it protects file transfers, email attachments and shipped storage media on the way to the recipient.
Which of these points a data set needs follows from its rating in data classification.
Key management: what BSI module CON.1 requires
Key management decides whether encryption works. Module CON.1 Kryptokonzept (cryptography concept) of the IT-Grundschutz Compendium, 2023 edition, sets out the following in basic requirements A2 and A4:
- It must be defined how keys and certificates are generated, stored, exchanged and deleted or destroyed.
- The integrity and authenticity of keys must be ensured, including for third parties' public keys.
- A key should serve only one purpose where possible; encryption and signing should use different keys.
- A procedure should be defined for a private key that has been disclosed.
- Long-lived keys must be kept offline, outside the IT systems in use.
- Information stored in encrypted form must remain accessible over long periods.
The last point makes encryption an availability matter too: lose the key and you lose the data. These decisions belong in a cryptography policy.
TR-02102: the reference for methods and key lengths
For choosing methods and parameters, the BSI publishes Technical Guideline TR-02102. The guideline has four parts, all at version 2026-01 (as of October 2026).
| Part | Subject |
|---|---|
| TR-02102-1 | Recommendations on cryptographic mechanisms and key lengths |
| TR-02102-2 | Use of Transport Layer Security (TLS) |
| TR-02102-3 | Use of IPsec and IKEv2 |
| TR-02102-4 | Use of Secure Shell (SSH) |
CON.1.A1 requires established algorithms that the expert community has examined intensively, and the key lengths recommended at the time. The longer the period of use, the longer the keys should be. Under CON.1.A15 the organisation should check at least once a year whether its methods and parameters are still sufficiently secure.
Is encryption mandatory under the GDPR?
Article 32(1) GDPR makes the choice of measures depend on the risk. The yardstick is a level of security appropriate to the risk. It is assessed against the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the likelihood and severity of the risk.
Encryption appears in point (a) among the measures included “inter alia as appropriate”; the German text has “unter anderem” without the qualifier. Whether a particular data set has to be encrypted is therefore decided by the risk assessment for that processing. The entry on technical and organisational measures places the options in context.
For essential and important entities, § 30(2) sentence 2 no. 8 BSIG (the German BSI Act) goes further: their measures must at least include concepts and processes for the use of cryptographic methods. What is required, then, is a concept; a method that happens to be switched on is not enough.
Notification duties: encryption only lifts the duty to inform data subjects
After a personal data breach, encryption affects the two GDPR notification duties differently.
| Duty | When it falls away | Role of encryption |
|---|---|---|
| Notification to the supervisory authority, Art. 33(1) | where the breach is unlikely to result in a risk to the rights and freedoms of natural persons | supports the risk assessment but does not replace it |
| Communication to data subjects, Art. 34(3)(a) | where appropriate measures were applied to the affected data that render it unintelligible to unauthorised persons | named expressly: “such as encryption” |
The exception in Article 34 requires the encryption to have been applied to exactly the data affected. If the keys were exfiltrated as well, the data is no longer unintelligible to unauthorised persons, and the exception does not apply. Under Article 34(4) the supervisory authority can still require the communication, or decide that the conditions of the exception are met.
Evidencing encryption per system: Rizzqo
Rizzqo carries the cryptography requirements from ISO/IEC 27002 on every system they are assigned to through category or subcategory. Evidence can be attached there, such as a web service's TLS configuration or the entry in the crypto inventory. When a system's category or subcategory changes, its requirement list adjusts.
The owner answers the requirement and finalises the answer with a name and a timestamp. Rizzqo computes coverage from the finalised answers, system by system.