Encryption: The Complete Guide for Compliance and Security Teams

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

Regulatory acceptance — AES-256 and RSA-2048 are accepted by all major frameworks
Performance requirements — AES-GCM for server workloads, ChaCha20 for mobile/IoT
Post-quantum readiness — Monitor NIST PQC standards (CRYSTALS-Kyber, CRYSTALS-Dilithium)
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
Audit readiness — Map encryption controls to framework requirements with pre-built control mappings