The data processing agreement, in Swiss usage Auftragsbearbeitungsvertrag (ABV), commonly imported from GDPR usage as AVV, in English Data Processing Agreement (DPA), is the central legal basis when a controller has personal data processed by a third party. Without a robust AVV the controller breaches Art. 9 DSG (CH) or Art. 28 GDPR (EU), both fines-backed duties.

This article explains step by step what a good Swiss AVV must contain, where it differs from the GDPR standard and which clauses are routinely missing in day-to-day audits. You receive:

• the line between processing and disclosure to an independent controller;
• the requirements of Art. 9 DSG with the three core duties (data security, processing within the scope of the mandate, sub-processor only by approval);
• the differences from Art. 28 GDPR and their consequences for contracts with an EU nexus;
• a full clause checklist with 12 must-have items;
• handling of sub-processors and cross-border transfers;
• the most common weaknesses in off-the-shelf AVVs from large providers (Microsoft, Google, AWS, Salesforce).

The audience is DPOs, legal counsel, CISOs and procurement leads. The template referenced at the end of this article is meant as a discussion base, not as unchecked copy-paste. Every AVV must be tailored to the concrete constellation because data categories, recipients, processing purposes and sectoral duties vary.

A data processing relationship under Art. 9 DSG arises where a third party processes personal data on behalf of and following the instructions of the controller, without independently deciding on the purposes and means of the processing. Three classic constellations:

• Cloud and SaaS providers: Hosting of CRM, HR and customer data in SaaS solutions (Salesforce, HubSpot, Microsoft 365, AWS).
• IT outsourcers and managed service providers: Operation of servers, networks, backup, SOC, helpdesk.
• Specialised service providers: Payroll, mailing, print, archive, secure destruction.

To be distinguished from transfer to an independent controller: where the recipient uses the data for their own purposes (e.g. credit bureaus, banks for payment, authorities under statutory duty), no AVV is needed; information duties and cross-border rules apply instead. This distinction is the most common error in practice, e.g. for email service providers, payment service providers or analytics tools where role allocation is non-trivial.

Important: an intra-group data flow between sister companies is also processing where one subsidiary processes for another. Intra-group AVVs are often forgotten and become a weak point in FDPIC or customer audits.

The two regimes are closely related functionally but differ in detail. Four differences matter in practice:

Form requirement: Art. 28(9) GDPR requires written form, expressly including electronic form. The DSG requires no specific form, theoretically allowing oral agreements, but the written form is essential in practice, if only for evidence. Anyone handling EU data is bound by the GDPR form anyway.

Mandatory content: Art. 28(3) GDPR lists eight mandatory items (subject matter, duration, nature and purpose of processing, type of data, categories of data subjects, rights and obligations of the controller plus eight processor duties). Art. 9 DSG is more open in wording but requires comparable content; the controller's duty of care leads to the same clause depth.

Sub-processors: GDPR requires specific or general written prior authorisation for engaging further processors, with prior information and right to object (Art. 28(2)). Art. 9(3) DSG also requires authorisation but is less formalised. In practice: mirror both regimes explicitly in the AVV.

Cross-border transfer: Art. 16 et seq. DSG (transfer rules) and Chap. V GDPR run in parallel. For US transfers the Swiss-US DPF (for CH) and EU-US DPF (for EU) suffice today for certified recipients; otherwise EU SCC with Transfer Impact Assessment.

Practical conclusion: AVVs for a CH/EU setup follow the GDPR standard and add Swiss specifics. Pure DSG-only AVVs are not sufficient in most international constellations.

A complete AVV to Swiss and EU standard contains the following 12 clause sets:

1. Subject matter and duration: What processing, what scope, what term.
2. Nature and purpose of processing: Collection, storage, transmission, deletion etc.
3. Type of personal data and categories of data subjects: Concrete listing in the annex.
4. Rights and obligations of the controller: Including instruction rights.
5. Processor following instructions: Processing only on documented instructions; duty to inform the controller of unlawful instructions.
6. Confidentiality: Confidentiality obligation of personnel (Art. 28(3)(b) GDPR / Art. 9 DSG).
7. Technical and organisational measures (TOMs): Concrete listing in the annex; encryption, pseudonymisation, access controls, backup, monitoring, incident response.
8. Engagement of sub-processors: List in the annex, information duty on changes, right of objection by the controller, pass-through of AVV duties.
9. Cooperation duties: For data subject rights, DPIA, FDPIC consultation, breach notification.
10. Data breaches: Duty to inform the controller without delay, contents of the notification, support with the FDPIC notification.
11. Audit rights: On-site audit, third-party reports (e.g. ISO 27001 reports, SOC 2 Type II), reasonable notice, cost arrangement.
12. Termination: Return or destruction of data after contract end, evidence, retention duties.

Additionally for cross-border transfers: annex with EU SCC (Module 2 / Module 3 depending on constellation), Swiss adaptation of the SCC per FDPIC FAQ of 27 August 2021, Transfer Impact Assessment, references to supplementary measures (encryption, pseudonymisation). These annexes are not a formality but the material core of the AVV.

Correct handling of sub-processors is the most common audit finding. Four points are central:

Complete list: The AVV annex must name all current sub-processors by name and location. With large SaaS providers (Microsoft, AWS) this quickly reaches 30–80 entries including intra-group subsidiaries, AI sub-suppliers, hosting partners.

Change mechanism: The processor must announce list changes with reasonable advance notice (typically 30 days). The controller has a right of objection; if exercised, a reasonable solution must be found (exception for the sub-processor, alternative configuration, extraordinary termination right).

Pass-through of obligations: The AVV duties must be contractually passed through to the sub-processor with the same quality. This pass-through duty is expressly regulated in Art. 28(4) GDPR and is standard in DSG practice.

Cross-border transfer: Where the sub-processor sits outside Switzerland, the EU/EEA and other countries with adequate data protection, an additional legal basis is required. Standard today: EU SCC with Swiss adaptation per FDPIC annex, plus TIA, plus supplementary safeguards. For the US: check Swiss-US DPF certification of the sub-processor (recognised by the FDPIC from 15 September 2024).

Practical note: standard AVVs of large US providers are often drafted in the provider's favour (e.g. broad definitions of instructions, limited audit rights, fast inclusion of new sub-processors). With significant data volume or sensitivity, push for renegotiation, it has become more realistic because large providers also feel regulatory pressure.

Audit rights are often on paper but rarely exercised. Three models shape practice:

On-site audit: Classic with appointment, inspection, interviews. Contractually provided, in practice rarely possible with large cloud providers and not economically sensible. With specialised vendors (print, payroll, archive) sensible and regularly performed.

Third-party reports: SOC 2 Type II, ISO 27001 certificate with current audit report, C5 attestation (relevant for public sector and health), HDS certificate for French health data. These reports are today the primary source of effectiveness review for large providers.

Self-attestations: Questionnaires, Vendor Security Assessments (VSA), CAIQ (Consensus Assessments Initiative Questionnaire). Practical in pre-screening but insufficient for sensitive processing.

In the AVV, mention all three models explicitly and require the strongest for the applicable risk class. Important is the processor's duty to provide third-party reports currently (no older than 12 months) and to respond substantively to findings. A clause that only promises reports on request without deadline or completeness duty is too weak.

Effectiveness measurement in the client workflow: at least annual review of current TOMs, sub-processor list and third-party reports. On material changes (cloud migration, new AI features, geographic expansion) ad-hoc review. Document these reviews in the processing register, they are the evidence of your duty of care in FDPIC proceedings.

In our practice we see recurring weaknesses in off-the-shelf AVV texts, particularly from large providers. Six deserve attention:

• Vague instruction definitions: Instructions are defined so broadly that every configuration counts as an instruction. Consequence: the provider can fall back on its default configuration even where it is problematic.
• Delayed breach notification: Within a reasonable time or after internal escalation is not enough. Demand a concrete deadline (24h or 48h from detection).
• Restricted audit rights: On-site audits are excluded or tied to unrealistic conditions. Third-party reports are only promised on request without an actuality duty.
• Unregulated sub-processor changes: We will inform you of material changes without deadline and without right of objection.
• Cross-border clauses too general: Reference to SCC without concrete annexes, without TIA, without description of supplementary measures.
• Liability cap too broad: Processor liability capped to annual fees or a small amount, with exclusion of consequential damages. Inappropriate for sensitive data.

Signing a standard AVV unchanged means accepting these weaknesses unprotected. Renegotiation often succeeds on individual points with medium bargaining power (especially with providers serving multiple Swiss and EU clients). With very large providers (Microsoft, Google) leverage is limited but side letters for particularly sensitive data categories are possible.

SIDD reviews, drafts and negotiates AVVs for SMEs, groups and regulated actors. We bring our own Swiss AVV template, regularly updated (DSG, EU GDPR, Swiss-US DPF, EU SCC, Swiss SCC annex) and usable for both inbound and outbound AVV constellations.

Through our mandates as Swiss data protection advisor and EU Data Protection Officer we run the ongoing AVV upkeep: onboarding of new vendors, annual reviews, sub-processor tracking, TIA updates as case law evolves. For highly sensitive setups (health, finance, AI) we add Trusted Third Party mandates where we sit as an independent supervisor between controller and processor.

An initial baseline of your existing AVV landscape (typically 5–20 contracts) takes a 2-day audit. Contact us via the contact form or request a quote. We respond within one business day with a concrete proposal and timeline.