2026-08-02
Does encrypting a file actually exempt you from data breach notification laws?
"The file was encrypted" is one of the first things a lawyer or compliance officer wants to know after something leaks — because in several real laws, that single fact can change whether notifying every affected person is legally required at all. It's usually phrased as a "safe harbor" or an "exemption," and it sounds like a blanket pass. It isn't. Three different legal frameworks — GDPR, HIPAA, and US state breach laws — each grant something in this direction, and each one attaches its own specific technical condition that "we encrypted it" doesn't automatically satisfy.
GDPR actually has two separate notifications, and encryption only excuses one
GDPR's breach rules split into two distinct duties with two distinct thresholds. Article 33 covers notifying the supervisory authority, and its own text says that's required "without undue delay and, where feasible, not later than 72 hours," unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons — a comparatively low bar to clear. Article 34 covers something bigger: telling the affected individuals themselves, triggered only "when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons" — a higher bar. It's Article 34, specifically, that carries the named encryption exemption: notification to the person isn't required if the controller "has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption." That's a real exemption, but it's scoped to the individual-notification duty. It doesn't automatically erase Article 33's separate, lower-threshold duty to the regulator — good encryption can help clear that bar too, since it lowers the actual risk, but it's a second, independent judgment call, not the same box being checked twice.
HIPAA's version is narrower and more literal: encryption is what makes PHI "secured"
HIPAA's Breach Notification Rule doesn't apply to protected health information at all once it counts as "secured" rather than "unsecured" — and encryption, done a specific way, is one of the two methods HHS guidance recognizes for making that switch (the other is destruction). HHS guidance describes data at rest as secured when it's encrypted consistent with NIST Special Publication 800-111, and data in transit as secured when the encryption process is FIPS 140-2 validated — technical bars tied to specific named standards, not just "we used a password." Even meeting that bar isn't automatic immunity: as HIPAA Journal summarizes it, the exemption covers "breaches of secured protected health information such as encrypted data when the key to unlock the encryption has not been obtained." Same shape as GDPR's condition, different words: the data being encrypted only matters if whoever got the data didn't also get what unlocks it.
US state laws: real safe harbors, but not one uniform bar
Most US state breach-notification statutes carve out encrypted data in some form, but "encrypted" isn't defined the same way twice. California's statute (Civil Code §§ 1798.29 and 1798.82), per Davis Wright Tremaine's summary, "does not apply to information that is encrypted, so long as the encryption key was not or is not reasonably believed to have been acquired" — the key-compromise condition again, as the deciding factor rather than encryption alone. But the technical bar for what counts as "encrypted" varies state to state. Massachusetts and Rhode Island write "128-bit or higher" encryption into their statutory definitions by name (Mass. Gen. Laws ch. 93H, § 1; R.I. Gen. Laws § 11-49.3-3); California, Colorado, and Maine instead require a "generally accepted" encryption methodology, without naming a specific bit length; Tennessee ties its safe harbor directly to "the current version of the Federal Information Processing Standard (FIPS) 140-2" (Tenn. Code Ann. § 47-18-2107). Individual states amend these statutes over time, so treat this as illustrating that the bar differs by state, not as a current, exhaustive checklist for any one of them.
The condition every one of these frameworks shares
Read across GDPR, HIPAA, and the state laws above, one pattern repeats regardless of the exact legal language: the exemption isn't really about the act of encrypting a file, it's about the key staying separate from whatever got breached. An encrypted laptop stolen with its unlock key left in a sticky note on the lid is functionally the same as an unencrypted one for notification purposes, because the thing standing between the attacker and readable data was never actually missing. That makes "did we encrypt it" the wrong first question for anyone assessing whether a safe harbor applies — "where did the key end up, and did it travel with the data" is the one that actually decides it.
What this isn't: legal advice, or a certification claim
None of the frameworks above are satisfied by a marketing claim of "AES-256" on its own, and none of this is a substitute for a lawyer looking at the specific facts of a specific breach in a specific jurisdiction. Worth being precise about one more distinction, too: "uses the AES-256 algorithm" and "is FIPS 140-2 validated" are not the same statement. FIPS 140-2 is a formal certification of a particular cryptographic software or hardware module, audited and listed by name — not just a description of which algorithm a tool happens to use. A tool can use a genuinely strong, standard algorithm without ever having pursued or received that specific certification, and only Tennessee's statute, among the sources checked here, names FIPS 140-2 by number as its own bar.
Where NearSeal fits into this
NearSeal's default format derives an AES-256-GCM key from your passphrase via PBKDF2-SHA256 at 220 iterations, using the browser's own SubtleCrypto implementation — well past the "128-bit or higher" language some states use, and squarely the kind of "generally accepted" symmetric algorithm others require by name. The optional age-encryption.org format is scrypt plus ChaCha20-Poly1305 instead, for the same reason: two files, two names, no ZipCrypto-style legacy scheme hiding under either one. What NearSeal explicitly does not claim is FIPS 140-2 module certification, or that using it settles any specific legal notification question for you — that's a determination for counsel, on the specific facts. What NearSeal can speak to directly is the one condition every framework above actually turns on: the passphrase is typed by you, used locally to derive the key, and never leaves your device or touches a server NearSeal runs — so if the encrypted file itself later ends up somewhere it shouldn't, the key wasn't sitting next to it in any system NearSeal controls. What happens to that passphrase afterward — who you tell it to, where you write it down — is still entirely up to you, and it's still the detail every one of these safe harbors actually cares about.