The encryption policy template, at rest and in transit
What gets encrypted, with what, where the keys live and when they rotate.
An encryption policy template says what data is encrypted, with which standard, where the keys are held and how often they rotate. A SOC 2 auditor tests it against CC6.1, logical access protection over information assets, and CC6.7, protecting data while it moves.1
It is the shortest policy in the set. The evidence behind it comes almost entirely from console settings.
What an auditor checks
- Encryption at rest is on. The setting on each production database, storage bucket and backup, and on company laptops.
- Transport Layer Security (TLS) is enforced. The load balancer or service configuration, and a scan showing old protocols refused.
- Keys are managed. The key service settings: who can administer keys, rotation, and logging of key use.
- Certificates are current. The certificate list with expiry dates.
The full policy text
TLS 1.2 is the floor, matching National Institute of Standards and Technology (NIST) Special Publication 800-52 Rev. 2, which also expects TLS 1.3 to be supported.2 The key rules follow NIST SP 800-57 Part 1, which covers protecting keys through their life, from generation to destruction.3
[Company name]
Encryption Policy
- Owner
- [Security owner role]
- Approved by
- [Policy approver role]
- Effective date
- [Effective date]
- Next review
- [Next review date]
- Version
- [Version]
1. Purpose and scope
This policy supports the SOC 2 common criteria CC6.1 and CC6.7 by defining encryption and key management requirements for data at rest and in transit.
This policy applies to all production systems, backups, and data transmissions that store, process, or transmit company or customer data.
2. Encryption standards
- Data at rest: Databases, object storage, backups and laptops that hold Company or customer data are encrypted with [Encryption standard at rest].
- Data in transit: Data crossing a public network is encrypted with [Encryption standard in transit]. Transport Layer Security (TLS) 1.2 is the minimum, and older protocols are disabled.
- Algorithms: Only current, widely reviewed algorithms from the cloud provider and standard libraries are used. Custom cryptography is not permitted.
3. Key management
- Where keys live: Encryption keys and secrets are held in [Secrets manager] and never in source code, chat or tickets.
- Rotation: Keys are rotated [Key rotation frequency], and at once when compromise is suspected or someone who could read them leaves.
- Access: Only named administrators can manage keys, and every use of a key is logged.
- Retirement: A retired key is disabled before it is deleted, so data it protects can still be read during the change.
4. Certificates
Public certificates come from a trusted certificate authority, renew automatically where the provider supports it, and are tracked with their expiry dates so none lapses unnoticed.
5. Roles and responsibilities
| Role | Held by | Responsibility |
|---|---|---|
| Policy approver | [Policy approver role] | Approves this policy, each new version, and any risk the Company accepts instead of meeting it. |
| Policy owner | [Security owner role] | Maintains this policy, makes sure the controls in it operate, keeps the evidence, and reviews it at least once a year. |
| Key administrators | [Engineering owner role] | Configure encryption and key rotation, and approve access to keys. |
| All personnel | Everyone in scope | Follow this policy and report a suspected breach of it to the [Security owner role]. |
6. Evidence and records
The records below show that this policy operates. Each is dated, kept for at least [Evidence retention period], and stored where an auditor can be given it.
| Record | What it shows | Where it is kept |
|---|---|---|
| Approved policy | This document, signed by the approver, with its version history. | [Documentation system] |
| Encryption configuration | Evidence of at-rest and in-transit encryption settings. | [Cloud provider] |
| Key management settings | Key service or secrets manager settings, including rotation. | [Secrets manager] |
| Certificate inventory | Each certificate, where it is used, and when it expires. | [Documentation system] |
7. Exceptions and enforcement
A deviation from this policy needs a written exception approved by the [Security owner role] before it begins. Each exception records the rule not met, the business reason, the compensating control and an expiry date no more than 12 months away. Exceptions are reviewed at each annual review.
A breach of this policy is handled under the Company disciplinary process and may lead to action up to and including termination of employment or contract. A breach that exposes customer data is also handled as a security incident.
8. Review and approval
The [Security owner role] reviews this policy at least once a year and after any significant change to the business, the systems in scope or the risks they face. The [Policy approver role] approves each version. Personnel are told of material changes and acknowledge the current version.
| Version | Date | Summary of change | Approved by |
|---|---|---|---|
| [Version] | [Effective date] | First version. | [Policy approver role] |
Sign-off. Name, signature and date for: Policy approver.
9. Fields to complete
Replace every bracketed field in this document with your own detail, then delete this section.
| Field | What to enter |
|---|---|
| [Company name] | Your legal company name. |
| [Effective date] | The date the approver signs this version. |
| [Version] | Start at 1.0 and increase it each time the document changes. |
| [Security owner role] | The role that runs the security program day to day, for example Chief Technology Officer. |
| [Policy approver role] | The officer who approves policies and accepted risks, for example Chief Executive Officer. |
| [Documentation system] | Where policies and procedures are published, for example the company wiki. |
| [Cloud provider] | Where production runs, for example AWS, Google Cloud or Azure. |
| [Secrets manager] | Where keys and secrets are stored, for example a cloud key management service. |
| [Encryption standard at rest] | For example AES-256, the Advanced Encryption Standard with 256-bit keys, through the cloud provider key service. |
| [Encryption standard in transit] | For example TLS 1.2 or higher. |
| [Key rotation frequency] | How often keys are replaced, for example every 12 months. |
| [Evidence retention period] | How long audit evidence is kept, for example three years. |
| [Engineering owner role] | The role that owns production systems, for example engineering lead. |
| [Next review date] | The date this version must be reviewed by, at most 12 months after the effective date. |
How to adapt it in an afternoon
- Write your actual standards. The provider default for storage, and the TLS policy on your load balancer.
- Turn on automatic key rotation. Then write the period it uses into the policy.
- Find stray secrets. Search the repository and the chat history before you sign a sentence saying there are none.
- List your certificates. Domain, where it is used, who renews it and when it expires.
- Approve it. Then screenshot each setting so the evidence exists on the day the period opens.
What produces a finding
An unencrypted database created after the policy was signed. A key in source code that the policy says cannot be there. A certificate that lapsed during the period. Data handling rules by level live in the data classification and retention policy, and who may administer keys in the access control policy. The evidence checklist lists the screenshots to keep, and the SOC 2 policy list shows the full set.
Polara G.R.C. onboarding is $2,000 one time. It writes the thirteen policies in its pack, which cover encryption, from your intake answers, with your systems, owners and review dates named, for you to review and approve. No template passes an audit on its own, this one included. An independent licensed U.S. CPA firm tests whether the policy operated.
Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.
Questions
Does SOC 2 require encryption?
Which TLS version should the policy require?
How often should encryption keys be rotated?
How often must the encryption policy be reviewed?
Is an encryption policy template enough for SOC 2?
Sources
- TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy
- Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (SP 800-52 Rev. 2)
- Recommendation for Key Management: Part 1, General (SP 800-57 Part 1 Rev. 5)
Get audit-ready without a compliance team.
The readiness assessment is free, with no payment and no card. Onboarding is $2,000 one time, then SOC 2 Type 2 is $600 a month on a 12-month term, and your first SOC 2 Type 2 audit is included in the term. You can be audit-ready starting at about a week.
Take the free assessmentPolara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.