Tech Due Diligence SEC-2: Data Encryption and Secrets Management
What This Control Requires
The assessor evaluates encryption practices for data at rest and in transit, key management procedures, secrets management for application credentials, and the overall approach to protecting sensitive data throughout the system.
In Plain Language
If your encryption is weak or your secrets are poorly managed, an attacker who gains any foothold can quickly escalate to full compromise. These are foundational controls that underpin everything else in your security posture. During a tech DD review, we check whether data is properly encrypted both at rest and in transit, whether encryption keys are managed with proper rotation and access controls, and whether application secrets (API keys, database credentials, tokens) live in a proper secrets management system rather than scattered across config files. We look at TLS configuration across external and internal communications, database and file storage encryption, application-level encryption for sensitive fields, key management practices (rotation schedules, access control, HSM usage), and how secrets are stored and accessed. We also check whether any secrets have been hard-coded in source code or committed to version control. Secrets management is a particularly common weak spot in startups and growth-stage companies. We regularly find API keys buried in source code, database passwords in .env files checked into Git, and encryption keys that have never been rotated. These findings are both immediate security risks and indicators of deeper cultural issues around security discipline.
How to Implement
Enforce TLS on all communications. External traffic must use TLS 1.2+ (preferably 1.3), and internal service-to-service traffic should also be encrypted, especially in shared hosting environments. Configure strong cipher suites, disable weak protocols, and automate certificate renewal so nothing expires unexpectedly. Turn on encryption at rest everywhere: enable storage-level encryption for all databases (RDS encryption, Azure TDE, etc.), encrypt object storage (S3 server-side encryption), and use full-disk encryption on all servers and workstations. For particularly sensitive fields like PII, financial data, or health data, add application-level encryption as a second layer of protection against database access compromise. Adopt a dedicated secrets management system - HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager. Every application credential, API key, encryption key, and certificate should live there, not in environment variables, config files, or source code. Set up key and credential rotation on a defined schedule. Encryption keys should rotate at least annually (more often for high-sensitivity data), database credentials quarterly, API keys whenever team members leave, and TLS certificates well before expiration. Scan your repositories for accidentally committed secrets using tools like GitGuardian, truffleHog, or git-secrets. Add pre-commit hooks to catch secrets before they land in version control. If you find secrets in Git history, rotate them immediately and consider rewriting history if the repository has ever been public. Document your encryption architecture clearly: what data is encrypted, where encryption is applied, which algorithms and key lengths are in use, how keys are managed, and who has access to key management systems. This documentation is one of the first things a DD reviewer will ask for. Apply least privilege to secrets access. Each service should only reach the secrets it actually needs. Audit access to the secrets management system regularly and set up alerts for unusual access patterns.
Evidence Your Auditor Will Request
- TLS configuration reports showing protocol versions and cipher suites
- Data-at-rest encryption configuration for databases and storage
- Secrets management system architecture and access controls
- Key rotation schedule and rotation history
- Source code secret scanning results and remediation records
Common Mistakes
- Secrets hard-coded in source code or committed to version control
- No dedicated secrets management system; secrets in plain-text env files
- Encryption keys never rotated since initial creation
- Internal service communication unencrypted in shared environments
- TLS misconfigured with outdated protocols or weak cipher suites
Related Controls Across Frameworks
Frequently Asked Questions
Are environment variables an acceptable way to manage secrets?
What if we find old secrets in our Git history?
Track Tech Due Diligence compliance in one place
AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.
Start Free Assessment