> Document Version: 1.0 Document Owner: Acme Inc Next Review Date: 2027-03-19

Last updated: 2026-03-19

Project: nextjs-saas-example

Organization: Acme Inc

## Related Documents

- Security Policy (`SECURITY.md`)
- Information Security Policy (`INFORMATIONSECURITYPOLICY.md`)
- Backup Policy (`BACKUP_POLICY.md`)

This Encryption Policy defines the encryption requirements for data at rest, data in transit, and key management procedures for Acme Inc's nextjs-saas-example application. It supports compliance with GDPR Article 32, SOC 2 CC6.1, ISO 27001 Annex A.10, and PCI DSS Requirement 3 & 4.

## 1. Encryption at Rest

All persistent data stores must encrypt data at rest using AES-256 or equivalent. The following table defines requirements per detected data store.

Data Store | Encryption Method | Recommendation | Key Type
--- | --- | --- | ---

### 1.1 Encryption Requirements by Data Type

Data Type | Minimum Encryption | Additional Requirements
--- | --- | ---
User credentials (passwords, tokens) | AES-256 + hashing (bcrypt/scrypt/argon2) | Never store plaintext; use one-way hash for passwords
Personal Identifiable Information (PII) | AES-256 at rest | Column-level encryption recommended; access logging required
Payment card data (PAN, CVV) | AES-256 + PCI DSS Req. 3 | Never store CVV; tokenize PAN; use PCI-compliant processor
Financial transaction data | AES-256 at rest | Audit trail required; key rotation every 12 months
Session data | AES-256 at rest | Short TTL; encrypted cookies with Secure + HttpOnly flags
OAuth tokens | AES-256 at rest | Encrypt in database; never log token values
AI training data / prompts | AES-256 at rest | Data minimization; purpose limitation per AI provider DPA
Audit logs | AES-256 at rest | Immutable storage recommended; integrity verification
Backups | AES-256 at rest | Encrypted independently of source; separate key from primary

## 2. Encryption in Transit

All data transmitted over a network must be encrypted using TLS 1.2 or higher. TLS 1.3 is recommended for all new deployments.

### 2.1 TLS Configuration Requirements

Requirement | Minimum | Recommended
--- | --- | ---
TLS version | TLS 1.2 | TLS 1.3
Certificate type | Domain Validated (DV) | Organization Validated (OV) or Extended Validation (EV)
Certificate authority | Trusted public CA | Trusted public CA with Certificate Transparency
Cipher suites | AEAD ciphers only | TLSAES256GCMSHA384, TLSCHACHA20POLY1305_SHA256
HSTS | Enabled | max-age=31536000; includeSubDomains; preload
Certificate pinning | Optional | Recommended for mobile apps and high-security APIs

### 2.2 In-Transit Requirements by Connection Type

Connection | Requirement | Verification
--- | --- | ---
Browser to application | TLS 1.2+ (HTTPS enforced) | HSTS header; redirect HTTP to HTTPS
Application to database | TLS 1.2+ (verify-full mode recommended) | Connection string parameter; certificate validation
Application to third-party APIs | TLS 1.2+ | Certificate validation; no self-signed certs in production
Internal service-to-service | TLS 1.2+ or mTLS | Mutual TLS for zero-trust architecture
Backup transfers | TLS 1.2+ or encrypted tunnel (VPN/SSH) | Encrypted before transfer; verify at destination
Payment processor communication | TLS 1.2+ (PCI DSS Req. 4) | PCI-validated endpoint; no fallback to HTTP
AI service API calls | TLS 1.2+ | Verify AI provider certificate; do not disable certificate validation

## 3. Key Management Procedures

### 3.1 Key Lifecycle

Phase | Requirement | Responsibility
--- | --- | ---
Generation | Use cryptographically secure random number generators (CSPRNG) | Security team
Storage | Keys must never be stored in source code, logs, or plaintext config files | Engineering team
Distribution | Use secure channels (KMS API, encrypted transfer) | Security team
Rotation | Rotate encryption keys on a defined schedule (see 3.2) | Security team + automation
Revocation | Immediately revoke compromised keys; re-encrypt affected data | Incident response team
Destruction | Securely destroy retired keys after retention period | Security team

### 3.2 Key Rotation Schedule

Key Type | Rotation Frequency | Trigger for Immediate Rotation
--- | --- | ---
Database encryption keys | Every 12 months | Key compromise, personnel departure
TLS certificates | Before expiry (auto-renew via ACME/Let's Encrypt) | Certificate compromise
API keys and secrets | Every 90 days | Key exposure in logs, code, or breach
Session signing keys | Every 30 days | Suspected session hijacking
Backup encryption keys | Every 12 months | Backup key compromise
Payment encryption keys | Every 12 months (PCI DSS Req. 3.6) | Key compromise; personnel with key knowledge leaves

### 3.3 Key Storage Requirements

Keys must be stored using one of the following approved methods:

1. Cloud Key Management Service (KMS) — AWS KMS, GCP KMS, Azure Key Vault
2. Hardware Security Module (HSM) — For highest-assurance requirements
3. Secrets Manager — AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault
4. Environment variables — Acceptable for non-sensitive keys in development only

Prohibited key storage:

- Source code repositories (even private repos)
- Unencrypted configuration files
- Application logs
- Email, chat, or shared documents
- Client-side code or mobile app bundles

## 4. Compliance Mapping

Regulation | Requirement | This Policy Section
--- | --- | ---
GDPR Article 32 | Encryption of personal data | Sections 1, 2
SOC 2 CC6.1 | Logical and physical access controls including encryption | Sections 1, 2, 3
ISO 27001 A.10 | Cryptographic controls | Sections 1, 2, 3
PCI DSS Req. 3 | Protect stored cardholder data | Section 1
PCI DSS Req. 4 | Encrypt transmission of cardholder data | Section 2
NIST SP 800-111 | Guide to storage encryption | Section 1
NIST SP 800-52 | TLS implementation guidelines | Section 2

## 5. Policy Review

This encryption policy must be reviewed:

- At minimum annually
- When new data stores or cloud services are added
- After any security incident involving data exposure
- When regulatory requirements change

For questions about this policy, contact legal@acme.com.

This Encryption Policy was generated by Codepliant based on an automated scan of the nextjs-saas-example codebase. It should be reviewed by your security and engineering teams and customized to reflect your actual encryption implementation.