Encryption at Rest and in Transit

Encryption at Rest and in Transit: A CDPSE Privacy Engineering Guide

Introduction
Encryption is one of the most important technical controls a privacy engineer uses to protect personal data. In the ISACA Certified Data Privacy Solutions Engineer (CDPSE) exam, encryption sits within the Privacy Architecture and Data Lifecycle domains. It is a key part of privacy by design.

You need to know what encryption at rest and in transit are. You also need to know when to use each, how keys are managed, and how encryption supports regulatory compliance.

Why Encryption at Rest and in Transit Is Important

1. Protects confidentiality of personal data. Encryption makes data unreadable to anyone without the decryption key. Lost laptops, stolen backups, intercepted network traffic and compromised databases are far less harmful when the data is encrypted.

2. Supports legal and regulatory compliance. Many laws and frameworks name encryption as an appropriate technical safeguard:
- GDPR Article 32 lists encryption and pseudonymisation as measures to ensure security of processing.
- HIPAA treats encryption as an addressable implementation specification.
- PCI DSS requires strong cryptography for cardholder data stored and transmitted over open, public networks.
- CCPA/CPRA and various US state breach laws are also relevant.

3. Breach notification safe harbor. Under several regimes, a breach of properly encrypted data may not require notification to individuals, provided the keys were not also compromised. Examples include GDPR Article 34(3)(a) and many US state breach laws. This can greatly reduce regulatory, financial and reputational impact.

4. Reduces risk across the data lifecycle. Personal data moves through several stages: collection, transmission, storage, processing, sharing, archiving and destruction. Encryption protects data in two of the most exposed states: when it is stored and when it moves.

5. Enables trust in third-party and cloud environments. When data is hosted by cloud providers or processors, encryption (especially with customer-managed keys) helps the controller keep control over who can access it.

6. Supports crypto-shredding. Destroying the encryption keys can render data permanently unrecoverable. This supports data minimisation, retention limits and the right to erasure.

What It Is

Data States
Data exists in three states:
- Data at rest: data stored on a physical or logical medium. Examples include databases, file systems, hard drives, SSDs, USB drives, backup tapes, cloud object storage and mobile devices.
- Data in transit (in motion): data moving between locations. Examples include across the internet, within internal networks, between applications, via APIs, email or file transfers.
- Data in use: data being actively processed in memory or CPU. Protection here relies on newer technologies such as confidential computing, trusted execution environments (TEEs), homomorphic encryption and secure multi-party computation.

Encryption at Rest
This protects stored data so that someone with physical or logical access to the storage cannot read it without the key. Common forms:
- Full Disk Encryption (FDE): encrypts the entire drive (e.g., BitLocker, FileVault, LUKS). It protects against device loss or theft, but data is transparent once the system is booted and the user is authenticated.
- File or folder level encryption: encrypts individual files or directories (e.g., EFS, PGP-encrypted files).
- Database encryption:
  - Transparent Data Encryption (TDE) encrypts database files and logs at the storage layer.
  - Column or field level encryption encrypts specific sensitive fields such as SSNs or card numbers.
  - Application-level encryption means the application encrypts data before it reaches the database.
- Storage or volume encryption in the cloud: provider-managed encryption of storage volumes and object stores.
- Backup and archive encryption: protects tapes, offsite copies and long-term archives.
- Mobile device and removable media encryption: often enforced via MDM policies.

Encryption in Transit
This protects data as it travels across networks against eavesdropping, interception and man-in-the-middle attacks. Common forms:
- TLS (Transport Layer Security): secures HTTPS, SMTP with STARTTLS, APIs and more. TLS 1.2 is the minimum acceptable version; TLS 1.3 is preferred. SSL and early TLS (1.0/1.1) are deprecated.
- IPsec VPNs: encrypt traffic at the network layer between sites or for remote users.
- SSH, SFTP and FTPS: secure remote administration and file transfers.
- S/MIME and PGP: end-to-end email encryption.
- End-to-end encryption (E2EE): only the communicating endpoints can decrypt, not intermediaries or service providers.
- Mutual TLS (mTLS): both client and server authenticate with certificates. It is common in microservices and zero-trust architectures.
- Wireless encryption: WPA2/WPA3 for Wi-Fi.

How It Works

Symmetric Encryption
The same key encrypts and decrypts data. It is fast and efficient, so it is ideal for bulk data, especially at rest. The standard algorithm is AES (128, 192 or 256-bit keys). AES-256 is widely recommended for sensitive personal data. Modes such as GCM provide both confidentiality and integrity (authenticated encryption). The main challenge is securely distributing and protecting the shared key.

Asymmetric Encryption
This uses a key pair: a public key to encrypt (or verify signatures) and a private key to decrypt (or sign). Examples are RSA and Elliptic Curve Cryptography (ECC). It is slower, so it is mainly used for key exchange, digital signatures and establishing secure sessions.

Hybrid Approach (how TLS works)
1. The client connects and the server presents its digital certificate, issued by a trusted Certificate Authority (CA).
2. The client validates the certificate (trust chain, expiry, hostname).
3. Asymmetric cryptography or ephemeral Diffie-Hellman (ECDHE) is used to agree on a shared session key securely.
4. Bulk data is then encrypted with a fast symmetric algorithm such as AES-GCM.
5. Message integrity is assured through authenticated encryption or MACs.

Ephemeral key exchange provides Perfect Forward Secrecy (PFS). If the server's long-term private key is later compromised, past sessions still cannot be decrypted.

Envelope Encryption (common at rest, especially in the cloud)
- A Data Encryption Key (DEK) encrypts the data.
- A Key Encryption Key (KEK), or master key, encrypts the DEK.
- The KEK is stored in a Key Management Service (KMS) or Hardware Security Module (HSM).
- This allows efficient key rotation and centralized control.

Key Management: The Heart of Encryption
Encryption is only as strong as its key management. Exam questions often focus here. Key lifecycle stages:
- Generation: use strong, random keys from approved generators, ideally within HSMs.
- Distribution: deliver keys securely to authorised systems.
- Storage: keep keys separate from the data they protect, using HSMs, KMS or vaults. Never hard-code keys in source code.
- Usage: apply least privilege, so only authorised services or users can use keys.
- Rotation: change keys periodically and after suspected compromise.
- Backup and escrow: avoid data loss when keys are lost.
- Revocation: withdraw compromised keys or certificates.
- Destruction: securely delete keys when no longer required, which enables crypto-shredding.

Supporting principles:
- Segregation of duties: key custodians should be different from data administrators.
- Split knowledge and dual control for master keys.
- Customer-managed keys (BYOK/HYOK): in cloud scenarios, organisations retain control so providers cannot freely access plaintext.

Encryption vs. Related Concepts
- Hashing: one-way and not reversible. Used for integrity and password storage, ideally with salt and slow algorithms such as bcrypt or Argon2. Hashing is not encryption.
- Tokenization: replaces sensitive data with non-sensitive tokens mapped in a secure vault. It is common for payment data and reduces scope.
- Pseudonymisation: replaces identifiers so data cannot be attributed to a person without additional information. Under GDPR, pseudonymised data, including encrypted data, is still personal data.
- Anonymisation: irreversible removal of identifiability. Truly anonymised data falls outside GDPR. Encrypted data is not anonymised, because it is reversible with the key.
- Masking: obscures data for display or testing purposes.

Limitations of Encryption
- FDE and TDE do not protect against authorised users, compromised applications or SQL injection, because data is decrypted transparently for legitimate sessions.
- Encryption in transit does not protect data once it lands at the endpoint.
- Poor key management, such as keys stored with data, defeats encryption.
- Weak or deprecated algorithms (DES, 3DES, RC4, MD5, SHA-1, SSL) offer inadequate protection.
- Encryption can hinder monitoring tools such as DLP or IDS unless TLS inspection is designed in, which itself raises privacy considerations.
- Quantum computing threatens current asymmetric algorithms, so organisations should plan for crypto-agility and post-quantum cryptography.

Privacy Engineering Considerations
- Classify data first, then apply encryption proportionate to sensitivity and risk.
- Document encryption requirements in privacy impact assessments (PIAs/DPIAs).
- Build encryption into system design rather than bolting it on later (privacy by design and by default).
- Include encryption and key management obligations in contracts with processors and cloud providers.
- Consider cross-border transfers. Strong encryption with keys held by the exporter can be a supplementary measure, for example after Schrems II.
- Ensure encryption of logs, backups, test environments and replicas, not just production.
- Validate implementations through audits, configuration scanning and penetration testing.

Exam Tips: Answering Questions on Encryption at Rest and in Transit

1. Identify the data state first. Read the scenario and decide whether the data is stored, moving or being processed.
- Laptops, databases, backups, USB drives or cloud storage point to at rest controls (FDE, TDE, field-level encryption).
- Web traffic, APIs, email, file transfers or remote access point to in transit controls (TLS, VPN, SFTP, mTLS).
- Analytics on sensitive data without exposing it points to in use technologies (homomorphic encryption, TEEs, MPC).

2. Key management is often the best answer. When a question asks for the MOST important factor in encryption effectiveness, it is usually secure key management. Look for these:
- Keys stored separately from data.
- HSM or KMS use.
- Segregation of duties.
- Rotation.
Answers such as 'use a longer key' are usually less correct if keys are poorly protected.

3. Watch for the 'stored with the data' trap. If encryption keys are on the same server or in the same database as encrypted data, the control is weak. The fix is to separate them.

4. Know what each control does NOT protect against.
- Full disk encryption protects against physical theft, not against a logged-in attacker or malware.
- TLS protects data on the wire, not on the endpoint.
Questions often test whether you understand these limitations.

5. Prefer current, strong standards. Choose AES-256, TLS 1.2/1.3, SHA-256 or higher, and RSA 2048+ or ECC. Reject DES, 3DES, RC4, MD5, SHA-1, SSLv3 and TLS 1.0/1.1.

6. Remember breach notification implications. If stolen data was strongly encrypted and the keys were not compromised, the best answer often notes that individual notification may not be required. You should still document the incident and assess risk.

7. Distinguish encryption from anonymisation. Encrypted personal data is still personal data, because it is reversible. Do not choose answers claiming encryption removes data from regulatory scope.

8. Think risk-based and lifecycle-wide. CDPSE favours answers that do these things:
- Start with data classification and inventory.
- Apply controls proportionate to risk.
- Cover the entire lifecycle, including backups, test data, logs and decommissioning.

9. Third parties and cloud. For questions about protecting data in a cloud provider's environment, the best answers usually include encryption with customer-managed keys plus contractual safeguards. To prevent the provider from accessing plaintext, choose client-side encryption or customer-held keys (HYOK).

10. Crypto-shredding for disposal. For erasing data in cloud or distributed environments where physical destruction isn't possible, destroying the encryption keys is a recognised approach.

11. End-to-end vs. transport encryption. If the scenario requires that intermediaries (including the service provider) cannot read messages, choose end-to-end encryption. TLS alone protects only each hop.

12. Look for qualifiers. Words like FIRST, BEST, MOST and PRIMARY matter:
- FIRST often points to classification or a risk assessment.
- BEST often points to the most comprehensive or root-cause control.
- PRIMARY purpose of encryption is confidentiality, though authenticated encryption and signatures also support integrity and non-repudiation.

13. Integrity and authentication. Digital signatures provide integrity, authentication and non-repudiation, but not confidentiality. Certificates and PKI validate identity in TLS. Expired or self-signed certificates in production are a red flag.

Sample Question Walkthrough
Question: An organisation encrypts its customer database using TDE. An attacker exploits a SQL injection vulnerability and extracts customer records in plaintext. Why did encryption fail to protect the data?
Reasoning: TDE protects files at the storage layer. The database engine decrypts data for authenticated queries, so a query through a vulnerable application returns plaintext.
Best answer: TDE protects data at rest against storage-level access, not against application-layer attacks. Field-level or application-level encryption plus secure coding would be needed.

Quick Revision Summary
- At rest: FDE, TDE, file, field and application encryption, backups, AES-256.
- In transit: TLS 1.2/1.3, VPN/IPsec, SSH/SFTP, mTLS, E2EE.
- In use: TEEs, homomorphic encryption, MPC.
- Symmetric for bulk data; asymmetric for key exchange and signatures; hybrid in TLS.
- Key management is critical: separate keys from data, use HSM/KMS, rotate, segregate duties, destroy securely.
- Encrypted data is still personal data, but strong encryption can provide breach notification relief.
- Always match the control to the data state, the threat and the risk.