nFADP Compliance

Sovereign communications built for
Switzerland's *revised data protection law.*

The revised Federal Act on Data Protection entered into force on 1 September 2023. SCOVR is architecturally aligned with every key obligation — not through policy alone, but through the structure of the platform itself.

Book a compliance briefing → Download the nFADP guide
Swiss data residency Art. 9 processor compliance Privacy by design — Art. 7
1 Sep 2023
Date the revised Act entered into force — replacing the 1992 Federal Data Protection Act
CHF 250k
Maximum criminal fine per individual for wilful violation of information duties or professional secrecy
7+
Statutory rights granted to individuals over their personal data — access, rectification, portability, and more
Art. 9
Processor obligation article — written contracts required for every third party processing data on your behalf
Scope of application

The nFADP applies more broadly than its predecessor.

Any organisation that processes personal data of individuals resident in Switzerland must comply — regardless of where the organisation itself is based.

Swiss-based organisations

Every company registered and operating in Switzerland that processes personal data of natural persons. No minimum size threshold applies — sole practitioners and multinationals alike are in scope.

International organisations

Non-resident companies that offer goods or services to individuals in Switzerland, or that monitor their behaviour, must comply. Organisations without a Swiss presence must designate a local representative.

Data processors

Third parties processing personal data on behalf of a controller must operate under a written contract — Article 9 — that sets out the permissible processing activities, security measures, and sub-processor obligations.

Professional advisors

Lawyers, fiduciaries, financial advisors, tax consultants, and accountants — all of whom process sensitive client data — face heightened obligations around professional secrecy and proportionate data handling.

What the law introduced

A modernisation that raised the bar for every organisation.

The 1992 Federal Data Protection Act was drafted before smartphones, cloud computing, or widespread internet use. The revised law addresses the reality of modern data processing: automated profiling, cross-border cloud services, sensitive biometric and genetic data, and the structural power imbalance between large platforms and individuals.

The most significant change is not the expanded definitions — it is the shift from a reactive to a proactive compliance model. Organisations can no longer wait for a complaint. They must demonstrate, in advance, that their systems are built with privacy protection embedded from the outset.

For communication tools and collaboration platforms — arguably the most data-intensive category of enterprise software — this means the architecture of the product itself must satisfy the law, not just the policy documents that accompany it. A sovereign, self-hosted, end-to-end encrypted platform satisfies the structural requirements of the revised Act in ways that consumer messaging services cannot.

Five key changes from the 1992 act

Genetic and biometric data now sensitive

Expanded definition of sensitive personal data now covers genetic profiles, biometric identifiers (fingerprints, facial geometry), and location data — all subject to stricter processing conditions.

Privacy by design and by default — Art. 7

Privacy protection must be embedded into systems from inception. The highest protection level must be active by default — users must not have to opt in to privacy.

Mandatory processing activity register — Art. 12

Organisations must maintain a documented register of all data processing activities. SMEs presenting limited risk may qualify for an exemption via the Ordinance on Data Protection.

Breach notification obligation — Art. 24

High-risk security incidents must be reported to the Federal Data Protection and Information Commissioner (FDPIC) without delay. Affected individuals must also be notified where necessary.

Profiling now regulated — Art. 5 / Art. 21

Automated processing of personal data to evaluate personal characteristics is now explicitly regulated. High-risk profiling (e.g. for creditworthiness or personality analysis) requires explicit consent.

Key obligations

Six structural requirements every organisation must satisfy.

The revised Act imposes proactive duties that cannot be fulfilled through documentation alone — the underlying systems must be built to comply.

Art. 7

Privacy by design & default

Data protection must be built into the architecture of any system that processes personal data. The highest protection level — including encryption and minimum data collection — must be active by default, without any opt-in from users or administrators.

Art. 9

Data processor contracts

Every third party processing personal data on behalf of your organisation must be bound by a written contract specifying the scope, purpose, security requirements, and sub-processor restrictions. Verbal arrangements are not sufficient.

Art. 12

Processing activity register

Controllers and processors must maintain a written register of all processing activities, including data categories, purposes, recipients, retention periods, and security measures. This register must be available to the FDPIC on request.

Art. 22

Data protection impact assessment

A DPIA is mandatory before any processing that presents a high risk to individuals' fundamental rights — particularly automated decisions with legal effect, large-scale processing of sensitive data, or systematic monitoring.

Art. 24

Breach notification

Security incidents that are likely to result in high risk to affected individuals must be reported to the FDPIC promptly. The report must describe the nature of the breach, the categories and number of data subjects affected, and the remedial measures taken.

Art. 16–17

Cross-border transfer controls

Personal data may only be transferred to countries with adequate protection, or under approved safeguards such as standard contractual clauses. Transfers to jurisdictions under foreign surveillance legislation require explicit legal analysis.

Article-by-article mapping

How SCOVR satisfies nFADP requirements structurally.

Compliance is demonstrated through architecture, not documentation. Every key obligation is addressed at the platform level — before any policy is written.

Article
nFADP requirement
SCOVR architectural response
Status
Art. 4
Proportionality & data minimisation
End-to-end encryption is the default state. No plaintext data exists in transit or at rest on any intermediary server. No metadata analytics or behavioural profiling is collected.
✓ Met
Art. 7
Privacy by design & default
Encryption is enabled automatically on every channel, room, and call. No configuration is required to achieve the highest protection level. Privacy is the factory setting, not an option.
✓ Met
Art. 9
Written processor contracts
A full Data Processing Agreement is included with every SCOVR deployment. Processing scope, sub-processor list, security obligations, and audit rights are documented before any data is processed.
✓ Met
Art. 12
Processing activity register
The platform generates a full, exportable audit log of all access events, message delivery confirmations, and administrative actions. This log constitutes the processing register required by the ordinance.
✓ Met
Art. 14–15
Information obligations
The platform operates on a published, open standard protocol. Every processing activity is auditable — there are no hidden data flows, undisclosed integrations, or opaque sub-processors.
✓ Met
Art. 16–17
Cross-border transfer controls
All data is stored on servers within your designated jurisdiction — by default, Switzerland. No data transits through non-adequate countries. No foreign surveillance legislation has extraterritorial reach over your infrastructure.
✓ Met
Art. 22
Data Protection Impact Assessment
The open-standard, auditable codebase enables third-party DPIA completion without vendor dependency. SCOVR provides pre-built DPIA documentation covering all data flows, encryption mechanisms, and access controls.
Supported
Art. 24
Breach notification
The isolated, self-hosted architecture eliminates the primary vectors of large-scale breach. Built-in monitoring and anomaly detection support rapid incident identification. Incident response documentation is provided for FDPIC reporting.
✓ Met
Art. 25–31
Data subject rights (access, portability, erasure)
Data remains entirely within your controlled infrastructure. Access requests, export functions, rectification, and deletion are all operational capabilities of the platform — no third-party approval or data retrieval process required.
✓ Met
Art. 60
Criminal penalty avoidance
Structural compliance — where the architecture itself enforces privacy obligations — eliminates the conditions under which wilful violation of the Act could be alleged. The platform does not permit the categories of processing the Act prohibits.
✓ Mitigated
Data subject rights

Seven rights individuals can exercise — and how SCOVR fulfils them.

The nFADP grants individuals direct rights over their personal data. Each right requires operational fulfilment, not only a written procedure.

Art. 25

Right of access

Any individual may request confirmation that their personal data is being processed, and receive a copy of that data. Because all SCOVR data resides within your own infrastructure, access requests can be fulfilled immediately — without relying on a third-party vendor to extract records.

Art. 32

Right to rectification

Individuals may request correction of inaccurate personal data. Administrative tools within the platform allow operators to locate, review, and update records directly — without routing the request through an external data processor.

Art. 25 / OODP

Right to erasure

Where the legal basis for processing has ceased or consent has been withdrawn, personal data must be deleted. The sovereign architecture means deletion is definitive — data exists in one place, under your control, and erasure is not contingent on a vendor's processes.

Art. 28

Right to data portability

Personal data provided on the basis of consent must be deliverable in a structured, machine-readable format. The open standard on which SCOVR is built means data is never locked in a proprietary format — export is a native capability, not a future roadmap item.

Art. 30

Right to object

Individuals may object to processing carried out on the basis of legitimate interests. Granular access controls allow administrators to restrict processing for specific users, data categories, or channels — without affecting the availability of the platform for other users.

Art. 21

Automated decision-making

The nFADP regulates decisions made solely by automated processing that produce legal or similarly significant effects. SCOVR performs no automated profiling of users. No algorithmic scoring, behavioural categorisation, or automated decision affecting an individual is carried out on the platform.

FDPIC & criminal penalties

Enforcement is criminal, not administrative — and personal.

Unlike comparable frameworks in other jurisdictions, the nFADP does not impose administrative fines on organisations. Instead, criminal penalties are levied directly against the individuals responsible for the violation. The Federal Data Protection and Information Commissioner investigates potential breaches and issues binding remedial orders — which, if not complied with, are referred to cantonal prosecution authorities.

Prosecution targets individuals who wilfully violate the information obligations of the Act, breach professional secrecy, or make personal data accessible to an unauthorised third party. The personal exposure this creates — up to CHF 250,000 per individual — means that a compliance failure is not merely a reputational or financial issue for the organisation: it is a criminal matter for the persons responsible.

Criminal liability is personal. The Act does not fine the company — it prosecutes the individual who made the decision to violate it. Directors, compliance officers, and data controllers are personally at risk where wilful breach is alleged. An architecture that makes violation structurally impossible is the only complete defence.

The FDPIC has broad investigative powers: it may open proceedings on its own initiative, require organisations to hand over documentation, and issue enforceable orders requiring remediation within a set timeframe. Non-compliance with an FDPIC order triggers cantonal criminal prosecution.

How open-standard architecture supports FDPIC compliance

Auditable by any competent authority

The platform is built on a published, open protocol. Any technically competent authority — including the FDPIC — can audit the data flows, encryption implementation, and processing logic without vendor cooperation.

No hidden processing

There are no undisclosed sub-processors, background analytics services, or third-party data integrations. The FDPIC register entry for your deployment reflects all processing activities because all processing occurs within your sovereign environment.

Incident response documentation

Pre-built breach notification templates and incident response playbooks are aligned with the FDPIC reporting format — enabling the required notification to be completed within the expected timeframe even under pressure.

DPIA documentation package

A complete Data Protection Impact Assessment documentation set is provided with every deployment — covering data flows, encryption mechanisms, access controls, and risk mitigations — ready for FDPIC review or internal governance.

Binding remediation capability

If an FDPIC order requires a change to processing activities, the self-hosted architecture means changes can be implemented immediately — without waiting for a vendor to update a multi-tenant platform affecting thousands of other customers.

Sovereign platform — nFADP technical compliance

Swiss data residency by default

All data — messages, files, call recordings, user profiles — is stored on servers physically located in Switzerland. No data transits through foreign cloud infrastructure. Art. 16–17 transfer obligations are satisfied by architecture.

End-to-end encryption — default on every channel

Every message, file, and call is encrypted with keys that never leave the recipient's device. No server operator — including SCOVR — can read the content of communications. Art. 7 privacy-by-default is satisfied before any configuration is applied.

Role-based access control

Granular permissions at the room, channel, and user level ensure that personal data is accessible only to those with a documented legal basis to process it. Over-permissioned access — a primary driver of insider incidents — is prevented structurally.

Immutable audit logging

Every access event, administrative action, and message delivery is logged in an immutable, exportable record. This constitutes the processing activity register required under Art. 12 — generated automatically, without manual documentation effort.

No vendor lock-in — open standard

The platform is built on a published, non-proprietary protocol maintained by an independent non-profit foundation. Your organisation can migrate, self-host, or switch providers at any time — without permission, without penalty, and without data loss.

Why architecture is the answer

Policy documents do not process data. Platforms do.

A compliance programme that relies entirely on internal policies and training cannot satisfy the structural requirements of the revised Act. Article 7 does not say that organisations must have a policy on privacy by design — it says that data protection must be built into the technology from the outset, and that the highest protection level must be the default state.

Consumer-grade cloud messaging platforms are architecturally incompatible with this requirement. They process data on shared infrastructure, collect metadata for product improvement, route communications through servers in jurisdictions subject to foreign surveillance law, and cannot provide the data residency guarantees that Art. 16 demands.

A sovereign, self-hosted, end-to-end encrypted communications platform built on an open standard is the only category of solution that satisfies the structural requirements of the nFADP at the platform level. Every other approach — DPAs, contractual safeguards, consent mechanisms — supplements the architecture but cannot replace it.

Full compliance coverage

Built for the most demanding data protection requirements.

Every deployment includes documentation, DPAs, and architectural features aligned with the nFADP and the supporting standards that competent authorities expect.

nFADP

Swiss Federal Act on Data Protection

Architecture and processes aligned with every key obligation of the revised Act: written processor contracts under Art. 9, privacy by design under Art. 7, processing register under Art. 12, breach notification under Art. 24, and cross-border transfer controls under Art. 16–17.

Art. 7 — Privacy by design

Structural privacy protection

End-to-end encryption is not a configurable option — it is the default state of every channel and communication on the platform. No administrator action is required to achieve the highest protection level that Art. 7 mandates.

Art. 9 — Processor contract

Data Processing Agreement included

Every deployment includes a written Data Processing Agreement that satisfies the requirements of Art. 9 — defining the scope of processing, permissible sub-processors, security obligations, and the data subject rights fulfilment process.

Art. 24 — Breach notification

FDPIC-aligned incident response

Pre-built incident response documentation, breach notification templates aligned with FDPIC reporting requirements, and built-in anomaly monitoring ensure that any qualifying incident can be reported within the timeframe the Act expects.

ISO 27001

Information security management

Platform and operational processes certified to ISO 27001. Independently audited security controls, documented risk management, and a formal information security management system available for due diligence review and FDPIC enquiry.

Open standard

Independently auditable protocol

Built on a published protocol maintained by an independent non-profit foundation. Any competent technical authority — including the FDPIC — can audit the data flows and processing logic. There are no proprietary components that resist independent review.

Questions

Frequently asked.

Specific answers to the nFADP questions legal, compliance, and IT teams ask most often.

Does SCOVR qualify as a compliant data processor under the nFADP?+
Yes. A written Data Processing Agreement that satisfies the requirements of Art. 9 nFADP is included with every deployment. The agreement specifies the scope of permitted processing activities, the security measures in place, the list of approved sub-processors, audit rights, and the procedures for handling data subject requests. No additional contractual negotiation is required for basic Art. 9 compliance.
How does SCOVR support the breach notification obligation under Art. 24?+
The sovereign, isolated architecture significantly reduces the breach surface compared to multi-tenant consumer platforms. In the event of a qualifying incident, the platform provides built-in monitoring and alerting capabilities, pre-formatted breach notification documentation aligned with the FDPIC reporting template, and a documented incident response playbook. The self-hosted deployment means you have direct control over the investigation without waiting for a cloud vendor to conduct its own inquiry.
Is data stored in Switzerland?+
Yes, by default. All data — messages, files, call recordings, and user metadata — is stored on servers physically located in Switzerland. SCOVR operates its own sovereign infrastructure and does not route your data through shared cloud services based in other jurisdictions. For organisations with specific cantonal or sectoral requirements, bespoke data residency configurations are available.
How does SCOVR satisfy the Privacy by Design requirement of Art. 7?+
Article 7 requires that data protection be built into the architecture of the system, and that the highest protection level be active by default. SCOVR satisfies this structurally: end-to-end encryption is enabled on every channel automatically, without any configuration step required from the administrator or the user. Minimum data collection is enforced at the protocol level — no metadata analytics, no behavioural profiling, no content scanning. Privacy is not a setting; it is the architecture.
When is a Data Protection Impact Assessment (DPIA) required?+
Under Art. 22, a DPIA is mandatory before any processing likely to present a high risk to the fundamental rights or interests of data subjects. This typically applies to large-scale processing of sensitive personal data, systematic monitoring of publicly accessible areas, and automated decisions with significant legal effect. SCOVR provides a pre-built DPIA documentation package covering all relevant data flows, encryption mechanisms, access controls, and residual risks — enabling your legal or compliance team to complete the assessment without starting from a blank document.
How does SCOVR handle data subject access requests?+
Because all data resides within your own controlled infrastructure, access requests under Art. 25 can be fulfilled directly by your administrators — without submitting a request to a third-party vendor and waiting for their response. Administrative tools allow operators to locate, review, export, and if necessary delete personal data for a specific user, across all channels and rooms, within minutes. This operational capability is a direct consequence of the sovereign architecture.
Does the nFADP require a Data Protection Officer?+
No. Unlike some comparable frameworks, the nFADP does not mandate the appointment of a Data Protection Officer. The Ordinance on Data Protection encourages organisations to designate a data protection advisor — an internal or external expert who advises on compliance matters and liaises with the FDPIC — but this is a recommendation rather than a legal requirement. SCOVR's compliance documentation is designed to support a data protection advisor's review without generating significant additional work.

Demonstrate nFADP compliance on day one.

Book a private briefing with our compliance team. We will review your current communications infrastructure against the specific requirements of the revised Act and design a deployment that satisfies them structurally — before any processing begins.

Book a compliance briefing → Download the nFADP guide