Endpoint Encryption Compliance Requirements Across Common Frameworks

Every major compliance framework agrees on one control, and that control is endpoint encryption. HIPAA, PCI DSS, SOC 2, NIST CSF 2.0, CMMC, and ISO 27001 each demand it, in their own language, with their own penalties attached. For a lean IT team, that convergence creates a strange kind of pressure: the underlying technical work is the same across every framework, but the paperwork, the evidence, and the consequences for getting it wrong are not.

Before a deal closes, a contract can require proof of a security control. A cyber insurance renewal arrives with a questionnaire asking pointed questions about disk encryption and key management. An auditor shows up to check boxes against a framework a client chose, not one the business picked for itself. Government agencies, prime contractors, healthcare systems, and large enterprises now build documented security practices into the terms of doing business, and encryption sits near the top of that list almost every time.

None of this is really a question of whether to encrypt. Every serious framework already answered that question years ago. The actual difficulty is that HIPAA, PCI DSS, CMMC, SOC 2, NIST CSF 2.0, and ISO 27001 each phrase the requirement differently, attach different consequences to failure, and expect different kinds of proof when an auditor comes knocking. A business working under two or three of these frameworks at once can end up doing the same job three separate times, each with its own rules for what counts as done.

How HIPAA treats endpoint encryption

HIPAA's current Security Rule asks for a familiar mix of safeguards: access controls, encryption, audit logging, and documented policies, spread across administrative, physical, and technical categories. In practice, this means any device holding electronic protected health information (ePHI), workstations, laptops, portable drives, backup media, cloud storage, needs encryption applied to it. The rule reaches well past hospitals and clinics, too. It covers business associates, so IT vendors, billing companies, and any service firm handling health data in some form fall under the same obligations as the providers they work for.

The real shift coming is in how the rule treats the word "addressable." Under the current Security Rule, encryption falls into a category called "addressable," which sounds like a requirement but functions more like a suggestion with paperwork attached. An organization could look at its own environment, decide encryption wasn't reasonable to implement, write down why, and put some other measure in its place instead. Many organizations took that escape hatch, especially on workstations and portable devices, because setting up encryption there took extra work.

The proposed 2026 Security Rule update closes that door. It's built to set one minimum bar for cybersecurity controls across the entire healthcare sector, regardless of how small the organization is. A small practice can no longer write a memo that explains why encryption wasn't practical and call itself compliant. Encryption of ePHI, at rest and in transit, becomes a flat requirement tied to NIST standards, which in practice means AES-256 for stored data and TLS 1.2 or higher for data moving across a network. So the old path of documenting an alternative rationale disappears under the proposed rule.

The rule hasn't been finalized. The federal rulemaking body overseeing the update is targeting July 2027 for final action, so nothing here is locked in. But enforcement posture tends to shift ahead of the paperwork catching up, and the timeline for compliance once the rule does take effect is tight: regulated entities get roughly six months after the effective date to come into line, and that effective date itself follows publication by only a short stretch. Mandatory compliance lands well under a year from the day the rule publishes. If you wait for the final text before you start work on encryption, you'll be working against a six-month clock.

What PCI DSS v4.0 requires at endpoint level

PCI DSS v4.0.1 carried a batch of requirements that were optional for a while, future-dated so organizations could prepare before they became binding. That grace period ended on March 31, 2025. One of the requirements that came fully into force that day quietly disqualifies a method of protecting payment card data that a lot of organizations had relied on for years.

Requirement 3.5.1.2 states that disk-level or partition-level encryption no longer counts as an acceptable way to render a cardholder's primary account number (PAN) unreadable, with one exception for removable electronic media. What counts now is encryption applied at the file, column, or field level, on the data itself. An organization running BitLocker or a similar full-disk tool across its workstations, with PAN data stored somewhere on those drives, might have passed an audit under the old rules. Under v4.0's mandatory requirements, that same setup fails.

PCI DSS also carries a standing maintenance obligation, and it's easy to let that slide once you've achieved initial compliance. Organizations must review their full cryptographic inventory, hardware, software, and the specific cipher suites in use, at least once every 12 months. Catching outdated or weakening cryptography before it becomes the thing an attacker exploits matters more than finding out about it during an incident response.

Full-disk encryption protects a laptop if it's lost or stolen, but it does nothing once that laptop is running and an application reads the PAN data off the disk. PCI DSS v4.0 now requires protection that travels with the data itself, not just with the physical device holding it.

How CMMC 2.0 extends NIST 800-171's encryption rules

CMMC 2.0 pushes the encryption conversation a level deeper than most frameworks bother to go. It isn't enough for a defense contractor to encrypt data. The cryptographic module doing the encrypting has to carry FIPS validation, a formal certification that the specific implementation meets federal cryptographic standards. Encryption that works fine and encryption that satisfies CMMC are not automatically the same thing.

This distinction trips up more organizations than almost any other part of the framework. A widely used built-in disk encryption tool ships in a default mode that is not FIPS-compliant. You have to explicitly turn on FIPS mode through Group Policy or a mobile device management platform, then confirm that mode is actually active across every machine, not just configured somewhere in a settings menu. The gap between encryption that's running and encryption that's running in FIPS mode is visible constantly in CMMC assessments, and it's one of the most common reasons contractors fail them.

Encryption doesn't remove a file from CMMC's scope, either. A file containing it remains subject to every applicable CMMC control even after encryption is applied, a point the Department of Defense reinforced again in its FAQ updates through late 2025 and into 2026. If you encrypt a drive, the compliance boundary around what's on it doesn't shrink.

The certification side of CMMC 2.0 is currently paused. That pause doesn't touch the underlying obligation. NIST SP 800-171 compliance remains a binding contractual requirement under DFARS 252.204-7012 for any contractor handling CUI, certification mandate or not. Contractors waiting out the pause before addressing their encryption gaps are waiting out the wrong thing: the contract clause that requires compliance never went anywhere.

How SOC 2 and NIST CSF 2.0 treat encryption

SOC 2 and NIST CSF 2.0 land in a similar place on encryption, and the overlap between them (and with ISO 27001 and HIPAA) rewards building one strong control.

NIST CSF 2.0 addresses endpoint encryption through PR.DS-01, a control built around protecting the confidentiality, integrity, and availability of data at rest. Full-disk encryption on managed devices is one way to satisfy it, and the practical payoff is straightforward: a lost, stolen, or decommissioned machine stops being a liability because whatever's on it stays unreadable without the key. NIST CSF 2.0 was written to apply across organizations of every size and sector, so it now covers small and midsize businesses that weren't really the focus when earlier versions came out.

SOC 2 approaches the same ground through its Confidentiality criteria, which call for strong encryption of data both at rest and in transit. SOC 2 is an attestation clients request before they'll sign a contract, and for technology companies or any business handling client data, a SOC 2 report has become close to a prerequisite for landing enterprise deals.

A single control satisfying SOC 2's CC6.1 logical access requirement will often also satisfy ISO 27001's Annex A.9, NIST CSF 2.0's PR.AA-01, and PCI DSS Requirement 7.1 at the same time. That overlap compounds when a security program treats these controls as one architecture, not six separate checklists stapled together. Building the control once and documenting it well answers most frameworks asking the same underlying question in the same motion.

Where ISO 27001 takes a different path

ISO 27001:2022 breaks from the pattern the other frameworks follow. It requires organizations to protect data on endpoint devices, but it never names a specific encryption standard or algorithm. Instead, it asks organizations to assess their own risk and decide what level of protection fits. That sounds like flexibility, and for an organization only answering to ISO 27001, it is. For an organization also chasing CMMC certification, that same flexibility turns into an extra layer of work.

The 2022 revision reorganized ISO 27001's controls into four broad themes, so endpoint protection now lives under Annex A 8.1, and that covers user endpoint devices. The control states that information stored on, processed by, or accessible through endpoint devices needs protection. Encryption is widely treated as the most effective way to protect data at rest under that control, but the standard stops short of naming an algorithm or a validation level. It leaves that decision to the organization's own risk assessment.

It's a reasonable design choice, because the standard has to apply across industries with wildly different risk profiles. But if you're pursuing both ISO 27001 and CMMC certification at once, it becomes a real burden. CMMC's FIPS validation requirement is specific and non-negotiable. ISO 27001's risk-based approach is documentation-heavy and open-ended. So you have to meet CMMC's stricter technical bar while you still produce the risk assessments and justification paperwork ISO expects, and teams building toward both certifications often underestimate this dual burden going in.

What encryption failures cost

Regulatory encryption requirements aren't theoretical. Recent enforcement actions show what happens when organizations treat them that way, and the costs rarely stay contained to a single agency.

Blackbaud, Inc. gives the clearest picture of how fast exposure can multiply. The company stored sensitive consumer data, including Social Security numbers and bank account numbers, but it didn't encrypt it. It used weak or duplicate passwords, never set up multi-factor authentication, and didn't watch its network closely enough to catch an intrusion as it happened. A hacker got in during early 2020 and stayed inside, undetected, for three months. In 2024 the FTC finalized a consent order that required Blackbaud to build a full information security program and submit to 20 years of oversight. That wasn't the end of it: the company separately paid substantial settlements to dozens of state attorneys general and to the SEC. Missing encryption, missing MFA, and missing monitoring didn't produce one penalty. They produced several, from several different directions, over several years.

The allegations centered on failing to meet Department of Defense cybersecurity requirements while administering TRICARE contracts, including the North Region and West Region, for the Defense Health Agency, and on falsely certifying compliance in annual reports over a three-year stretch. The certification itself, not just the underlying gap, became part of the government's case.

Raytheon Companies and Nightwing Group settled allegations in May 2025 that they failed to meet required cybersecurity measures across multiple federal contracts, and they agreed to pay millions to resolve the matter.

These cases sit inside a broader federal enforcement push through 2025, where false-claims litigation goes after contractors who certified NIST 800-171 compliance but didn't meet it. The pattern across all of them is consistent: the gap between documented compliance and real technical enforcement is exactly where regulators have started looking hardest, and the cost of getting caught there runs well past the cost of building the control correctly the first time.