POLICY TEMPLATE

Encryption Policy

Create a customized encryption policy document showing data protection across all states, aligned with Travelers, Hartford, Coalition, and Beazley requirements.

📋 What this cyber insurance requirement is

An encryption policy for cyber insurance should define data-state matrix showing how you encrypt data at rest, in transit, on mobile devices, and for third-party transfers. It should specify encryption standards (TLS version, AES algorithm, key management procedures), document HTTPS enforcement for web endpoints, outline email encryption requirements, and detail key management practices including creation, storage, rotation, and retirement. Encryption is foundational to most cyber policies and carriers expect a comprehensive policy at renewal to verify your organization protects sensitive information across all data states.

Create your encryption policy below

What you'll get

✓A customized encryption policy document (3-5 pages)
✓Data-state matrix: encryption at rest, in transit, on mobile, and for third-party transfer
✓Encryption standards (TLS version, AES algorithm, key management)
✓HTTPS enforcement & web endpoint protection details
✓Mobile device & email encryption procedures
✓Key management (creation, storage, rotation, retirement)

1. Encryption Methods

2. Preview & Download

Company Name*

The company name as it appears on your policies and official documents.

Encryption at Rest*

Multi-select: which encryption methods are deployed for data at rest?

Encryption in Transit*

TLS 1.2TLS 1.3IPSec VPN

Which protocols protect data in transit between endpoints, servers, and cloud services?

Mobile Device Encryption*

How are mobile devices (phones, tablets) encrypted if used for company data?

Key Management*

How are encryption keys created, stored, and rotated?

HTTPS for Web Endpoints*

What percentage of your web applications are enforced with HTTPS/TLS?

Email Encryption*

What encryption is applied to email communications?

What carriers are looking for

Each carrier asks slightly different questions. Here are some named artifacts by carrier.

Travelers

Encryption methods matrix for data at rest and in transit
Hard drive encryption standards
Database encryption documentation
TLS configuration details

Hartford

TLS 1.2+ enforcement across all systems
Database encryption procedures
HTTPS requirement and enforcement
Key management procedures

Coalition

Sensitive data encryption standards
Key management procedures
Mobile device encryption
Data-state encryption matrix

Beazley

Encryption standards across data states
Encryption in transit (TLS versions)
Encryption at rest (AES standards)
Key management details and procedures

What to collect

Evidence artifacts your broker will need during the renewal process.

💾

Disk Encryption Report

Compliance report showing BitLocker, FileVault, or LUKS encryption status across all endpoints and servers

🔍

TLS Configuration Scan

SSL Labs or similar scan results showing TLS 1.2+ enforcement and no deprecated protocols (SSL 3.0, TLS 1.0/1.1)

📜

Certificate Inventory

List of all SSL/TLS certificates with expiration dates, key sizes, and renewal procedures

🔐

Key Management Documentation

Key storage location (KMS, HSM, or vault), rotation schedule, and access controls

✅

HTTPS Enforcement Audit

Screenshots showing automatic HTTPS redirects on all sensitive data endpoints and web applications

📧

Email Encryption Config

Documentation of TLS-enforced email transmission, S/MIME, PGP setup, or gateway encryption settings

Important: What this doesn't prove

Be upfront about these gaps. Carriers appreciate honesty over overstatement.

Actual Deployment: A policy is a statement of intent, not evidence that encryption is actually deployed everywhere

Consistent Enforcement: Policy doesn't verify that encryption is enforced consistently across all systems and updates

Third-Party Compliance: Your encryption policy doesn't verify that third-party vendors actually follow encryption standards

Cipher Disabling: Documentation doesn't prove that weak ciphers have been disabled or that key sizes are adequate

Key Rotation: Policy on key rotation doesn't prove that keys are actually rotated on schedule

Encryption Coverage: Policy may not cover all data states (backup encryption, archive encryption, decommissioned media)

Who owns what

🏢Insured

Owns the encryption policy (governance, approval, and oversight). Responsible for defining encryption standards across the organization, approving key management approach, and ensuring compliance across all data states. Coordinates with IT and security teams to validate encryption coverage.

🔧MSP/IT Team

Deploys encryption on all systems and databases. Manages certificates, TLS configuration, and key management infrastructure. Conducts encryption audits, maintains HTTPS enforcement, and executes key rotation procedures. Provides compliance reports and disk encryption status across endpoints.

🤝Broker

Coordinates encryption policy creation and review with insured. Collects encryption evidence and compliance reports from IT. Maps encryption standards to carrier questions. Flags gaps (e.g., missing encryption coverage, weak cipher algorithms) for remediation before renewal.

Frequently Asked Questions

What's the difference between encryption at rest and in transit?

At rest: Data stored on disk, database, or storage media (BitLocker, FileVault, AES-256). In transit: Data moving across networks (TLS/SSL, IPSec, VPN). Both are required. Data is vulnerable during both states.

What TLS version should we enforce?

Minimum: TLS 1.2. Preferred: TLS 1.3. Disable SSL 3.0, TLS 1.0, and TLS 1.1 completely. Carriers expect TLS 1.2+ across all production systems. TLS 1.3 adoption is increasing.

How should we handle mobile device encryption?

Device encryption: Native OS encryption (iOS, Android) or MDM-enforced. Backup encryption: Cloud storage must also be encrypted. Email: Mobile email apps should enforce encryption in transit. Carriers expect full-device encryption as baseline.

What's the best approach to key management?

Cloud KMS: AWS KMS, Azure Key Vault, Google Cloud KMS. HSM: On-premises Hardware Security Module. PKI: Certificate Authority for infrastructure. Never store keys in code or config files. Rotate keys annually or per policy.

Do we need HTTPS on all web endpoints?

Yes. All endpoints handling sensitive data require HTTPS with automatic HTTP-to-HTTPS redirects. Carriers increasingly expect this across all applications, not just login pages. Exceptions for static content must be documented.

How should we handle email encryption?

Minimum: TLS enforcement for email transport (prevents unencrypted SMTP). Recommended: S/MIME or PGP for end-to-end encryption of sensitive messages. Gateway: Email gateway encryption for outbound messages. Most carriers accept transport-level TLS as baseline.

Sources (March 2026)

Travelers Cyber Risk Assessment — Encryption methods for data states and locations
Hartford Cyber Security Questionnaire — TLS 1.2+ enforcement and database encryption requirements
Coalition Underwriting Standards — Encryption standards, key management, and mobile device encryption
Beazley Security Assessment — Encryption procedures across data states and key management documentation
NIST Cybersecurity Framework (SC-28) — Protection of information at rest and in transit
PCI DSS v3.2.1 — Encryption requirements for payment card data and sensitive information
OWASP Top 10 — Encryption best practices for web application security

Get your policies in order

← Browse all templates Start a renewal readiness check →Decode a carrier form