Breach Notification: How Encryption Changes the Equation

Sooner or later, something goes wrong. A laptop with a database export walks out of the office. A misconfigured cloud bucket is indexed by a search engine. A contractor's GitHub token leaks. A phishing email lands on the wrong assistant. And at that exact moment, the legal clock starts ticking: 72 hours to notify the EU supervisory authority under the GDPR, 'as soon as possible' under Switzerland's nFADP, plus — in some cases — an obligation to tell every single affected person what has happened.

Strong encryption does not stop the laptop from disappearing or the bucket from being misconfigured. But both regimes draw a sharp legal distinction between a breach of data that is readable to an unauthorised party and a breach of data that is not. For decision-makers — general counsel, DPOs, CISOs, executive teams — that distinction is often the difference between a painful but manageable regulatory notification and a mass individual-notification event with reputational and financial fallout. This article is about where that distinction lives, what counts as 'encrypted enough', and how the two regimes treat it in practice.

What Counts as a Personal-Data Breach

Both regimes use a broad definition. Under the GDPR, Art. 4(12) defines a personal-data breach as 'a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed'. The nFADP, in Art. 5(h), uses essentially parallel language: 'any breach of data security involving the unintentional or unlawful loss of, deletion of, destruction of, or alteration of, personal data, or their disclosure or access to unauthorised persons'.

A few practical implications for form-based workflows:

• An incident does not have to be the work of a hostile attacker. Accidental loss — a hard drive left on a train, an email sent to the wrong group, a Google Drive shared publicly — counts
• Unavailability can count. If ransomware encrypts your database of form submissions and you have no backup, that is a 'loss' event under both definitions
• The breach lives where the data lives. A leak at your third-party form vendor is your breach as the controller, even though the operational failure was on the vendor side
• A breach of the processor is presumptively a breach the controller must be told about; the processor has its own statutory duty to inform the controller without undue delay

GDPR: The 72-Hour Clock and the Art. 34 Exception

The GDPR has two distinct notification obligations and two distinct thresholds.

Notification to the supervisory authority (Art. 33)

The controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach. The exception is tight: 'unless the personal-data breach is unlikely to result in a risk to the rights and freedoms of natural persons'. In practice, many legal teams notify even borderline cases because the cost of a justified omission that turns out to have been unjustified is much higher than the cost of an over-notification.

The notification itself must describe the nature of the breach, categories and approximate numbers of data subjects and records, the likely consequences, and the measures taken or proposed. A delay beyond 72 hours is allowed, but must be accompanied by reasons for the delay. That reasoning is itself a document that a regulator will later scrutinise.

Notification to affected individuals (Art. 34)

A much higher threshold applies to individual notification. It is required only when the breach is 'likely to result in a high risk to the rights and freedoms of natural persons'. And Art. 34(3) lists three specific situations in which even a high-risk breach does not require individual notification:

1. Art. 34(3)(a): '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'
2. Art. 34(3)(b): 'the controller has taken subsequent measures which ensure that the high risk to the rights and freedoms of data subjects referred to in paragraph 1 is no longer likely to materialise'
3. Art. 34(3)(c): 'it would involve disproportionate effort. In such a case, there shall instead be a public communication or similar measure whereby the data subjects are informed in an equally effective manner'

The first of these — the encryption exception — is the single most powerful safe harbour in the GDPR's breach architecture. It does not eliminate the authority notification (you still owe that), but it can lawfully remove the obligation to send an individual letter, email, or public statement to every affected person. The practical delta at scale, for a breach touching tens or hundreds of thousands of data subjects, is enormous.

nFADP: 'As Soon As Possible' and the Protection Calculus

Switzerland's revised Federal Act on Data Protection (nFADP), in force since 1 September 2023, approaches breach notification with similar intent but different wording.

Notification to the FDPIC (Art. 24(1))

The controller must notify the Federal Data Protection and Information Commissioner (FDPIC / EDÖB / PFPDT / IFPDT) of any breach of data security that is 'likely to result in a high risk to the personality or fundamental rights of the data subject'. The notification must be made 'as soon as possible'. There is no fixed 72-hour clock, but in practice most Swiss legal teams operate a 72-hour playbook so that they meet the GDPR standard and the nFADP simultaneously.

Notification to the data subject (Art. 24(2))

The controller must inform the affected data subject 'if this is necessary for their protection or if the FDPIC so requires'. Notably, this is a lower-friction test than the GDPR's 'high risk' trigger: the Swiss rule asks what the data subject actually needs in order to protect themselves.

The nFADP does not codify the Art. 34(3)(a) encryption exception in the same explicit wording. But it does something closer to the underlying logic: if the data never became readable to anyone outside the authorised circle — because strong encryption was applied and the keys remained uncompromised — the question 'is notification necessary for the data subject's protection?' usually answers itself. The FDPIC's guidance and the nFADP's risk-based framing both treat the actual intelligibility of the exposed data as a first-order factor.

What Counts as 'Encrypted Enough' for the Exception

Regulators have been clear that 'encryption' in the Art. 34(3)(a) sense is not a checkbox. Guidelines from the European Data Protection Board (EDPB Guidelines 01/2021) and similar FDPIC commentary treat a few conditions as necessary for the encryption exception to actually apply:

• The algorithm and key length must be considered state-of-the-art at the time of the breach — broadly, AES-256, RSA-4096 or modern elliptic-curve equivalents, or equivalent well-reviewed primitives
• The implementation must be sound — no custom crypto, no key reuse, proper IV/nonce handling, authenticated encryption (AES-GCM or equivalent) where integrity matters
• The keys must have remained outside the attacker's reach — if the same compromise that exposed the ciphertext also exposed the decryption key, there is no safe harbour
• The encryption must have been applied to the actual data that was exposed — not merely to a different copy or a different system
• Forward-looking durability matters — an algorithm considered strong today but likely broken tomorrow (e.g. by known quantum threats against certain schemes) does not give lifetime cover

A few corollaries for form-data workflows:

• Encryption at rest (full-disk encryption of database storage) helps against physical drive theft, but it does not help against a compromise of the running application — the OS serves plain text to the app, which serves plain text to the attacker
• Transport encryption (HTTPS / TLS) does not qualify: the data is readable at both endpoints
• Application-level encryption where the vendor holds the keys does not qualify if the vendor is the one breached — they had the keys
• End-to-end encryption where only the form owner holds the keys (zero-knowledge architecture) is the strongest posture: a breach of the form vendor exposes ciphertext only, and the vendor cannot hand over readable data even under legal compulsion

Decision Matrix: What You Actually Notify

At a high level, the two regimes produce the following matrix for common scenarios. This is indicative only — real incidents always have wrinkles — but it gives an idea of where encryption moves you.

The big shifts always live in the right-most column. Individual notification at scale is the part of breach response that generates press coverage, regulator scrutiny, class-action risk, and brand damage. The encryption exception is the legal mechanism that can remove that column from your playbook for a given incident — and it is entirely driven by the technical controls you put in place before the incident occurs.

A Dual-Regime, 72-Hour Playbook

Where a Zero-Knowledge Form Vendor Changes the Math

For a large class of form-driven workflows — patient intake, KYC onboarding, whistleblower reporting, legal intake, insurance claims — the breach exposure runs through a third-party form vendor. The question on the day of an incident is: what is actually sitting in the vendor's database?

With a generic form vendor, the answer is usually 'plain text'. A breach of that vendor becomes your controller-level breach, and the path through Art. 33, Art. 24, Art. 34, and individual notification is open. With a zero-knowledge form vendor — one that only stores ciphertext encrypted with keys the vendor does not hold — the same incident produces ciphertext exposure. Whether the Art. 34(3)(a) exception applies is ultimately for you and your regulator to assess, but you are standing on the side of the line where it can apply, instead of the side where it cannot.

Schweizerform is built specifically for this posture: end-to-end encryption in the submitter's browser, keys held only by the form owner, Swiss hosting for the ciphertext, and EN / DE / FR / IT support. It does not eliminate breach risk. It changes what a breach means.

Bottom Line

Breach notification under GDPR and nFADP is a timing exercise wrapped around a factual one. The timing — 72 hours, 'as soon as possible' — is unforgiving, but the facts are where decisions are made. And the single fact that consistently changes the decision, across both regimes, is whether the data that left your control was intelligible to the person who ended up holding it.

Encryption does not prevent breaches. It changes what a breach obliges you to do. For data sensitive enough that mass individual notification would be a category-defining event for your organisation, that change is usually worth designing for — not after the incident, when it is too late, but before, in the architectural choices that determine what 'the data' actually is when something goes wrong.