How Per-File Encryption Changes Whether a Cyber Incident Triggers SEC Disclosure

The breach notification your legal team is drafting isn't triggered by the breach. It's triggered by a materiality determination.

That's the structural fact most public company security programs miss — and it's the reason two companies can experience the exact same attack, the same files exfiltrated, the same attacker, and arrive at completely different disclosure obligations.

Understanding why requires looking at what the SEC's cybersecurity disclosure rule actually asks.

What Item 1.05 of Form 8-K Actually Requires

In December 2023, the SEC's cybersecurity incident disclosure rules took effect. Item 1.05 of Form 8-K requires public companies to disclose a material cybersecurity incident within four business days of determining it is material — not four business days after the incident itself.

The clock starts on the materiality determination, not the discovery.

The SEC defines materiality for cybersecurity incidents the same way it defines materiality for any corporate disclosure: information is material if there is a substantial likelihood that a reasonable investor would consider it important in making an investment decision. For cybersecurity, this means assessing the nature, scope, and timing of the incident — and whether it has a material impact (or reasonably likely material impact) on financial condition or operations.

In May 2024, SEC Director Erik Gerding issued clarifying guidance reinforcing this: Item 1.05 is specifically for incidents determined to be material. Non-material incidents can be disclosed under Item 8.01 but should not be filed under 1.05 — doing so risks investor confusion about severity.

The practical implication: materiality is a judgment call about damage, not a checklist based on incident type.

The Question Materiality Turns On

When your legal team sits down to assess whether a breach is material, they're asking several questions — but one dominates: what can the attacker actually do with what they took?

If files were exfiltrated but are encrypted with keys the attacker cannot access, the answer is "very little." Stolen ciphertext is not a breach of confidential information — it's a breach of possession. The data is in the attacker's hands, but it has no informational value. No customer data is exposed. No trade secrets are readable. No regulated information is accessible.

That's not a technicality. It's the structural reality of what "stolen" means when the stolen object is inert.

The inverse is what makes breaches materially disclosable: files that were in plaintext, or encrypted with vendor-held keys the attacker can compel or acquire, are genuinely compromised. Their contents are accessible. The harm is real. The investor impact can be substantial.

Two breaches. Same files. Different architectures. Different materiality outcomes.

How Per-File Encryption Changes the Analysis

Theodosian's per-file approach uses FIPS 140-3 validated AES-256 encryption with a unique encryption key for every file. Keys are generated client-side, managed in the customer's key management environment, and never transmitted to Theodosian in usable form.

When a file is exfiltrated — whether by a ransomware actor, a phished admin's session, or a malicious insider who knows where the drive is — what they receive is nothing. Without the decryption key, it cannot be read. The data is in their hands, and it is useless.

This is what the product boundaries document describes as the correct framing: Theodosian doesn't prevent data theft. It makes stolen data useless. That difference matters enormously in an Item 1.05 analysis.

Your legal team's materiality assessment now proceeds differently:

• What did the attacker get? Encrypted files.
• Can they read the contents? No — unique per-file keys, held in your key management environment.
• Is customer, financial, or operational data accessible? No.
• Is there a reasonably likely material impact on operations? Only if the breach affected system availability — not file contents.

This doesn't eliminate the obligation to assess materiality. There may be other dimensions — ransomware affecting operational continuity, a data exfiltration that also compromised unencrypted metadata, a supply chain attack that hit systems rather than files. Item 1.05 is a framework, not a checkbox.

But on the specific question of whether data exfiltration creates a disclosure obligation, the architecture of the files that were exfiltrated is often the deciding factor.

The Vendor-Key Problem SEC Counsel Often Misses

There's a second dimension legal teams frequently overlook: what can your encryption vendor be compelled to do?

Most enterprise encryption tools are not zero-knowledge by design. The vendor manages encryption keys on the customer's behalf. That's a service convenience — it means lost keys can be recovered, files can be accessed without IT intervention, and administration is simpler.

It also means a government agency, a foreign regulator, or a well-resourced attacker can approach the vendor directly. If a government subpoenas your encryption vendor for decryption keys — and the vendor holds them — the encrypted data becomes readable without touching your systems at all.

For ITAR-classified programs, this creates export exposure. For healthcare data, it creates a HIPAA breach notification trigger even if your systems were never compromised. For public companies, it means a vendor key disclosure can retroactively change the materiality assessment on an incident you'd already classified as non-material.

Theodosian's zero-knowledge architecture is architecturally engineered around this. Keys are generated client-side and stored in the customer's own key management environment. Theodosian, the company, cannot decrypt customer data — not because of policy, but because it doesn't hold the keys. A subpoena to Theodosian returns nothing of cryptographic value.

And in a materiality determination, it's the difference between a disclosure trigger and a contained incident.

Two Companies, Same Breach, Different Disclosure Outcomes

Walk through the scenario.

Company A stores its sensitive internal files in a SharePoint tenant encrypted with Microsoft's tenant-level key management. An attacker phishes a Global Admin account. Over 72 hours, they exfiltrate 4.3 TB of documents — board materials, customer contracts, M&A target analyses. Microsoft's service-side encryption protected files in transit and at rest, but Microsoft holds the service encryption keys. The attacker doesn't need them — they used a valid session token. Everything was readable during the session.

Company A's GC determines materiality within 48 hours. The board materials contained non-public information. The M&A analyses contained undisclosed strategic data. The customer contracts contain PII and contract terms that competitors would find valuable. Item 1.05 filing is required within four business days.

Company B stores the same categories of files, but with per-file encryption applied at the file layer — unique keys per file, managed in the company's own key management environment. The same attacker phishes the same type of account. Over 72 hours, they exfiltrate 4.3 TB of documents.

Company B's GC sits down for the materiality assessment. The attacker has possession of 4.3 TB of unreadable data. The attacker gained nothing but storage of encrypted data. The incident affected system access during the session, but no data was compromised in value.

The legal team determines the incident is below the materiality threshold. If ongoing operational impact is contained and no systems remain compromised, disclosure under Item 1.05 is not required. An Item 8.01 disclosure may be appropriate if the incident otherwise meets voluntary disclosure thresholds, but the four-business-day mandatory filing is not triggered.

Same attacker. Same files. Same exfiltration volume. Different architecture. Different regulatory outcome.

What This Means for Security Architecture Decisions

The SEC disclosure rule changed something important about how public company boards should think about data security investment.

Previously, the argument for encryption investment was about breach prevention — keeping files away from attackers. That argument struggled in boardrooms because breach prevention is probabilistic: spend more, reduce risk, but never eliminate it.

The architecture argument is different. Per-file encryption with zero-knowledge key management is not primarily about preventing breach. It is about engineering the outcome of a breach that occurs anyway. The investment shifts from "prevention" (uncertain ROI) to "materiality management" (calculable regulatory impact).

When the CFO asks what the return on file-encryption infrastructure is, the answer is now concrete: it is the cost difference between a material cybersecurity disclosure — with its market impact, regulatory scrutiny, class action exposure, and reputational cost — and a contained incident that never becomes a public event.

That's not a failure of your security program. That's not a limitation of your team. It's a limitation of the model — protecting the container rather than the content. Theodosian moves the wall to each file.

When the Perimeter Fails, the Data Must Defend Itself

The Theodosian Walls of Constantinople held for a thousand years until the threat changed shape. Modern data security is in the same transition: perimeter defenses — tenant encryption, access controls at the container level, network monitoring — work for the threat model they were built for. They fail when valid credentials walk through the front door.

Item 1.05 is, in effect, a regulatory instrument that measures whether your file architecture held when the perimeter didn't. Two companies can experience identical breach events and have materially different disclosure obligations based on one variable: did the attacker get files or ciphertext?

The data should defend itself. When it does, your legal team's materiality assessment reaches a different conclusion. That conclusion determines whether the four-business-day clock starts.

FAQs: SEC Cyber Disclosure & Per-File Encryption