SOC 2 Type 1 encryption and key management checklist

For SOC 2 Type 1, show that data is encrypted in transit and at rest where your risk assessment says it should be, and that keys are protected through generation, storage, use and destruction. The relevant criteria are CC6.1 and CC6.7, plus C1.1 if confidentiality is in scope. Type 1 judges design at a point in time.

What do the criteria say about encryption?

The 2017 Trust Services Criteria with 2022 points of focus do not mandate a specific algorithm. CC6.1 covers logical access protections over information assets, and its points of focus include using encryption to protect data and protecting cryptographic keys during generation, storage, use and destruction. CC6.7 covers restricting transmission, movement and removal of information, with a point of focus about using encryption technologies or secure channels to protect data in transit, and protecting removable media. C1.1 covers identifying and maintaining confidential information, which tells you which data deserves the strongest protection. I paraphrase here and do not quote the criteria.

A Type 1 report covers the design of controls at a point in time, with no opinion on how they operated over a period. So the auditor wants to see that the control exists and is configured properly on the audit date.

What belongs in the checklist?

Data inventory. Which data is confidential or restricted and where it lives. Encryption decisions follow this list.

In transit.

1. Transport encryption on every public endpoint, with old protocol versions disabled.
2. Encryption on internal service links that cross network boundaries.
3. Encrypted channels for administrative access, with no plain text remote login.
4. Encryption for email or file transfers that carry confidential data to customers.

At rest.

1. Storage volumes, databases and object stores encrypted.
2. Backups and snapshots encrypted, including copies in another location.
3. Laptops and phones with disk encryption enforced by device management.
4. Log stores that may hold personal data covered.

Key management.

1. Keys held in a managed key service or vault, not in code or chat.
2. Separate keys by environment, and by tenant where the design calls for it.
3. A rotation schedule and a documented process for emergency rotation.
4. Access to keys limited to named roles, logged and reviewed.
5. A destruction step when data or systems are retired.
6. Secrets management for application credentials, with scanning to catch committed secrets.

Policy. A short cryptography policy that states what must be encrypted, minimum standards and key roles. It must match what is configured.

What evidence will the auditor request?

Configuration exports or console views showing encryption enabled on a sample of databases and buckets, the TLS settings of your public endpoints, the device management report on disk encryption, the key service policy and access list, the rotation schedule, and the cryptography policy with approval. Dated exports are better than cropped screenshots.

How do you order the work?

Start with the data inventory so you know what matters. Fix public endpoints next because they are visible. Then enable storage and backup encryption, then keys and access. Write the policy last, so it describes the real design.

What mistakes are common?

• Encryption on the primary database but not on backups or analytics copies.
• Keys readable by every engineer.
• Secrets committed to repositories.
• A policy that says annual rotation when nothing rotates.
• Treating a vendor's encryption as covering your own configuration.

What to do

1. Classify data and list where it is stored and transmitted.
2. Fix any unencrypted store or old protocol on that list.
3. Move keys into a managed service with role based access.
4. Enable secret scanning in repositories and pipelines.
5. Write the cryptography policy and get it approved.
6. Export dated evidence for each item on the checklist.

Quick check

How Safeguard helps automate this

Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence for these controls is collected from connected systems and code instead of by screenshot, and monitoring continues between audits. Technical evidence, including secrets scanning results, comes from your real code and dependencies. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. The report comes from an independent auditor. Safeguard helps you prepare and keep evidence ready.

Open the framework mapping demo

Sources

• AICPA 2017 Trust Services Criteria with 2022 points of focus, criteria CC6.1, CC6.7 and C1.1, read from the AICPA publication

Last reviewed: 18 October 2026.