Data Security Compliance: A Practical Guide for Regulated Industries

There is a consistent pattern across CMMC Level 2 assessment failures, HIPAA OCR settlements, and FTC Safeguards Rule enforcement actions. The organization had a compliance program. The system security plan (SSP) was complete. The policies were signed. The controls were documented. The data still got out.

This is not a coincidence. Data security compliance and data security are related, but they are not the same thing. Compliance is about demonstrating that controls exist. Security is about ensuring those controls actually work, on data, wherever it travels. Most regulated organizations have the first. Many are missing the second.

The gap between those two things is where breach notifications, assessment failures, and enforcement actions live.

What Do Regulated Frameworks Demand?

The frameworks generating the most active enforcement share the same structure: they require organizations to 

1. Know what sensitive data they have
2. Implement technical controls to protect it
3. Produce evidence that those controls are working. 

Most compliance programs execute step one reliably. They partially address step two. Step three exposes the gap.

CMMC Level 2 / NIST SP 800-171

The most technically demanding framework in the defense industrial base. 110 controls across 14 practice families, assessed by an authorized third-party organization (C3PAO). The controls that most commonly surface assessment failures are not the process controls, they are the technical ones.

SC.3.177 requires FIPS-validated cryptographic modules (transitioning to active FIPS 140-3 standards as the FIPS 140-2 sunset window closes) for CUI. The validated module must hold a current CMVP certification certificate number; assessors ask for it.AES-256 as an algorithm is necessary but not sufficient; the module implementing it must hold the certificate. An organization using Microsoft 365 as its encryption layer may be relying on platform encryption that uses AES-256 but whose specific CMVP certificate it has never verified.

SC.3.187 requires that the organization establish and manage its own cryptographic keys. "We use Microsoft 365 and the encryption is built in" is the most commonly cited SC.3.187 failure mode. Microsoft manages those keys; the organization does not.

Both controls are on the POA&M-prohibited list for Phase 2 enforcement beginning November 10, 2026. They cannot be deferred; they must be implemented before the C3PAO assessment.

HIPAA Security Rule (45 CFR § 164.312)

HIPAA requires technical safeguards for ePHI covering access controls, audit controls, integrity controls, and transmission security. Encryption of ePHI at rest and in transit is "addressable", meaning the organization must implement it or document why an equivalent alternative provides the same protection. In practice, OCR treats unencrypted PHI as a significant risk finding.

The HIPAA encryption safe harbor (§ 164.402(2)) is important: properly encrypted PHI does not trigger mandatory breach notification obligations. The condition is specific — decryption keys must not be accessible to unauthorized users. Platform-managed encryption, shared passwords on PDF attachments, or keys held by a cloud provider that the government can subpoena may not qualify for the safe harbor.

ITAR / EAR

ITAR has no audit cycle. It has a penalty schedule: $1,271,078 per violation (2025 figure), or twice the transaction value for civil violations. Criminal exposure runs to $1,000,000 per violation and 20 years imprisonment.

The compliance requirement is direct: ensure that ITAR-controlled technical data is not accessible to unauthorized persons, including foreign nationals. The "deemed export" rule means that storing controlled data on infrastructure accessible to foreign national employees — including those of cloud providers — is a potential violation regardless of where the servers are physically located.

The ITAR encryption safe harbor (§ 120.31) provides a workable path: properly encrypted technical data is not considered a regulated export because it cannot be accessed without authorized decryption. The key must remain under organizational control. Data can live in cloud infrastructure, travel to suppliers, and move through AI workflows — and remain ITAR-compliant — as long as the encryption key never leaves authorized hands.

GLBA Safeguards Rule (16 CFR Part 314)

The FTC's revised Safeguards Rule requires financial institutions to encrypt customer nonpublic personal information (NPI) both at rest and in transit, and to enforce access controls calibrated to data sensitivity. Non-compliance triggers severe statutory penalties under the FTC Act, allowing for civil penalties of up to $53,088 per violation. For an organization exposing thousands of customer records across multiple days of non-compliance, statutory liabilities scale rapidly into multi-million dollar enforcement actions before a formal resolution is filed.

The Compliance-Protection Gap

Here is the gap that generates enforcement actions in organizations that have compliance programs.

Compliance programs document what controls should be in place. The SSP, the risk assessment, the policies, and procedures, these describe the intended security posture. Assessors and auditors review the documentation and the evidence that controls are implemented.

The gap appears when the technical implementation doesn't match the documentation. Not because of dishonesty, because the documentation describes a policy-layer control while the technical reality is different.

A defense contractor writes in their SSP: “CUI is encrypted using FIPS-validated modules.” The implementation is Microsoft 365 with default platform encryption." The implementation is Microsoft 365 with default platform encryption. The platform uses AES-256 — an approved algorithm — but the organization has never verified the specific CMVP module certificate, and the keys are managed by Microsoft. The SSP says one thing, the technology does something adjacent but different.

A healthcare organization writes in its risk analysis: "PHI is encrypted in transit and at rest." The implementation covers the EHR with TLS for transmission and platform encryption at rest. But PHI leaves the EHR daily — in billing exports, referral letters, research datasets, and clinical communications. Those files are often unencrypted once they clear the platform boundary.

That's not a compliance failure in the formal sense. It is the structural gap between what the compliance program documents (what controls should exist) and what the security program actually enforces (whether those controls follow the data).

That's not a failure of your compliance program; it's a limitation of the model.

The Three Layers a Complete Data Security Compliance Program Requires

Organizations that pass CMMC assessments, survive OCR audits, and satisfy FTC examiners have built a stack, not a single tool.

Layer 1 — Governance and documentation. GRC platforms (ServiceNow, Archer), SSP management, risk assessment methodology, policy libraries, POA&M tracking. This is the compliance layer. It organizes the program, manages evidence, and documents the controls.

Layer 2 — Infrastructure and access controls. Identity management (Microsoft Entra ID, Okta), endpoint management (Intune, CrowdStrike), network controls (ZTNA, segmentation). This layer enforces who can reach which systems.

Layer 3 — Data-level controls. Per-file FIPS 140-3 validated encryption (Theodosian), organization-controlled key management, context-aware access policies at the document level, per-file audit logging. This layer enforces what happens to the data itself, wherever it travels.

The documentation and compliance evidence that frameworks require live in Layer 1. The infrastructure controls are Layer 2. The data-level controls that assessors, examiners, and regulators are increasingly focused on are Layer 3.

The most common gap: Layers 1 and 2 are in place. Layer 3 is missing. The SSP documents encryption. The infrastructure protects the network. The data leaves the network every day in files that carry no encryption, no access policy, and no audit trail beyond the download event.

Framework-by-Framework: The Data-Layer Requirements

The pattern is consistent. Every framework requires documentation (Layer 1) and technical controls at the data layer (Layer 3). The documentation requirement is met by most compliance programs. The data-layer technical requirement — specifically at the file level, where data actually travels — is where gaps appear and where enforcement actions are found.

Building Your Security Data Layer

The data-layer requirement maps directly to what CMMC, HIPAA, and ITAR specifically require:

FIPS 140-3 validated per-file encryption directly satisfies SC.3.177. Each document gets its own cryptographic key. The CMVP certificate number is available for SSP documentation. Assessors can verify it.

Organization-controlled key management addresses SC.3.187's most common failure mode. When keys are derived from seeds the organization holds — not from infrastructure a cloud provider manages — the organization controls access to its own CUI. A government subpoena to the cloud provider yields nothing useful because the provider holds no readable data.

Per-file access controls satisfy MP.2.121 media protection by ensuring CUI is protected on any device — managed or unmanaged — not just devices enrolled in MDM. The same encryption applies whether the file is on a corporate laptop or a contractor's personal machine.

Per-file audit logging at the document level — not just platform-level events — provides the contemporaneous access evidence that OCR, FTC examiners, and C3PAO assessors are asking for. The question "who accessed this specific file on this specific date, from this device?" gets a clean answer instead of a SIEM summary.

Retroactive access revocation means that when a contractor's engagement ends, an employee leaves, or a file is shared in error — access is terminated immediately. No file retrieval required and no trust in the recipient's cooperation.

Control that travels with the data. That's the difference between a documented compliance program and one that holds up when something goes wrong.

Next steps? You choose.

1. Do Nothing — Maintain a documented compliance posture that depends on every person, platform, and workflow handling sensitive files exactly as intended. One downloaded file, one forwarded email, one cloud provider managing keys that should be yours — and the gap between documented compliance and actual protection becomes visible at the worst possible moment.

2. Make Your Compliance Real at the Data Layer — Per-file FIPS 140-3 encryption, organization-controlled keys, context-aware access controls, per-file audit logs. The controls your compliance program documents are the controls your data actually enforces — in every environment, on every device, wherever the file travels.

FAQs: Data Security Compliance For Regulated Industries