Breach notification is a young area of law with a clear origin. California passed the first such statute in 2002, effective July 2003, requiring companies to tell residents when their personal information was acquired by an unauthorised party. Other states followed one at a time over the next fifteen years, and the set was completed in 2018 when Alabama and South Dakota passed the last two. Europe put the duty in the GDPR the same year. Canada's federal private-sector law made reporting mandatory in November 2018.
Every one of these regimes had to answer the same question: does a company have to notify when the stolen data was unreadable. Nearly all of them answered no, and the shape of that exemption is what this article is about.
What the exemption says
The GDPR handles it at Article 34, which covers notifying the individuals themselves. Notification is not required if the controller applied protection measures that render the data "unintelligible to any person who is not authorised to access it," and the regulation names encryption as an example. Note the scope: this is the exemption from telling you. Article 33, the duty to report to the supervisory authority within 72 hours, has a narrower carve-out and is generally still owed.
California takes a different route to a similar place, by writing the condition into the definition. Personal information under the statute means unencrypted data, or encrypted data where the encryption key or security credential was also taken and the company reasonably believes it could render the data readable. The key clause was added by amendment in 2016, and it matters, because without it a company could hold the key next to the ciphertext and still claim the exemption.
In US health care, the Breach Notification Rule only bites on "unsecured" protected health information. Data encrypted according to the methods the Department of Health and Human Services identified, which point at the relevant NIST publications, is secured, and its loss is not a breach for notification purposes at all.
None of these rules ask whether the data was safe. They ask whether the specific bytes that left were readable at the moment they left. Those are different questions whenever the attacker's route to the data ran through something that could already decrypt it.
The threat model the exemption assumes
The archetype behind these rules is a physical one. A laptop is left in a taxi, a backup tape goes missing in transit, a decommissioned server is resold with its drives intact, a storage bucket is exposed. In every one of those, the attacker gets bytes at rest and nothing else. Encryption at rest is a complete answer, and the exemption is entirely correct.
The dominant breach patterns now look different. Credentials are phished or bought, an application vulnerability is exploited, a third-party integration is compromised, or an intruder moves laterally to a service account. In each of those the attacker is operating inside the trust boundary, using the application's own access path, and the application necessarily holds the key. Data comes out through a query, decrypted on the way, exactly as it would for a legitimate user.
Full-disk and database-level encryption are worth deploying and do real work against a real class of loss. What they cannot do is make an authenticated query return ciphertext.
Encryption at rest with a provider-held key protects your data from anyone who steals the storage. It does not protect it from anyone who becomes the application.
This is the same boundary that envelope encryption and managed key services are built around, and those services document it plainly: they secure key material against extraction, and they authorise the application to decrypt because the application has to. The gap is not a flaw in the design. It is a mismatch between what the design covers and what the statute treats as sufficient.
Deadlines, and what starts the clock
| Regime | Deadline | Clock starts at |
|---|---|---|
| GDPR, to the supervisory authority | 72 hours | Becoming aware of the breach |
| GDPR, to affected individuals | Without undue delay, where risk is high | Becoming aware |
| HIPAA, to individuals | 60 calendar days | Discovery of the breach |
| HIPAA, 500 or more affected | Contemporaneous notice to the regulator and to media in the affected area | Discovery |
| US public companies, SEC Form 8-K | 4 business days | Determining the incident is material |
| US states, generally | Varies, from a fixed number of days to "the most expedient time possible" | Varies |
The SEC row is the one worth reading twice. Four business days sounds fast, and it runs from the materiality determination rather than from the incident or its discovery. A company that takes months to conclude an incident was material has not missed the deadline. Deadlines that start at "awareness" or "discovery" have the same property in softer form, which is part of why the interval between a breach and its disclosure is so often measured in months.
Reading a notice letter
When one arrives, most of its length is legal boilerplate and the useful content is in three places.
- The data categories. A name and email address is a phishing risk. A government identifier, a date of birth and an address together is an identity-theft risk, because those are the inputs to opening an account in your name. The categories tell you which of the two you have.
- The dates. The gap between "unauthorised access occurred" and "we discovered" is the window in which the data was in use by someone else, and it is frequently much larger than the gap between discovery and the letter.
- Any encryption claim. If the letter says the data was encrypted, it has told you the storage was encrypted. It has not told you who held the key or whether the attacker used a path that decrypted it, and there is no obligation to state either. Those are fair questions to ask.
The remedy offered is almost always credit monitoring, which notifies you after something is opened in your name. A credit freeze prevents it instead, is free in the United States, and is not the option the letter leads with. If a password was involved, change it everywhere it was reused, which is the real cost of reuse and the reason credential stuffing works. Then expect a phishing wave that uses the breach itself as its pretext, because the attacker knows you are expecting mail about it.
What the law does not reward
There is a design where the provider cannot decrypt user content at all, because the keys are derived on the user's device and never sent. Under it, a full database compromise yields ciphertext to an attacker who has become the application, since the application never had the key either.
That design gets no additional statutory credit. The exemptions are written to be satisfied by encryption at rest with provider-held keys, which is easier to operate, cheaper to support and compatible with server-side search, spam filtering and content indexing. Both configurations satisfy the same clause. Only one of them still protects the data when the attacker is authenticated to the application.
There is no regulatory pressure closing that gap, so it stays a question about which service you choose rather than a question about compliance. It is worth asking directly, because the answer is architectural and cannot be adopted after an incident: can the provider read this if compelled or compromised, and what specifically prevents it.
Haven derives its encryption keys on the device from a passphrase that is never transmitted, so there is no server-side key to seize, subpoena or lose. That costs us server-side search over message contents and any operator-held password reset, which are real conveniences that users of conventional providers get. The statute would let us use the same encryption language with or without any of that.