Key Business Drivers for Encryption Adoption

Published: December 2019. Updated: August 2026. Reviewed by Encryption Consulting’s Encryption Advisory team.

The desire to keep information private is not new. Julius Caesar’s substitution cipher protected military orders two thousand years ago for the same reason a modern healthcare provider encrypts patient records today: whoever intercepts the data should not be able to read it. What has changed is not the goal but the pressure behind it. A modern enterprise rarely adopts encryption because a security team recommended it in isolation. It adopts encryption because a regulator, an insurer, an acquirer, or a board asked for proof that it already has.

What Is Driving Encryption Adoption Now?

Six forces are pushing encryption from a technical best practice to a board reviewed requirement: regulatory compliance costs, data breach cost reduction, customer trust, cyber insurance underwriting, mergers and acquisitions (M&A) due diligence, and cloud migration. Each one now expects documented proof, not just a policy statement, that sensitive data is encrypted at rest, in transit, and increasingly in use.

What Are the Main Business Drivers for Encryption Adoption?

1. Regulatory compliance costs. The General Data Protection Regulation (GDPR), in force across the European Union since May 2018, requires encryption of personal data as an explicit technical safeguard. In the US, the California Consumer Privacy Act (CCPA), later expanded by the California Privacy Rights Act (CPRA) and enforced by the California Privacy Protection Agency (CPPA), sets a similar bar at the state level. The Payment Card Industry Data Security Standard (PCI DSS), now at version 4.0.1, requires cardholder data to be rendered unreadable at rest (Requirement 3) and protected with strong cryptography in transit (Requirement 4), with the newest 4.0.1 requirements enforced since March 31, 2025. Two EU frameworks go further and name the control directly: the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), applicable to EU financial entities since January 2025, has a dedicated technical standard, Article 6 of Commission Delegated Regulation (EU) 2024/1774, titled “Encryption and cryptographic controls,” and the NIS2 Directive (Directive (EU) 2022/2555) lists “policies and procedures regarding the use of cryptography and, where appropriate, encryption” as a required risk management measure under Article 21. The cost driver is straightforward: the cost of building and evidencing these controls is consistently lower than the cost of a regulatory fine plus remediation after the fact.
2. Data breach cost reduction. IBM’s 2025 Cost of a Data Breach Report puts the global average cost of a breach at $4.44 million, the first year over year decline in five years, while the US average climbed to a record $10.22 million. The same report found organizations took an average of 241 days to identify and contain a breach. Encryption does not prevent every breach, but it limits what an attacker can do with the data taken, and many US state breach notification laws include a safe harbor that exempts properly encrypted data from public disclosure requirements, which reduces both direct cost and reputational fallout.
3. Customer trust. Buyers, especially in business to business software, health care, and financial services, now ask about data protection posture before signing a contract, not after an incident. Visible encryption commitments, TLS everywhere, encrypted backups, and independent attestations such as ISO/IEC 27001 or SOC 2, have become a standard part of the vendor security questionnaire, and their absence is itself a red flag to a prospective customer’s procurement or security team.
4. Cyber insurance underwriting. Carriers have moved encryption from an assumed control to a checklist item. Industry reporting on 2026 underwriting practices lists disk encryption for laptops and portable devices as a baseline expected control, and some carriers now request a written encryption compliance report as part of the evidence package for a new policy or a renewal. Organizations that cannot produce that evidence quickly risk higher premiums, added exclusions, or a delayed renewal.
5. M&A due diligence. Acquirers now run a dedicated cybersecurity due diligence workstream before closing, and that workstream increasingly asks for a cryptographic inventory rather than a policy document: what is actually encrypted, who holds the keys, and how quickly the environment could respond to a key compromise or an algorithm deprecation. A gap discovered during diligence becomes a purchase price or indemnification conversation; a gap discovered and fixed before diligence does not.
6. Cloud migration. As workloads move to AWS, Azure, and Google Cloud, data no longer sits inside a single physical perimeter, and each hyperscaler’s native key management service has different defaults, different FIPS validation levels, and different bring your own key (BYOK) support. Migrating without an encryption and key custody plan in place produces duplicate key material and audit blind spots; migrating with one in place turns cloud migration into an opportunity to centralize key ownership rather than fragment it further.

How Does Each Business Driver Map to a Technical Encryption Approach?

Each business driver above calls for a specific combination of encryption layer, at rest, in transit, or in use, and key custody model, rather than one generic “turn on encryption” project. The table below maps each driver to the technical response it typically requires and the Encryption Consulting service built to address it.

Business Driver	Typical Technical Response	EC Service That Addresses It
Regulatory compliance (GDPR, CCPA/CPRA, PCI DSS 4.0.1, DORA, NIS2)	Encryption at rest and in transit mapped to one shared control set, with a documented key management policy per regulation’s evidence requirements	Compliance Advisory
Data breach cost reduction	Field or database level encryption plus tokenization so exfiltrated data stays unusable, positioning the organization for encrypted data breach notification safe harbors	Encryption Advisory
Customer trust	Visible encryption commitments (TLS everywhere, encrypted backups) backed by independent attestations such as ISO/IEC 27001 or SOC 2	Encryption Advisory
Cyber insurance underwriting	Documented disk, at rest, and in transit encryption plus an auditable encryption compliance report for new policies and renewals	Compliance Advisory
M&A due diligence	A cryptographic inventory showing what is encrypted, who holds the keys, and how agile the environment is to an algorithm or key change	Cryptographic Inventory
Cloud migration	Envelope encryption with hardware security module (HSM) backed root keys and a bring your own key or hold your own key custody model across providers	HSM as a Service, PKI as a Service

Why Is Unencrypted Data a Growing Liability?

Unencrypted data is a growing liability because the attack surface protecting it keeps expanding faster than most security teams’ visibility into it, and the consequences of exposure now compound rather than end with the initial theft. Three trends drive this. First, cloud sprawl and third party data sharing mean sensitive data increasingly sits outside an organization’s own network perimeter, in a partner’s system, a SaaS vendor’s database, or a public cloud storage bucket. Second, modern ransomware groups run a double extortion model: they steal unencrypted data before encrypting an organization’s own systems, then threaten to leak the stolen data even if the ransom is paid, which means encryption at rest is now a defense against a second monetization lever, not just the original one. Third, harvest now, decrypt later risk means data with a long confidentiality window, health records, trade secrets, government data, can be stolen today in encrypted form and stored by an attacker until a cryptographically relevant quantum computer can break the algorithm protecting it, which is why crypto agility toward post quantum cryptography (PQC) algorithms such as ML-KEM (FIPS 203) matters for encryption decisions made today, not just future ones.

The IBM figures above make the exposure window concrete: an average of 241 days to identify and contain a breach means unencrypted data can sit exposed for the better part of a year before an organization even confirms what happened, let alone reports it to a regulator or an insurer.

How Should Enterprises Roll Out Encryption Adoption?

Enterprises roll out encryption adoption most successfully by following a repeatable sequence tied to the specific driver forcing the decision, rather than deploying encryption tool by tool as each new requirement surfaces. The process below is the sequence Encryption Consulting uses when a client is adopting or expanding encryption for a named business reason.

1. Name the driver and its owner. Identify the specific audit finding, insurer questionnaire, signed letter of intent, or cloud migration deadline forcing the decision, and who in the business owns the outcome.
2. Classify the data in scope. Map the data affected to the specific regulatory clause or contractual requirement it must satisfy, rather than encrypting broadly and sorting out compliance mapping afterward.
3. Choose the encryption layer per workload. Decide at rest, in transit, or in use encryption for each system based on its actual threat model, not a single default applied everywhere.
4. Select algorithms and protocols behind a policy layer. Build crypto agility in from day one so a future post quantum migration is a configuration change to certificate profiles and cipher suites, not a rebuild of every application.
5. Stand up centralized, HSM backed key management first. A strong cipher layered on top of ungoverned keys satisfies no regulator, insurer, or acquirer; key custody has to be decided before the rollout scales.
6. Pilot on the data set the driver actually cares about. Start with the specific cardholder data field, patient record type, or business unit the regulator, insurer, or acquirer is asking about, not the easiest system to encrypt first.
7. Roll out in phases and track results against the original justification. Measure premium change, audit findings closed, or breach cost avoided, not just percentage of systems encrypted.
8. Report back to the sponsor in their language. Translate the rollout into terms the board, insurer, or auditor uses, evidence, risk reduction, cost avoided, rather than cipher names and key lengths.

What Are the Performance and Interoperability Trade-offs When Adopting Encryption Broadly?

Broad encryption adoption introduces real but manageable trade-offs in performance and interoperability, and most of them show up only once encryption moves from a single system to the whole business. On performance, hardware accelerated symmetric ciphers (AES-NI on modern CPUs, or HSM offload) keep bulk data encryption overhead low, while asymmetric operations are better reserved for key exchange and signing than for bulk payloads; a naive full database re-encryption job, or an application that decrypts constantly to support search, is where the overhead becomes noticeable rather than encryption itself. On interoperability, adopting encryption across a multi-cloud or hybrid environment means reconciling key formats and protocols, an on-premises hardware security module speaking PKCS#11, a cloud provider’s native key management service (KMS) speaking its own API, without a common interchange standard such as the Key Management Interoperability Protocol (KMIP), duplicate key material and audit blind spots follow quickly. Every driver above ultimately runs into these same two trade-offs, so it is worth planning for them once at the architecture level rather than once per project. For the deeper technical breakdown of these trade-offs, see our guide to common encryption challenges enterprises face.

Why Does Key Management Determine Whether Encryption Adoption Succeeds?

Key management determines whether encryption adoption succeeds because the keys, not the algorithm, are the actual point of failure and the actual point of proof for every driver above. A Key Management System (KMS) is the software or service layer that governs how keys are generated, rotated, and retired; a Hardware Security Module (HSM) is the tamper resistant hardware, on premises or delivered as a managed service, where the most sensitive key material is generated and stored so it is never exposed in plaintext, typically validated to FIPS 140-3, the current federal standard for cryptographic modules. Three key custody decisions repeat across every driver in this article: whether to use a cloud provider’s native KMS, a bring your own key (BYOK) model where the organization supplies the key but the provider can still access it, or a hold your own key (HYOK) model where the key never leaves organization controlled hardware; how root and intermediate keys are protected with access separation from the administrators who manage the systems those keys encrypt; and how key rotation and a formal key ceremony process are documented so an auditor, insurer, or acquirer can verify the process rather than take it on faith. A managed HSM-as-a-Service model gives an organization FIPS 140-3 validated key protection and the ceremony and maintenance discipline that regulators and insurers are increasingly asking to see, without building that specialized capability in house from scratch.

What Do Real Deployment Examples Look Like?

The scenarios below are representative of how the drivers above typically converge in a single encryption program, not case studies of a named client.

• Compliance and insurance converging: A financial services firm facing a PCI DSS 4.0.1 assessment and a cyber insurance renewal in the same quarter encrypts cardholder data at rest, tokenizes card numbers at the application layer, and produces one encryption compliance report that satisfies both the Qualified Security Assessor (QSA) and the insurer’s underwriting questionnaire, instead of building two separate evidence packages.
• Cloud migration with HIPAA in scope: A health care provider migrating patient records to a multi cloud environment adopts envelope encryption with HSM backed root keys under a hold your own key model, so protected health information stays encrypted at rest and in transit regardless of which cloud provider’s native KMS handles the data key day to day.
• M&A readiness: A mid market software company preparing for acquisition runs a cryptographic inventory ahead of due diligence, discovers an unencrypted legacy reporting database, and remediates it before the buyer’s technical diligence team finds it, turning a potential price adjustment into a closed finding.
• Crypto agility for NIS2 and the coming PQC transition: A manufacturer with EU operations subject to NIS2 builds a centralized key management architecture with a crypto agility policy layer, so its TLS certificate infrastructure can move to post quantum algorithms as NIST and CA/Browser Forum guidance firms up, without renegotiating every application’s cipher configuration one at a time.

Limitations

• Encryption limits what a breach can expose; it does not stop unauthorized access by someone who already holds a valid key or account, which is why access separation and key governance matter as much as algorithm choice.
• Regulatory citations here (GDPR, CCPA/CPRA, PCI DSS 4.0.1, DORA, NIS2) reflect each framework’s requirements as of this update; confirm current text and enforcement dates with legal or compliance counsel before finalizing a control mapping.
• Breach cost figures from the IBM report are global and US averages; an individual organization’s actual cost depends heavily on sector, data volume, and detection speed.
• Cyber insurance encryption expectations vary by carrier and policy; treat the underwriting example in this article as directional, not a guarantee of coverage or pricing.
• This article addresses business drivers and adoption strategy at a program level and does not replace a workload specific technical risk assessment.

What Would Encryption Consulting Recommend?

Start with the driver, not the tool. Too many encryption programs pick a product before naming which regulation, insurer, or acquirer actually needs the evidence, then retrofit reporting around whatever was purchased. Run a cryptographic inventory first so you know what is and is not encrypted today, decide key ownership and custody model second, and treat algorithm and protocol selection as a policy decision that will be revisited again given the post quantum transition ahead, not a one time setting. If your team is being asked to prove encryption maturity for a compliance audit, an insurance renewal, or a deal, our Compliance Advisory team can map your controls to the specific regulation in question, and our Encryption Advisory team can design the underlying architecture. Where the driver comes down to key custody at scale across cloud and on premises environments, HSM-as-a-Service gets you FIPS 140-3 validated key protection without building the ceremony and maintenance capability in house.

Frequently Asked Questions

What is the single biggest business driver behind encryption adoption today? Regulatory compliance remains the most consistent driver because GDPR, PCI DSS 4.0.1, DORA, and NIS2 now name encryption or cryptography directly in their required controls, but breach cost reduction is closing the gap since the 2025 IBM Cost of a Data Breach Report put the US average breach cost at a record $10.22 million.

Does encryption actually reduce the cost of a data breach? Encryption reduces exposure by making exfiltrated data unusable without the key, and many US state breach notification laws exempt properly encrypted data from public disclosure requirements, which limits both direct cost and reputational damage even when a breach occurs.

Do cyber insurers require encryption? Most carriers now list disk, at rest, and in transit encryption as baseline controls on underwriting and renewal questionnaires, and some ask for a written encryption compliance report as evidence, though exact requirements vary by carrier and policy.

Does encryption alone satisfy GDPR, PCI DSS, DORA, and NIS2? No single control satisfies any of these frameworks alone; encryption is one required control among several, including access control, monitoring, incident response, and key management documentation, and each regulation expects it implemented and evidenced as part of a broader program.

How does encryption factor into M&A due diligence? Acquirers increasingly expect a documented cryptographic inventory, proof of what is encrypted, who holds the keys, and how quickly the environment can respond to an algorithm or key compromise, as part of technical due diligence, not just a written security policy.

Conclusion

Encryption’s core purpose, keeping data private from whoever intercepts it, has not changed since Caesar’s cipher. What has changed is that the demand to prove it, and prove it well, now comes from six directions at once: regulators, breach economics, customers, insurers, acquirers, and the cloud providers hosting the data itself. Enterprises that treat each of these drivers as a separate project end up running six overlapping encryption efforts with six different owners. The ones that build a shared cryptographic inventory and a centralized, HSM backed key management foundation first find they can answer a regulator, an insurer, and an acquirer with the same evidence, rather than starting over for each one.

References

• IBM, Cost of a Data Breach Report 2025, Navigating the AI Rush Without Sidelining Security: https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai
• Regulation (EU) 2016/679 (General Data Protection Regulation): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679
• State of California Department of Justice, California Consumer Privacy Act (CCPA): https://oag.ca.gov/privacy/ccpa
• PCI Security Standards Council, PCI DSS v4.0.1 Resource Hub: https://blog.pcisecuritystandards.org/pci-dss-v4-0-resource-hub
• Regulation (EU) 2022/2554 (Digital Operational Resilience Act, DORA): https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554
• Commission Delegated Regulation (EU) 2024/1774, Article 6, Encryption and Cryptographic Controls: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1774
• Directive (EU) 2022/2555 (NIS2), Article 21: https://eur-lex.europa.eu/eli/dir/2022/2555/2022-12-27/eng
• Cyber Advisors, Cyber Insurance in 2026, The Controls Underwriters Expect and How to Prove Them: https://blog.cyberadvisors.com/cyber-insurance-in-2026-the-controls-underwriters-expect-and-how-to-prove-them