GDPR vs nFADP: Form-Data Guide for Swiss Businesses
Dual-regulation overview for Swiss businesses handling EU and Swiss personal data in online forms. Where GDPR and nFADP align, where they diverge, and what it means for your intake forms, processors, and breach response.
A Swiss clinic takes online registrations from German patients. A Zurich-based SaaS company collects feedback forms from Spanish customers. A Geneva law firm runs an intake questionnaire used by clients across the EU and the rest of the world. In each of these everyday scenarios, two data-protection regimes apply at the same time — the European Union's GDPR and Switzerland's revised Federal Act on Data Protection (nFADP), in force since 1 September 2023.
The two laws are closely aligned by design: the nFADP was drafted specifically to preserve Switzerland's EU adequacy status, so a company compliant with one will be largely compliant with the other. But 'largely' is not 'entirely', and the differences matter — especially for online forms, which is where most businesses first touch personal data. This article is a practical, field-level comparison focused on what Swiss businesses actually do with forms.
Who this is for
Swiss businesses — SMEs, professional services, healthcare, financial services, e-commerce — that collect personal data through online forms and whose customers, patients, or users include EU residents. Also relevant for EU businesses that process Swiss resident data on any meaningful scale.
Why Swiss Businesses Often Fall Under Both Laws
The nFADP applies to any processing of personal data that has an effect in Switzerland — essentially: if you are a Swiss company, or you process data about people in Switzerland, you are in scope. The GDPR applies extraterritorially under Art. 3(2) whenever a non-EU business either offers goods or services to people in the EU, or monitors their behaviour. For most Swiss businesses with even a modest EU customer base, both conditions are satisfied at once.
This means the relevant question is not 'which law do we pick?'. It is: where do GDPR and nFADP agree (and a single control satisfies both), and where do they diverge (and you need to design for the stricter of the two)?
GDPR vs nFADP: Field-Level Comparison for Online Forms
| Topic | EU GDPR | Swiss nFADP |
|---|---|---|
| In force since | 25 May 2018 | 1 September 2023 (revised law; previous DPA goes back to 1992) |
| Extraterritorial reach | Yes — Art. 3(2) covers non-EU businesses targeting EU residents | Yes — applies to processing with effects in Switzerland |
| Adequacy status | Grants adequacy to Switzerland (transfers EU → CH are free) | Recognises EU as providing adequate protection (transfers CH → EU are free) |
| Special categories / sensitive data | Art. 9: health, biometrics, genetic, sexual orientation, religion, politics, trade union, race | Art. 5: same categories plus administrative/criminal proceedings, social assistance measures |
| Lawful basis required | Six bases (consent, contract, legal obligation, vital interests, public interest, legitimate interests) | Generally justified processing; consent required mainly for sensitive data, profiling, transfers to inadequate countries |
| Consent for cookies / form tracking | Opt-in, explicit, granular (ePrivacy + GDPR) | More permissive in principle, but EU-facing sites often default to GDPR consent |
| Right of access | Art. 15 — including copy of the data | Art. 25 — similar scope; info on source, recipients, retention |
| Right to erasure | Art. 17 — 'right to be forgotten' with specific exceptions | Art. 32 — right to have inaccurate data corrected or deletion requested; slightly narrower than GDPR Art. 17 |
| Data portability | Art. 20 — in structured, machine-readable format | Art. 28 — 'right to data portability' introduced in the revision; similar structure |
| Breach notification to authority | Within 72 hours (Art. 33) | As soon as possible (Art. 24) — no strict 72-hour clock, but authority and affected persons must be notified promptly |
| Notification to affected person | When high risk (Art. 34); exception if data was rendered unintelligible (e.g. strong encryption) | When necessary for their protection (Art. 24) or upon request of the authority |
| Fines | Up to €20M or 4% of worldwide turnover | Up to CHF 250,000 — but imposed on responsible natural persons (not companies), which creates direct personal exposure for executives and DPOs |
| Processor obligations | Art. 28 — written data-processing agreement required | Art. 9 — similar content; written agreement, documented safeguards |
| Records of processing | Art. 30 — mandatory above 250 employees or for sensitive data | Art. 12 — mandatory; SMEs processing non-sensitive low-risk data may be exempt via implementing ordinance |
| Data Protection Officer | Mandatory for public bodies and large-scale sensitive processing (Art. 37) | Not mandatory; firms may appoint a 'data-protection advisor' with specific duties (Art. 10) |
| Transfers to third countries | Adequacy, SCCs, BCRs, derogations — Schrems II applies | Federal Council country list; otherwise SCCs, safeguards, explicit consent for routine cases |
| Criminal liability | No criminal offences in the GDPR itself (member states may add) | Criminal offences for specific breaches of duty by responsible natural persons, up to CHF 250,000 fines |
Where a Single Control Can Cover Both Regimes
For online forms, the two regimes align more than they diverge. A Swiss business that implements the GDPR-level controls for its forms usually meets the nFADP bar automatically. Specifically:
- A clear privacy notice on the form page, identifying the controller, the purpose, the legal basis, retention, and the recipients of the data, satisfies both regimes
- A signed data-processing agreement with any third-party form vendor (including the hosting provider) meets GDPR Art. 28 and nFADP Art. 9 simultaneously
- Strong technical controls — encryption in transit, encryption at rest, access control — count towards Art. 32 GDPR and Art. 8 nFADP
- A breach-response playbook that targets a 72-hour authority notification meets the stricter GDPR clock; the nFADP's 'as soon as possible' rule follows from it
- A record of processing activities (ROPA) drafted to GDPR Art. 30 largely satisfies nFADP Art. 12
- Documented safeguards for transfers (e.g. SCCs for non-adequate jurisdictions) work across both regimes
A practical heuristic
For most online-form scenarios, design your controls to the GDPR bar and document the nFADP-specific points explicitly. You end up with a single operating model instead of two parallel ones.
Where GDPR and nFADP Diverge — and Why It Matters for Forms
Sensitive data: nFADP covers a broader list
The nFADP's catalogue of sensitive data in Art. 5 adds 'data on administrative or criminal proceedings or sanctions' and 'data on measures of social assistance' — categories that GDPR covers through its general processing rules rather than its Art. 9 list. For a form that asks about criminal records (employment screening, tenancy applications, financial vetting) or social-assistance history, you may need explicit justification under nFADP that is not required under GDPR Art. 9 in the same wording.
Criminal liability and named individuals
The most-cited difference is the criminal-liability structure. The nFADP attaches personal criminal liability to specific, wilful breaches by the natural person responsible — most notably, wilfully giving false information in a privacy notice, or wilfully violating the duty of confidentiality, up to CHF 250,000. This changes the incentives for executives and DPOs: a Swiss compliance failure can land on a person, not just on the legal entity. EU fines, by contrast, attach to the controller or processor as an organisation.
Cross-border transfers outside the adequacy circle
Both regimes restrict transfers to countries without an adequate level of protection. The lists are close but not identical — the Federal Council maintains its own country list under nFADP. For a Swiss business that uses a US-based form vendor, both Schrems II (GDPR side) and the Swiss transfer rules apply in parallel, and a single set of SCCs plus technical safeguards (such as end-to-end encryption that the vendor cannot decrypt) usually covers both. The architecture of the form vendor — specifically, whether it can read the submission — materially affects how much of this gymnastics you need.
Breach notification timing and content
GDPR gives 72 hours to notify the authority; nFADP says 'as soon as possible'. In practice, a single 72-hour process covers both. The more significant difference is the exception for encrypted data: under GDPR Art. 34(3)(a), if exposed data was rendered unintelligible by state-of-the-art encryption where the keys remained outside attacker control, individual notification to affected people may not be required. The nFADP does not explicitly codify this exception, but strong encryption is still a material risk-reducing factor in the 'necessary for protection' assessment under Art. 24.
Profiling, automated decisions, and high-risk profiling
The nFADP introduces a concept of 'high-risk profiling' (essentially: profiling that entails a high risk to personality rights or fundamental rights) and requires explicit consent for it. GDPR Art. 22 restricts solely automated decisions that produce legal effects. If your form feeds a decisioning or scoring model (credit, insurance, fraud, eligibility), both regimes require a careful look and explicit disclosure in the form's notice.
A Dual-Regime Checklist for Your Online Forms
Map the data
List the fields on each form, classify which contain personal data, and flag any that fall into sensitive categories under either GDPR Art. 9 or nFADP Art. 5. Note that criminal-record and social-assistance fields are only sensitive under nFADP specifically.
Identify lawful basis / justification
For each form, write down the GDPR basis (consent, contract, legitimate interests, etc.) and the nFADP justification (typically contract or legitimate interest; explicit consent for sensitive categories, high-risk profiling, or transfers to non-adequate countries).
Write one privacy notice for both
Draft the form's privacy notice to GDPR standards — controller identity, purposes, legal basis, retention, recipients, rights, contact — and ensure it also satisfies nFADP's information duty under Art. 19 (source of data, purpose, recipients, transfers, criteria for retention).
Sign a data-processing agreement with the form vendor
A GDPR Art. 28 processor agreement, reviewed against nFADP Art. 9, covers the formal side. The substantive question is whether the processor can actually read the submissions. A zero-knowledge vendor substantially narrows your exposure under both regimes.
Set retention and deletion
Define and implement a retention period per form, informed by the business need and any sector-specific rules (tax, AML, medical records). Both regimes expect retention to be no longer than necessary; nFADP Art. 6 imposes a specific lawfulness-of-retention duty.
Plan breach response to the stricter standard
Design a 72-hour playbook: detection, containment, preliminary assessment, authority notification (Swiss FDPIC + applicable EU supervisory authorities), individual notification if required, documentation. Keep encryption-as-exception squarely in mind.
Document rights-of-data-subject handling
Both regimes give the data subject a right of access, rectification, and erasure (within limits). Have a single intake process for requests — ideally via a form itself — and a single internal SLA. GDPR gives one month (extendable by two) for response; nFADP does not fix a single number but requires 'as soon as possible, at the latest within 30 days'.
Where Encrypted Forms Change the Calculation
A lot of the GDPR/nFADP 'double work' dissolves when the form vendor genuinely cannot read submissions. Data-processing agreements become narrower (the processor has no readable data to mishandle). Cross-border transfer analysis becomes more defensible (the submission leaving Switzerland is ciphertext, not content). Breach-notification exposure shrinks (the encryption exception is easier to invoke). And sensitive-category submissions gain a technical control that matches the legal weight the two regimes attach to them.
Schweizerform is designed around this architecture: zero-knowledge end-to-end encryption on every form, Swiss hosting for the response payload, and EN / DE / FR / IT native support for the typical Swiss-plus-EU customer base. It does not replace a proper compliance programme — but it collapses several of the ugliest corners of GDPR vs nFADP into a single technical control.
Bottom Line
For online forms, GDPR and nFADP overlap much more than they differ. A Swiss business that designs its forms to the GDPR bar will pass the nFADP bar in most respects; the parts that diverge — extended sensitive categories, personal criminal liability, the FDPIC's expectations, high-risk profiling — need deliberate handling but not a parallel compliance stack.
Choose a form architecture that makes the hard parts easier: a vendor that cannot read sensitive submissions, Swiss hosting for Swiss-resident data, and language support matching your actual customers. Then document the programme once, not twice.
Schweizerform gives you a single encrypted-forms layer that maps cleanly to both GDPR and nFADP expectations. Swiss hosting, zero-knowledge encryption, and full EN / DE / FR / IT support — no credit card required on the free tier.
Disclaimer: This article is general information and marketing content, not legal or compliance advice. References to the GDPR, the nFADP, FINMA/FDPIC guidance, Swiss Federal Council country lists, Schrems II case law, and related frameworks are summarised at a conceptual level and are subject to jurisdictional interpretation and future legislative change. Specific situations — including sector-specific rules (healthcare, financial, public-sector), cross-border group structures, and high-risk processing — require tailored advice. Consult qualified Swiss and EU data-protection counsel before relying on any single article, including this one, for compliance or purchasing decisions.