---
title: "Encryption: Definition and Compliance Guide"
description: "Learn how encryption protects data at rest, in transit, and in use. Covers AES, RSA, TLS, key management, and compliance requirements under ISO 27001, SOC 2, NIS2, DORA, and GDPR."
canonical: https://www.orbiqhq.com/glossary/encryption
html: https://www.orbiqhq.com/glossary/encryption
publisher: Orbiq GmbH
language: en
---
# Encryption: Definition and Compliance Guide

Learn how encryption protects data at rest, in transit, and in use. Covers AES, RSA, TLS, key management, and compliance requirements under ISO 27001, SOC 2, NIS2, DORA, and GDPR.


## What Is Encryption?

Encryption is the process of converting readable data (plaintext) into an unreadable format (ciphertext) using a mathematical algorithm and a cryptographic key. Only authorised parties with the correct decryption key can reverse the process and access the original data.

For compliance and security teams, encryption is not optional — it is a foundational control required by virtually every major security framework and regulation.

## Types of Encryption

### Symmetric vs Asymmetric

| Property | Symmetric Encryption | Asymmetric Encryption |
| --- | --- | --- |
| **Keys** | Single shared key | Public-private key pair |
| **Speed** | Fast — suitable for bulk data | Slower — used for key exchange and signatures |
| **Common algorithms** | AES-128, AES-256, ChaCha20 | RSA-2048, RSA-4096, ECC P-256, Ed25519 |
| **Use cases** | Database encryption, disk encryption, file encryption | TLS handshake, digital signatures, PGP email |
| **Key distribution challenge** | Must securely share the key | Public key can be freely distributed |
| **Compliance standard** | AES-256 accepted universally | RSA-2048 minimum for most frameworks |

### Hybrid Encryption

Modern systems use **hybrid encryption** — asymmetric encryption to securely exchange a symmetric key, then symmetric encryption for the actual data. TLS (HTTPS) is the most common example: the TLS handshake uses RSA or ECC to agree on an AES session key.

## Encryption States

| State | What It Protects | Common Mechanisms | Compliance Requirement |
| --- | --- | --- | --- |
| **At rest** | Stored data — databases, files, backups | AES-256, LUKS, BitLocker, TDE, cloud KMS | ISO 27001 A.8.24, SOC 2 CC6.1, GDPR Art. 32 |
| **In transit** | Data moving between systems | TLS 1.2/1.3, IPsec, SSH, SFTP | ISO 27001 A.8.24, SOC 2 CC6.7, NIS2 Art. 21 |
| **In use** | Data being processed in memory | Confidential computing, Intel SGX, AMD SEV, homomorphic encryption | Emerging — not yet widely mandated |

### Encryption at Rest

Encryption at rest protects data stored on disk, in databases, or in cloud storage. Key approaches:

| Approach | Description | Best For |
| --- | --- | --- |
| **Full-disk encryption (FDE)** | Encrypts the entire storage volume | Laptops, workstations, portable devices |
| **File-level encryption** | Encrypts individual files or directories | Selective protection of sensitive files |
| **Database encryption (TDE)** | Transparent Data Encryption at the database engine level | Structured data in SQL/NoSQL databases |
| **Cloud-managed encryption** | Cloud provider encrypts storage automatically (AWS S3, Azure Blob) | Cloud-native workloads |
| **Application-level encryption** | Application encrypts data before writing to storage | Maximum control, field-level protection |

### Encryption in Transit

| Protocol | Version | Status | Notes |
| --- | --- | --- | --- |
| TLS | 1.3 | Recommended | Fastest, most secure, fewer round trips |
| TLS | 1.2 | Acceptable | Still widely used, configure strong cipher suites |
| TLS | 1.0, 1.1 | Deprecated | Must be disabled — known vulnerabilities |
| SSL | All | Obsolete | Never use — critically insecure |
| IPsec | IKEv2 | Recommended | VPN and network-level encryption |
| SSH | v2 | Required | Remote administration and file transfer |

## Cryptographic Algorithms: What to Use and What to Avoid

| Category | Recommended | Avoid |
| --- | --- | --- |
| **Symmetric** | AES-256-GCM, ChaCha20-Poly1305 | DES, 3DES, RC4, Blowfish |
| **Asymmetric** | RSA-2048+, ECC P-256+, Ed25519 | RSA-1024, DSA |
| **Hashing** | SHA-256, SHA-3, BLAKE2 | MD5, SHA-1 |
| **Key derivation** | Argon2, bcrypt, scrypt | PBKDF2 with low iterations, plain hashing |
| **MACs** | HMAC-SHA256, Poly1305 | HMAC-MD5 |

### Algorithm Selection Criteria

1. **Regulatory acceptance** — AES-256 and RSA-2048 are accepted by all major frameworks
2. **Performance requirements** — AES-GCM for server workloads, ChaCha20 for mobile/IoT
3. **Post-quantum readiness** — Monitor NIST PQC standards (CRYSTALS-Kyber, CRYSTALS-Dilithium)
4. **Key length** — Minimum 128-bit symmetric, 2048-bit RSA, 256-bit ECC

## Key Management

Encryption is only as strong as your key management. A perfectly encrypted database is worthless if the keys are stored in plaintext next to it.

### Key Lifecycle

| Phase | Best Practice | Common Mistake |
| --- | --- | --- |
| **Generation** | Use cryptographically secure random number generators (CSPRNG) | Using predictable seeds or weak RNGs |
| **Storage** | Store in HSM, cloud KMS, or dedicated vault (HashiCorp Vault) | Storing keys in source code, config files, or environment variables |
| **Distribution** | Use secure key exchange protocols (TLS, Diffie-Hellman) | Sending keys via email or chat |
| **Rotation** | Automate rotation on schedule and after incidents | Never rotating keys |
| **Revocation** | Immediately revoke compromised keys | Delayed revocation after breach |
| **Destruction** | Cryptographic erasure — securely destroy all copies | Leaving old keys accessible |

### Key Management Services

| Service | Type | Best For |
| --- | --- | --- |
| AWS KMS | Cloud-managed | AWS-native workloads |
| Azure Key Vault | Cloud-managed | Azure-native workloads |
| Google Cloud KMS | Cloud-managed | GCP-native workloads |
| HashiCorp Vault | Self-managed / SaaS | Multi-cloud, secrets management |
| Hardware Security Module (HSM) | Hardware | Highest assurance, regulatory requirements |

## Compliance Requirements

### Framework Mapping

| Requirement | ISO 27001 | SOC 2 | GDPR | NIS2 | DORA |
| --- | --- | --- | --- | --- | --- |
| Encryption at rest | A.8.24 | CC6.1 | Art. 32 | Art. 21(2)(d) | Art. 9(2) |
| Encryption in transit | A.8.24 | CC6.7 | Art. 32 | Art. 21(2)(d) | Art. 9(2) |
| Key management | A.8.24 | CC6.1 | Art. 32 | Art. 21(2)(d) | Art. 9(2) |
| Cryptographic policy | A.8.24 | CC6.1 | — | Art. 21(2)(h) | Art. 9(4)(c) |
| Algorithm standards | A.8.24 | CC6.1 | Recital 83 | Art. 21(2)(h) | Art. 9(4)(c) |
| Incident response for key compromise | A.5.26 | CC7.3 | Art. 33-34 | Art. 23 | Art. 19 |

### GDPR and Encryption

GDPR provides a strong incentive to encrypt personal data:

- **Article 32** — Lists encryption as an appropriate technical measure
- **Article 34 exemption** — If breached data was encrypted and keys remain secure, you may not need to notify individuals
- **Pseudonymisation** — Encryption supports GDPR's pseudonymisation requirements

### Audit Evidence for Encryption

| Evidence Type | Description | Framework |
| --- | --- | --- |
| Encryption policy document | Approved policy covering algorithms, key lengths, and management | ISO 27001, SOC 2 |
| Key management procedures | Documented lifecycle for generation, rotation, and destruction | All frameworks |
| TLS configuration scans | SSL Labs or similar scan results showing TLS 1.2+ | SOC 2, NIS2 |
| At-rest encryption proof | Cloud console screenshots or configuration exports | All frameworks |
| Key rotation logs | Automated rotation records from KMS | ISO 27001, SOC 2 |
| Certificate inventory | Complete list of all certificates with expiry dates | NIS2, DORA |
| Penetration test results | Testing encryption implementation effectiveness | ISO 27001, NIS2 |
| Crypto algorithm inventory | List of all algorithms in use with deprecation timeline | DORA, NIS2 |

## Common Mistakes

| Mistake | Risk | Fix |
| --- | --- | --- |
| Storing encryption keys alongside encrypted data | Breach exposes both data and keys | Use external KMS or HSM |
| Using deprecated algorithms (MD5, SHA-1, DES) | Known vulnerabilities, audit findings | Migrate to AES-256, SHA-256 minimum |
| Not encrypting backups | Backup theft exposes all data | Apply same encryption policy to backups |
| Hardcoding keys in source code | Keys leak through version control | Use secrets management (Vault, KMS) |
| Missing key rotation | Longer exposure window if key is compromised | Automate annual rotation minimum |
| TLS 1.0/1.1 still enabled | Compliance failure, known attack vectors | Disable and enforce TLS 1.2+ |
| No crypto algorithm inventory | Cannot prove compliance or plan migrations | Maintain and review quarterly |

## How Orbiq Supports Encryption Compliance

Orbiq helps you demonstrate and manage encryption controls:

- **Evidence collection** — Automatically gather encryption configuration evidence from cloud providers
- **Policy templates** — Pre-built cryptographic policy templates aligned to ISO 27001 and SOC 2
- **Continuous monitoring** — Track TLS configurations, certificate expiry, and encryption status
- **Trust Center** — Share your encryption posture with customers and auditors through your [Trust Center](/glossary/trust-center)
- **Audit readiness** — Map encryption controls to framework requirements with pre-built control mappings

## Further Reading

- [ISO 27001 Certification](/glossary/iso-27001-certification) — Framework requiring encryption controls
- [Data Classification](/glossary/data-classification) — Determine what data needs encryption
- [Access Control](/glossary/access-control) — Complement encryption with access restrictions
- [Incident Response](/glossary/incident-response) — Handle key compromise incidents
- [Cloud Security Posture Management](/glossary/cloud-security-posture-management) — Monitor cloud encryption configurations
- [SOC 2 Compliance](/glossary/soc-2-compliance) — Encryption requirements for SOC 2