---
status: "Proposed"
date: 2026-02-25
decision-makers: Ethan, Dave, Eliana
---

# New Data Encryption Architecture 

## Context and Problem Statement

We currently encrypt sensitive data fields (such as emails, phone numbers, and preferences) and fields containing secrets (such as passwords and external API keys for Data Subject Requests integrations) before writing them to the database. 

The primary problems with the current approach are:
- **Single Key Usage**: A single encryption key is currently utilized to both encrypt and decrypt all of this data.
- **Plain-Text Environment Variables**: The encryption key is injected into the application as a plain-text environment variable at deployment time.
- **Security Vulnerabilities**: Relying on environment variables for secrets management is an anti-pattern in cloud security because they are globally accessible to all processes on the same machine. The key is highly susceptible to exposure via customers’ CI/CD pipelines, application logs, crash dumps, or child processes. If an attacker gains minor remote code execution (RCE) access, they could dump the environment variables, capture the key, and move laterally across the infrastructure.
- **Operational Bottlenecks:** The current setup does not easily support regular key rotation without incurring the massive computational cost of re-encrypting the underlying database records.


## Considered Options

* Implement an Envelope Encryption architecture 
* Implement key rotation capabilities for the current encryption architecture 

## Decision Outcome

We will implement an **Envelope Encryption architecture** and add support for utilizing dedicated secret managers. This new architecture eliminates the risks of plain-text key exposure and  supports seamless key rotation without requiring to re-encrypt all the data. Because the underlying data is encrypted by the Data Encryption Key (DEK), rotating the Key Encryption Key (KEK) leaves the database records completely untouched, successfully avoiding significant system downtime.

We will keep our (thus far undocumented) convention to encrypt all personal data and PII at application-level by default; we will allow reasonable exceptions where there would be too high of a performance impact with an approval from the security team and engineering tech leadership.

The implementation plan will be executed in the following steps:
- Optimizing High-Volume Data: We will remove encryption entirely for the high-volume Consent Management Platform (CMP) v3 table (`privacy_preferences`). Because these fields are not highly sensitive, the overhead of encryption is not worth the negative impact on API performance.
- Seamless Legacy Migration: To avoid the massive operational burden of re-encrypting existing consent and DSR data, the consent v1 tables and DSR tables will use the current encryption key as their new DEK.
- Isolating High-Risk Secrets: For remaining encrypted columns containing highly sensitive data (passwords, API secrets), we will utilize a brand new, isolated DEK. We will also build a way to help existing customers perform a re-encryption with this new DEK.



## Pros and Cons of the Options

### Implement an Envelope Encryption architecture

Pros:
* Key rotation is seamless and does not require re-encrypting data
* We can avoid a one-off re-encryption of the large consent tables by using the current app encryption key as the DEK
* We can build in support for secret managers

Cons:
* Requires more implementation work
* Requires re-encrypting fields with secrets

### Implement key rotation capabilities for the current encryption architecture 

Pros:
* Faster to implement

Cons:
* Need to re-encrypt all fields every time key is rotated, including the large consent tables
* Still have the encryption keys as plaintext env vars
