Introduction
Encryption and key management evidence for SOC 2 is the dated proof that your organization encrypts in-scope data where its policy says it will, protects the keys that make that encryption meaningful, keeps certificates and protocol settings current, and can show those settings stayed in place across the audit period.
Most SaaS teams already encrypt a lot by default. The audit gap is rarely "no encryption." It is that nobody can show which data stores are in scope, which ones are actually encrypted, who can use or change the keys, when keys were last rotated, and whether a certificate quietly expired last spring.
Here is a concrete example. An auditor selects your production customer database and asks how you protect it at rest and who can decrypt it. Strong evidence includes a data store inventory that lists the database and its classification, an exported configuration showing encryption at rest enabled with a named key, the key policy showing which roles can use and administer that key, rotation settings or rotation records, and change history showing the setting was not turned off during the period. Weak evidence is a screenshot of a console checkbox taken the day before fieldwork, with no answer to "who can use the key?"
In plain language: this guide is an evidence playbook for encryption settings, key management, and certificates over time. It is not a second definition of encryption. That glossary page explains what encryption is. This page explains what to keep so you can prove it worked for the whole period.
What Encryption and Key Management Evidence Means
Encryption evidence proves that in-scope data is protected at rest and in transit according to your written standard. Key management evidence proves that the keys behind that protection are generated, stored, accessed, rotated, and retired in a controlled way. Certificate evidence proves that the identities used for encrypted connections are valid and renewed before they lapse.
A complete encryption and key management file usually answers:
- Which data stores, services, and endpoints are in scope, and how is each one classified?
- Is each in-scope data store encrypted at rest, and with which type of key?
- Which connections carry in-scope data, and are they encrypted in transit with approved protocol versions?
- Where do keys live, who can use them, and who can administer or delete them?
- How often are keys rotated, and where is the record of rotation?
- Which certificates are in use, when do they expire, and who renews them?
- Which systems do not meet the standard, and is each gap documented as an approved exception with a plan?
- Can you show configuration history for the period, not just today's settings?
How This Guide Differs From Related Pages
| Page | Primary job | Use it when |
|---|---|---|
| What Is Encryption? | Defines encryption and its basic types | You need the concept and vocabulary |
| What Is Confidentiality? | Defines the confidentiality principle | You need the reason encryption matters for sensitive data |
| What Is Data Classification? | Defines how data is labeled by sensitivity | You need to decide which data requires which protection |
| Logging and Monitoring Evidence for SOC 2 | Log sources, alert rules, review cadence, triage | You are proving detection, including alerts on key and encryption changes |
| Change Management Evidence for SOC 2 | Approvals, testing, and deployment records | You are proving that configuration changes were controlled |
| This guide | Encryption settings, key access and rotation, certificates, exceptions, and Type 2 configuration history | You need the encryption and key management evidence playbook |
What SOC 2 Requires vs Common Practice
Keep the criteria and your chosen practices apart.
What the criteria address. The AICPA 2017 Trust Services Criteria with revised points of focus (2022) include themes that encryption and key management controls commonly support:
- CC6.1: implementing logical access security software, infrastructure, and architectures over protected information assets. Its points of focus include using encryption to supplement other measures that protect data at rest when that protection is appropriate based on assessed risk, and protecting encryption keys during generation, storage, use, and destruction.
- CC6.7: restricting the transmission, movement, and removal of information to authorized users and processes, and protecting it during transmission, movement, or removal. Its points of focus include using encryption technologies or secure communication channels to protect data.
- C1.1 and C1.2 (Confidentiality category, when in scope): identifying and maintaining confidential information, and disposing of it to meet confidentiality objectives.
Points of focus are illustrative, not a checklist. SOC 2 does not name an algorithm, a key length, a key management service, a rotation interval, or a minimum TLS version. Your auditor tests the controls you describe, so the criteria set the outcome and your written standard sets the specifics.
What is common practice, not a fixed SOC 2 rule:
- AES-256 for data at rest (a widely used choice, not a SOC 2 mandate)
- TLS 1.2 or higher for data in transit, with older protocol versions disabled
- Annual automatic rotation for customer-managed keys
- Keeping keys in a cloud key management service or hardware security module
- Automated certificate renewal with expiry alerts
If your policy says production data stores use customer-managed keys rotated annually and external endpoints accept only TLS 1.2 or higher, the evidence must show both for the sampled period.
For design input, NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management covers key types, cryptoperiods, and key lifecycle states. NIST SP 800-52 Rev. 2 gives guidance on selecting and configuring TLS. NIST SP 800-53 Rev. 5 includes system and communications protection themes such as transmission confidentiality and integrity, cryptographic key establishment and management, cryptographic protection, and protection of information at rest. Use them as reference points and map carefully to the controls you assert through control mapping.
The Encryption and Key Management File at a Glance
| Area | What to keep | Stronger evidence | Weaker evidence |
|---|---|---|---|
| Scope | Inventory of in-scope data stores and endpoints | Dated inventory with classification, owner, and encryption status | "Everything in the cloud is encrypted" |
| At rest | Encryption setting per data store | Exported configuration or compliance rule results over time | One console screenshot |
| In transit | Protocol and cipher settings per endpoint | Load balancer or gateway policy exports, external TLS scan results | A padlock icon in the browser |
| Key inventory | List of keys and what they protect | Key list with purpose, owner, type, and creation date | Keys nobody can map to a system |
| Key access | Who can use and administer keys | Key policies and role assignments, reviewed on a schedule | Broad admin roles with implied key access |
| Rotation | Rotation settings or records | Automatic rotation config or dated rotation tickets | "We rotate when needed" |
| Secrets | Where application secrets and keys live | Secrets manager records, scan results for secrets in code | Keys in environment files in a repository |
| Certificates | Inventory and renewal records | Certificate list with expiry dates, renewal automation, expiry alerts | An outage caused by an expired certificate |
| Changes | History of encryption and key changes | Change tickets plus cloud audit log entries | Settings that changed with no record |
| Exceptions | Systems that do not meet the standard | Approved exception with risk rationale, owner, and end date | Known gaps with no documentation |
Building the Evidence Step by Step
1. Inventory in-scope data stores and endpoints
Start from your system description and list every place in-scope data lives or moves: production databases and replicas, object storage, disks and snapshots, backups, queues and caches that hold customer data, analytics copies, public endpoints, internal service connections, and administrative access paths.
For each item, record its data classification, owner, and required protection. Backup and analytics copies are often missed, and auditors notice when the primary database is encrypted but last month's export sits in a bucket with default settings.
2. Write the encryption standard
Document what "encrypted" means for you: approved algorithms and key lengths, required encryption at rest by classification, minimum TLS version and approved ciphers, where keys must be stored, rotation intervals, certificate renewal expectations, and how exceptions are approved. Link it to your information security policy so the policy and the procedure say the same thing.
3. Evidence encryption at rest
For each in-scope data store, keep a configuration export or automated check result showing encryption is enabled and which key protects it. Note whether the key is provider-managed or customer-managed, since that affects who controls access and rotation. Where possible, use a recurring automated check so you have results across the period, not a single snapshot.
4. Evidence encryption in transit
Collect the settings that control transport encryption: load balancer and gateway TLS policies, database connection requirements, and internal TLS configuration where in scope. Add scheduled external TLS scan results for public endpoints, and confirm older protocol versions are disabled if your standard says so.
5. Build a key inventory
List the keys that protect in-scope data. For each key, record the purpose, the systems it protects, the type (provider-managed, customer-managed, or customer-supplied), the owner, the creation date, and the current state.
6. Control and review key access
Export the key policies and role assignments that show who can use each key and who can administer, disable, or schedule deletion. Separate those duties where your standard requires it, for example application roles that can encrypt and decrypt but cannot change key policy. Include key access in your recurring access reviews and apply least privilege. Departing engineers should lose key administration rights as part of onboarding and offboarding.
7. Rotate keys and keep the record
Show rotation the way you perform it. If automatic rotation is on, export the setting and the last rotation date. If rotation is manual, keep a dated ticket for each rotation with the key, the approver where required, and confirmation that dependent systems still work. NIST SP 800-57 frames rotation around cryptoperiods, but your written interval is what auditors test.
8. Keep secrets out of code
Application secrets, API keys, and private keys belong in a secrets manager or key management service. Keep evidence such as secrets manager usage, secret scanning on repositories, and tickets showing how detected secrets were revoked and replaced.
9. Track certificates
Maintain a certificate inventory with domain, issuer, expiry date, owner, and renewal method. Automate renewal where you can, alert well before expiry, and keep renewal records. Expired certificates cause outages.
10. Control encryption and key changes
Route changes to encryption settings, key policies, and TLS configuration through your change management process. Back that up with alerts on high-risk events such as a key being disabled or scheduled for deletion, encryption being removed from a storage resource, or a key policy being widened. The Logging and Monitoring Evidence for SOC 2 playbook covers how to evidence those alerts.
11. Document exceptions honestly
Some systems will not meet the standard. A legacy integration may only support an older protocol, or a vendor may not offer customer-managed keys. Record each gap as an exception with the system, the risk, any compensating control, the approver, and an end date. Review open exceptions on a schedule. An approved, time-boxed exception is evidence of control. An undocumented gap is a finding.
12. Plan key destruction and recovery
Keys must be recoverable for as long as the data they protect needs to be readable, including backups. Document how keys are backed up or protected against accidental deletion, and how key deletion is approved. Connect this to disaster recovery evidence so a restore test confirms you can decrypt what you restore, and to data retention when deleting a key is part of how data is disposed.
Type 1 vs Type 2 Considerations
For a Type 1 report, auditors look at whether encryption and key management controls are suitably designed and in place at a point in time. A current data store inventory, the encryption standard, configuration exports, key policies, the certificate inventory, and open exceptions usually support that.
For a Type 2 report, auditors test operation across the period. Expect requests such as:
- Evidence that encryption at rest stayed enabled for sampled data stores during the period, such as recurring check results or audit log history
- Rotation records or rotation settings with dates that fall inside the period
- Key access reviews performed on the cadence you wrote down
- Change tickets for encryption, key policy, and TLS changes made during the period
- Certificate renewal records and proof that no in-scope certificate lapsed, or a documented response if one did
- Exception approvals and reviews dated within the period
- Proof that new data stores created during the period were encrypted at creation
Point-in-time screenshots support design but rarely prove operation. See SOC 2 Type 1 vs Type 2 and What Is SOC 2 Evidence?.
Evidence Examples by Scenario
| Scenario | Stronger evidence | Weaker evidence |
|---|---|---|
| Auditor samples a production database | Inventory entry, encryption config export, key policy, rotation record | Console screenshot with no key details |
| New storage bucket created mid-period | Config rule result showing encryption on creation, linked change ticket | Bucket discovered during fieldwork with default settings |
| Key rotation | Automatic rotation setting and last rotation date, or dated manual rotation ticket | Policy says annual, no record exists |
| Certificate near expiry | Expiry alert, renewal record, updated inventory | Outage ticket after expiry |
| Legacy partner needs an older protocol | Approved exception with compensating control and end date | Older protocol enabled for all clients with no record |
| Secret found in a repository | Scanner alert, revocation and replacement ticket, root cause note | Secret deleted from the latest commit only |
Common Mistakes
- Encrypting primary databases but missing backups, snapshots, exports, or analytics copies
- Broad administrator roles that can use or delete any key, with no review
- A written rotation interval that nobody follows or records
- Private keys or API secrets stored in code, tickets, or chat
- No certificate inventory, so renewals depend on memory
- Older TLS versions left enabled on one forgotten endpoint
- A standard that promises more than the environment delivers
- Encryption and key policy changes made outside change management
- Known gaps with no documented exception, owner, or end date
These patterns create findings and real exposure. When you find one, record it and track the fix through Exception Management and Audit Findings Remediation. Settings that drift from the standard without anyone deciding they should are a form of control drift.
Operating Model: Make Encryption Evidence Routine
- Name owners. Assign a control owner for the encryption standard, key management, and certificates, plus a system owner for each in-scope data store.
- Encrypt by default at creation. Use infrastructure templates or configuration rules that encrypt new data stores automatically and flag those that are not.
- Run recurring checks. Scheduled configuration checks and external TLS scans build results across the period, which are stronger than any one-time export.
- Review key access on a schedule. Add key policies and key administrator roles to your recurring access review.
- Watch the keys. Alert on key disablement, scheduled deletion, key policy changes, and removal of encryption from storage.
- Dry-run sampling before fieldwork. Pick three data stores and two endpoints at random, pull the inventory entry, configuration history, key policy, rotation record, and certificate status, then fix gaps and record late items honestly.
Linking Encryption and Key Management to Neighboring Controls
- Data classification and confidentiality. Classification decides which data needs which protection, and confidentiality is the objective encryption serves.
- Access control. Key access is logical access. Review it alongside other privileged roles and apply least privilege.
- Change management. Encryption, key, and TLS changes should leave records through Change Management Evidence for SOC 2.
- Logging and monitoring. Alerts on key and encryption changes are covered in Logging and Monitoring Evidence for SOC 2.
- Disaster recovery. Restores only work if keys survive. See Disaster Recovery Evidence for SOC 2.
- Vendor management. Vendors that store your data carry their own encryption controls. Review them through vendor management.
How AuditFlo.co Helps
AuditFlo.co helps teams retain continuous evidence collection and audit-period history for operational artifacts when those records are stored or linked through connected systems and workflows your team already uses, such as GitHub and Jira.
For encryption and key management, that can mean dated history for change tickets that touch encryption or key settings, rotation and certificate renewal tasks, access review records, and exception approvals, so you can show the work across the period without rebuilding the story from chat. Your cloud provider, key management service, secrets manager, and certificate tooling remain the systems of record for keys and configuration. AuditFlo.co is not a key management service or encryption tool, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Final Thoughts
Encryption and key management evidence is the proof behind your data protection claims: an inventory of in-scope data stores and endpoints, a written standard, configuration that matches it, controlled key access, recorded rotation, tracked certificates, and honest exceptions. SOC 2 does not dictate algorithms, key services, or rotation intervals, so write the standard you actually operate, follow it, and keep history that survives Type 2 sampling. Encryption that nobody can prove is still encryption, but it is not evidence.
If you are building the broader readiness path, start with What Is Encryption?, What Is Data Classification?, Logging and Monitoring Evidence for SOC 2, SOC 2 Trust Services Criteria Explained, and how to prepare for a SOC 2 audit.
FAQ
Does SOC 2 require encryption?
SOC 2 does not contain a single rule that says "encrypt everything." The Trust Services Criteria include points of focus about using encryption to protect data at rest when appropriate based on risk, protecting data in transit, and protecting encryption keys. In practice, most auditors and customers expect encryption for sensitive data at rest and in transit, and your own policy usually commits to it.
Does SOC 2 require AES-256 or a specific TLS version?
No. SOC 2 does not name algorithms or protocol versions. AES-256 and TLS 1.2 or higher are common practice, and NIST guidance helps you choose. Whatever you write in your standard is what auditors test.
Are cloud provider default encryption settings enough?
Default encryption at rest can satisfy your standard if your standard allows provider-managed keys. You still need to show which data stores are in scope, that encryption is on for each, and that settings stayed in place during the period. If your standard requires customer-managed keys for certain data, defaults alone will not meet it.
How often should we rotate encryption keys for SOC 2?
SOC 2 does not set an interval. Many teams choose annual automatic rotation for customer-managed keys, and NIST SP 800-57 discusses cryptoperiods to guide the choice. Pick an interval, write it down, and keep settings or records that prove it happened.
What evidence proves encryption in transit?
Common evidence includes load balancer and gateway TLS policy exports, database connection settings that require TLS, HTTP to HTTPS redirect configuration, and scheduled external TLS scan results showing approved protocol versions.
What if a system cannot meet our encryption standard?
Document it as an exception. Record the system, the reason, the risk, any compensating control, the approver, and an end date or review date.
Does AuditFlo.co manage our encryption keys?
No. AuditFlo.co helps organize dated evidence such as tickets, reviews, and workflow history from systems you already use. Your cloud provider, key management service, and secrets manager remain the systems of record for keys, and AuditFlo.co does not replace your auditor.