CalcEngine All Calculators

Encryption Coverage Calculator

General

Enter your total assets and how many are encrypted at rest and in transit to get an instant coverage score. Ideal for security audits, compliance reviews, and gap analysis.

Last updated: April 2026

This calculator is designed for real-world usage based on typical engineering scenarios and publicly available documentation.

An encryption coverage calculator gives security teams a fast, quantified view of how much of their data estate is protected. Without a coverage number, "most of our data is encrypted" is just a guess — regulators, auditors, and incident responders need a percentage. This tool covers both dimensions that matter: encryption at rest (data stored on disk, in databases, in object storage) and encryption in transit (data moving over networks, APIs, and service meshes). Multiply across your total asset count and you get separate scores for each dimension plus a combined overall coverage metric. Use this calculator when preparing for a SOC 2, ISO 27001, or CRA audit, during a security posture review, or after a new system is added to your inventory. It also helps prioritise remediation: if at-rest coverage is 95% but in-transit is 60%, you know exactly where to focus next. The formula works for any unit — databases, microservices, S3 buckets, IoT endpoints, or on-prem servers. Define "asset" consistently across your inventory and the resulting percentage is comparable over time.

How to Calculate Encryption Coverage

Encryption Coverage — how it works diagram

1. Count your total data assets — databases, services, storage buckets, or endpoints. 2. Count how many assets have encryption at rest enabled (AES-256, LUKS, cloud-managed KMS, etc.). 3. Count how many assets encrypt data in transit (TLS 1.2+, mTLS, HTTPS). 4. Divide each encrypted count by the total to get at-rest and in-transit coverage percentages. 5. Average the two percentages to get your overall encryption coverage score.

Formula

At-Rest Coverage (%)    = (Encrypted at Rest   ÷ Total Assets) × 100
In-Transit Coverage (%) = (Encrypted in Transit ÷ Total Assets) × 100
Overall Coverage (%)    = (At-Rest Coverage + In-Transit Coverage) ÷ 2

Total Assets        — number of systems, services, or data stores in scope
Encrypted at Rest   — assets with storage-layer encryption enabled
Encrypted in Transit — assets communicating over encrypted channels (TLS/mTLS)

Example Encryption Coverage Calculations

Example 1 — Mid-size SaaS (50 assets)

Total assets: 50
Encrypted at rest: 40   →  40 ÷ 50 × 100  =  80.0%
Encrypted in transit: 45 → 45 ÷ 50 × 100  =  90.0%
                                              ─────────────
Overall coverage: (80.0 + 90.0) ÷ 2  =  85.0%
Gap: 10 assets not encrypted at rest → prioritise storage remediation.

Example 2 — IoT fleet (200 devices)

Total devices: 200
Encrypted at rest (secure element): 120  →  60.0%
Encrypted in transit (TLS):         160  →  80.0%
                                          ─────────────
Overall coverage: (60.0 + 80.0) ÷ 2  =  70.0%
80 devices lack at-rest encryption — flag for firmware update before CRA audit.

Example 3 — Enterprise microservices (120 services)

Total services: 120
Encrypted at rest (KMS-managed): 114  →  95.0%
Encrypted in transit (mTLS mesh):  108  →  90.0%
                                          ─────────────
Overall coverage: (95.0 + 90.0) ÷ 2  =  92.5%
Remaining 6 at-rest gaps are legacy batch jobs — schedule migration to meet 100% target.

Tips to Improve Encryption Coverage

Notes

Frequently Asked Questions

What counts as "encryption at rest"? +
Any storage-layer encryption that protects data when it is not being processed counts: AES-256 disk encryption (LUKS, BitLocker), database transparent data encryption (TDE), object-storage server-side encryption (SSE-S3, SSE-KMS), and hardware secure elements. Application-level encryption (encrypting before writing) also qualifies. The key test: if the physical media is stolen, is the data unreadable without the key?
What counts as "encryption in transit"? +
Any channel-level encryption that protects data while it moves between systems: TLS 1.2 or 1.3 for HTTP/gRPC/database connections, mTLS for service-to-service communication, IPsec or WireGuard for network tunnels, and SSH for remote access. Unencrypted HTTP, plain-text database connections, or legacy protocols like FTP are gaps. For IoT, DTLS over UDP or MQTT with TLS counts.
What encryption coverage percentage do compliance frameworks require? +
Most frameworks — SOC 2 Type II, ISO 27001, PCI DSS, and the EU Cyber Resilience Act — require 100% encryption of data classified as sensitive or confidential. In practice, auditors accept documented exceptions with compensating controls. Aim for 100% on your sensitive-data assets first, then extend to all assets. A coverage below 80% will typically generate audit findings.
How is overall coverage calculated from at-rest and in-transit scores? +
Overall coverage is the simple average of at-rest and in-transit percentages: (at-rest % + in-transit %) ÷ 2. This gives equal weight to both dimensions. If your threat model treats one as higher risk — for example, in-transit is more exposed in a public-cloud environment — you can weight the average accordingly. Most compliance frameworks evaluate each dimension separately rather than using a combined score.
How often should I recalculate encryption coverage? +
Recalculate after any infrastructure change that adds, removes, or modifies assets: new service deployments, cloud account changes, IoT firmware updates, and database migrations. At minimum, run a full audit quarterly and before each compliance review. Automating the scan with IaC linters or CSPM tools (AWS Security Hub, Wiz, Orca) lets you track coverage continuously rather than as a point-in-time snapshot.