Data Processing Agreement (DPA): Template and nFADP Obligations

Data Processing Agreement (DPA): Template and nFADP Obligations

Since Switzerland's revised Federal Act on Data Protection (nFADP, also known as revFADP or nDSG in German) came into force on 1 September 2023, Swiss businesses have been legally required to formalise their relationships with service providers that handle personal data on their behalf. This formalisation takes the shape of a Data Processing Agreement — commonly referred to as a DPA.

Whether you are a startup using a handful of SaaS tools or an established SME with dozens of vendors, understanding when a DPA is required, what it must contain, and what warning signs to watch for is now a core compliance obligation — not optional paperwork.

What Is a DPA Under Art. 9 nFADP?

Article 9 of the nFADP establishes the legal framework for commissioned data processing (Auftragsbearbeitung). The rule is straightforward: when a controller (your business) engages a processor (a third-party vendor) to handle personal data, the controller must ensure the processor provides sufficient guarantees around data protection.

The two key roles under Swiss law:

• Controller (Verantwortlicher): The entity that determines the purposes and means of processing personal data. This is your company — you decide why and how data is collected and used, and you are accountable to data subjects and the FDPIC.
• Processor (Auftragsbearbeiter): The entity that processes personal data solely on the controller's instructions. Your cloud host, CRM platform, or payroll software provider are typical processors.

A DPA is the binding contract that governs this relationship. It defines what the processor can and cannot do with your data, ensures they implement adequate security, and creates a traceable accountability chain in the event of a data breach or regulatory inquiry.

When Do You Need a DPA?

The practical test is simple: if a third party touches personal data you control, you need a DPA. Here are the most common scenarios for Swiss businesses:

Cloud Hosting and Infrastructure Infomaniak, AWS, Google Cloud, Microsoft Azure — any provider storing or running systems that contain personal data is a processor. A DPA is mandatory regardless of where the provider is headquartered.

Email Marketing Services Mailchimp, Brevo, Klaviyo, ActiveCampaign: your subscriber lists containing names and email addresses are personal data. The vendor sending emails on your behalf is a processor.

Web Analytics Google Analytics, Matomo, Plausible: even technical data such as IP addresses or session identifiers qualifies as personal data under nFADP. Analytics providers are processors, and a DPA is required.

CRM and Sales Platforms Salesforce, HubSpot, Pipedrive: customer and prospect records stored in a CRM are personal data. The CRM vendor processes this data on your behalf.

Payment Processing Stripe, Datatrans, Payrexx: payment providers handle customer financial data. Most major providers make their DPA available in account settings or legal documentation pages.

HR and Payroll Software Abacus, Sage, Personio: salary data, employment contracts, sick leave records, and performance reviews are among the most sensitive personal data your business holds. The DPA obligation is especially critical here.

Customer Support Tools Zendesk, Freshdesk, Intercom: support tickets routinely contain personal data from your users. Any tool your support team uses to manage tickets is a processor.

Accounting Software Bexio, Banana, QuickBooks: accounting tools process customer and supplier data including names, addresses, and financial details.

Required Clauses in a nFADP-Compliant DPA

A DPA that meets nFADP requirements must address the following elements:

1. Processing on Instructions Only The processor may only process personal data according to your documented instructions. Any use of your data for the processor's own purposes — advertising, AI model training, benchmarking — is prohibited unless you explicitly agree.

2. Confidentiality All personnel with access to your data must be bound by a confidentiality obligation. This applies to the processor's employees as well as any sub-processors they engage.

3. Technical and Organisational Measures (TOMs) The processor must describe and implement appropriate security measures proportionate to the risk: encryption at rest and in transit, access controls, logging and monitoring, backup procedures, patch management, and incident response plans.

4. Sub-processors The DPA must specify whether the processor can engage further sub-processors, and under what conditions. You should either require prior written approval for each sub-processor, or at minimum receive notification of any changes with the right to object.

5. Assistance with Data Subject Rights When your customers or employees submit requests to access, correct, delete, or port their data, your processor must be contractually obligated to help you respond — including when the relevant data sits within the processor's systems.

6. Data Breach Notification In the event of a security incident, the processor must notify you without undue delay (ideally within 72 hours) so you can fulfil your own reporting obligation to the FDPIC if the breach poses a high risk to data subjects.

7. Data Return and Deletion At contract termination, you must be able to retrieve all your data in a usable format. The processor must then confirm the secure deletion of all copies, including backups.

8. Audit Rights You must have the right to verify the processor's compliance with the DPA — directly or through a mandated third party. Many large providers substitute this right with recognised third-party certifications such as ISO 27001 or SOC 2 Type II, which is generally acceptable provided the certification scope covers the relevant services.

Swiss DPA vs. GDPR Art. 28: Key Differences

If you are familiar with the EU's General Data Protection Regulation, you will recognise many parallels — the nFADP drew heavily from it. However, important differences exist:

A critical practical note: if your business processes data belonging to EU residents, you must comply with both frameworks simultaneously. A GDPR Art. 28-compliant DPA covers most nFADP requirements, but should be reviewed for Switzerland-specific elements — particularly around international transfer mechanisms and the FDPIC as the relevant authority.

DPA Template: Structure and Essential Clauses

Here is a recommended structure for a nFADP-compliant DPA:

Preamble

• Identification of the parties (controller and processor)
• Reference to the underlying service agreement
• Subject matter and duration of processing

Section 1 — Subject Matter and Scope

• Categories of personal data processed
• Purposes of processing
• Categories of data subjects

Section 2 — Processor Obligations

• Processing on instructions only
• Confidentiality obligations for personnel
• Technical and organisational measures (Annex B)
• Sub-processor management

Section 3 — Controller Assistance

• Data subject rights fulfilment
• Data breach notification procedures
• Data Protection Impact Assessment support (where applicable)

Section 4 — End of Processing

• Data return or deletion upon termination
• Timeframe and format for return
• Deletion confirmation

Section 5 — Audit and Verification

• Audit modalities and frequency
• Accepted certifications as substitutes

Annex A — Description of Processing Activities Annex B — Technical and Organisational Security Measures Annex C — Approved Sub-processors

Red Flags in DPA Contracts

Not all DPAs offer the same level of protection. Watch for these warning signs when reviewing a processor's proposed DPA:

"We may use your data to improve our services" This vague formulation can conceal AI model training, internal benchmarking, or product analytics using your customers' data. Demand a clear boundary between commissioned processing and the processor's own activities.

No sub-processor list provided If a vendor refuses to disclose its own sub-processors (infrastructure providers, CDN services, support tools), you cannot assess the risk chain. Insist on transparency — it is your legal obligation to know.

"Notification within a reasonable timeframe" An undefined breach notification window is legally problematic. You need a specific deadline (72 hours maximum) to honour your own FDPIC reporting obligations.

Audit rights hedged with unreasonable conditions Some DPAs technically grant audit rights but require six months' notice, prohibitive fees, or access so restricted that the right is meaningless in practice. Challenge these clauses.

Governing law in a jurisdiction without adequacy recognition If the processor is subject to a legal system that Switzerland has not recognised as providing adequate protection, you need additional safeguards before the data transfer is lawful.

Liability caps that exclude data protection breaches Some processors insert clauses limiting their liability to a small multiple of contract fees, even for data breaches. Ensure liability for data protection failures is not unreasonably capped.

International DPAs and Cross-Border Transfers

The nFADP tightly regulates the disclosure of personal data abroad (Art. 16–17 nFADP). When your processor is located outside Switzerland, your DPA must account for this:

Adequate countries (EU/EEA, Canada, UK, Japan, etc.): A standard DPA is sufficient without additional transfer clauses. The Federal Council maintains the current list of adequate countries.

Non-adequate countries (e.g. United States outside the DPF, India, etc.): You must add Standard Contractual Clauses (SCCs) approved by the FDPIC, or use another mechanism approved by the Federal Council (binding corporate rules, approved certification with enforceable commitments).

For US-based providers, check whether they are certified under the Swiss-U.S. Data Privacy Framework (DPF). If certified, the transfer is lawful without additional SCCs. If not certified, SCCs are mandatory and should be incorporated directly into the DPA as an addendum.

Practical tip: most major SaaS providers (Google, Microsoft, Salesforce, Stripe) offer a "Data Processing Addendum" page in their legal documentation that includes pre-signed SCCs. This is the fastest path to compliant international transfers.

How to Request a DPA from Existing Providers

If you have been operating without DPAs, here is a step-by-step approach to getting compliant:

1. Build your processor inventory: List every vendor that accesses personal data you control. Your record of processing activities (Art. 12 nFADP) is the right place to capture this.

2. Check existing documentation first: Major providers publish their DPAs online — search for "[Vendor name] data processing agreement" or look under their legal, privacy, or account settings pages.

3. For smaller or local vendors: Send a formal written request. Keep it concise: state that you are subject to the nFADP, that the vendor processes personal data on your behalf, and that you require a signed DPA.

4. Negotiate non-compliant clauses: Do not sign a DPA with glaring gaps. If a vendor refuses to negotiate, assess whether switching providers is the right course — and document your decision either way.

5. Centralise and track: Store signed DPAs in one place, with signatures, effective dates, and renewal reminders. A spreadsheet works; a dedicated compliance tool works better.

Managing DPAs with PrivaGuard Business

Tracking ten, twenty, or thirty vendor DPAs manually in spreadsheets and shared drives is error-prone and time-consuming. PrivaGuard Business includes an integrated Record of Processing Activities module (Art. 12 nFADP) that lets you:

• Register all processors with their current DPA status
• Store contract details, signing dates, and expiry information
• Receive automated reminders before DPAs expire or need review
• Generate compliance reports for internal audits or FDPIC inquiries
• Track sub-processor approvals across your vendor relationships

This centralised view makes it straightforward to demonstrate nFADP compliance to auditors, enterprise customers running vendor due diligence, or the FDPIC in the event of a complaint.

Practical Reminders for Swiss Businesses

Before wrapping up, a few important points that often get overlooked:

• The nFADP applies even without a Swiss presence: If you process data of Swiss residents from abroad, the nFADP applies to you.
• A DPA is not a privacy policy: These are two distinct documents with different audiences. Your privacy policy is public-facing; your DPA is a B2B contract with vendors.
• Review DPAs when vendors update their terms: Providers change their data practices. A DPA that was compliant two years ago may not reflect current sub-processors or infrastructure.
• Responsibility stays with you: Even with a signed DPA, you remain the controller. If your processor mishandles data, you bear accountability to data subjects and the FDPIC.
• Document your decisions: If you decide a particular vendor relationship does not require a DPA (because the vendor acts as an independent controller, for example), document why. Regulators appreciate evidence of deliberate compliance decisions.

Want to find out which third-party services are active on your website and which ones require a DPA? Run a free scan with PrivaScan — our tool automatically detects trackers, cookies, and external services, and helps you build the processor inventory you need to stay compliant with the nFADP.