What Your Breach Response Looks Like When Files Are Per-File Encrypted vs. When They Aren't

The incident response playbook triggers. The attacker is in. Files are moving out the door. Your forensics team starts scoping the blast radius.

What happens next — whether you send breach notifications, file regulatory disclosures, face enforcement fines, or pay remediation costs — is substantially determined by something that was decided long before. It was decided when your organization chose how to encrypt files.

Most security teams don't frame it this way. Encryption is a technical control. Incident response is an operational process. They live in different departments, different budget lines, different conversations.

But they converge directly in every major regulatory framework that governs breach response. HIPAA Safe Harbor. SEC Item 1.05. FTC Safeguards Rule. CMMC incident reporting. Each framework has a threshold below which breach response obligations shrink — and whether you're above or below that threshold depends heavily on whether the attacker got readable data.

The HIPAA Safe Harbor: Encrypted PHI Is Not a Reportable Breach

The HIPAA Breach Notification Rule creates an exception that is precise and often underutilized: if unsecured PHI is involved, breach notification is required. If the PHI was secured using the methods specified in 45 CFR § 164.402, notification may not be required.

Secured PHI, under HHS guidance, means PHI that was encrypted in accordance with HHS encryption guidance — specifically NIST Special Publication 800-111 and related standards. When PHI is encrypted to this standard, and the decryption keys were not acquired by the attacker, the information "is not readable, decipherable, or otherwise able to be used by an individual" — and the Safe Harbor applies. The incident is not a reportable breach.

Walk through what this means in practice.

Scenario A: A hospital's billing processor is breached. The attacker exfiltrates a file server that contains PHI in folder-level encrypted storage. The folder encryption uses the processor's own tenant-level key, managed by the cloud provider. The attacker gained access via a compromised admin account — a valid session that could access the encrypted storage. The files were decryptable during the session. The attacker had access to readable PHI.

This is a reportable breach. HIPAA notification is required for affected patients. HHS OCR must be notified. The covered entity — the hospital — faces investigation even though its own systems were not compromised. The business associate agreement created the exposure. The covered entity bears the notification cost.

Scenario B: Same billing processor. Same attacker. Same admin compromise. Same file exfiltration. But the PHI files were protected with per-file encryption at the file layer — individual files encrypted with unique keys held in the covered entity's key management environment, not the processor's tenant key.

The attacker's valid session opened the file server. What they exfiltrated was ciphertext. Decryption requires keys that were never in the billing processor's environment. The attacker cannot access the PHI contents. The Safe Harbor test is met: the PHI was encrypted, and the decryption keys were not compromised.

The covered entity assesses the incident. The PHI exfiltrated was secured. Notification may not be required. HHS OCR investigation is far less likely. The BA breach became a contained incident at the processor.

Same breach event. Different architecture. Different Safe Harbor outcome.

The SEC Item 1.05 Materiality Test

For public companies, the SEC's cybersecurity disclosure rule creates a four-business-day filing deadline after a material cybersecurity incident is determined. The materiality question turns significantly on what the attacker was able to do with what they got.

If the exfiltrated files were encrypted and the decryption keys were not accessible to the attacker, the argument for non-materiality is substantially stronger. Stolen ciphertext is not a breach of confidential information in the sense that matters to a reasonable investor — the data is in the attacker's possession but has no informational value.

If the exfiltrated files were in plaintext, or encrypted with vendor-held keys the attacker could access or compel, the materiality analysis reaches a different conclusion.

This is not the only dimension of materiality. A breach that disrupts operations, compromises system availability, or affects a public company's financial systems may be material regardless of whether the exfiltrated files were encrypted. But on the specific question of data confidentiality — the exposure of trade secrets, customer data, M&A analysis, or non-public financial information — the encryption architecture of the files is often determinative.

The four-business-day clock. The market disclosure. The investor impact. The class action exposure. These consequences track the materiality determination. And the materiality determination tracks, in significant part, whether what the attacker got was readable.

The FTC Safeguards Rule: Notification Thresholds and Enforcement Stakes

The FTC Safeguards Rule, which took full effect in April 2024, applies to financial institutions under GLBA. Its penalty regime is significant: $43,792 per violation per day, with combined enforcement actions totaling over $100 million across FY 2024-2025.

The Safeguards Rule does not create a direct Safe Harbor equivalent to HIPAA's for all incident types. But it requires breach notification to the FTC when a financial institution experiences unauthorized acquisition of unencrypted customer information affecting 500 or more customers.

The operative word is "unencrypted." When customer financial files are encrypted with per-file keys and the decryption keys are not acquired by the attacker, the notification obligation under the Safeguards Rule notification requirement may not be triggered — because what was acquired was encrypted, not unencrypted, customer information.

The FTC Safeguards Rule enforcement has focused heavily on organizations that lacked adequate encryption for customer information. An organization that can demonstrate per-file encryption with FIPS 140-3 validated cryptography and customer-controlled key management is not the regulator's target profile. The organization with plaintext customer financial files on a breached server is.

CMMC Incident Reporting: What the Clock Looks Like

For defense contractors operating under CMMC, incident reporting requirements are established under DFARS 252.204-7012. Organizations must report cyber incidents involving unclassified controlled technical information to the DIBNet portal within 72 hours of discovery.

The reporting requirement itself does not disappear with per-file encryption — the incident occurred, and DoD requires visibility into it. But the scope and severity of the required report changes based on what was actually compromised.

A contractor that reports: "We experienced a breach of our file server. All CUI on the affected system was protected with per-file FIPS 140-3 validated encryption with keys held outside the compromised environment. No CUI was accessed in readable form." — that contractor's report looks different from one that cannot make that statement.

The DoD's incident response team assesses reports for indicators of compromise, scope of CUI exposure, and likely impact on defense programs. A report that can affirmatively state CUI was encrypted and keys were not compromised is a substantially different document from one that must disclose unprotected CUI exposure.

And in the subsequent relationship with the prime contractor, and in any audit of the contractor's CMMC posture, the encryption architecture is either an asset or a liability.

What the Architecture Actually Changes

The common thread across HIPAA Safe Harbor, SEC materiality, FTC Safeguards notification, and CMMC incident reporting is this: the regulatory outcome of a breach is not just determined by whether the breach occurred. It's determined by whether the attacker got anything useful.

Damage prevention, not damage control. The framing matters.

When files are per-file encrypted with unique keys held outside the compromised environment, an attacker who exfiltrates those files gets ciphertext. The ciphertext has no informational value. The incident occurred — it requires investigation, containment, and forensic documentation. But the regulatory consequences that flow from data exposure — breach notification, SEC disclosure, regulatory enforcement — track data exposure, not data movement.

Per-file encryption means data moved. It doesn't mean data was exposed.

When files are protected only by container-level encryption, or by tenant encryption managed by the cloud provider, a compromised authenticated session often provides access to readable files. The attacker gets readable data. The incident escalates to a data exposure. Every regulatory obligation kicks in.

Two companies. Same breach. The file architecture decided which outcome applied before the incident occurred.

Preparing Incident Response for the Conversation That Follows

The week after a breach, your legal team will be in one of two conversations.

In one version, they are explaining to your Board, your regulator, and potentially your customers that data was exposed, that notification is required, and that remediation costs will begin accruing. The conversation lasts months.

In the other version, they are confirming that the incident was contained, that the files exfiltrated were ciphertext, that key management was not compromised, and that the regulatory frameworks applicable to your data do not require notification based on the incident as scoped. The conversation lasts a week.

The architecture determines which conversation happens. When the container breaks, the file doesn't, but only if the file had its own defenses.

FAQs: Breach Response & Per-File Encryption