A B2B SaaS vendor is a processor in almost every customer relationship. You host customer data, run the processing in your own infrastructure and act on your customer's instructions. That exact role is what every enterprise buyer scrutinises during vendor due diligence (third party risk management). Before a contract is signed, the stack arrives: security questionnaires, the demand for a signed Data Processing Agreement (DPA), the sub-processor list, statements on data residency and AI. Vendors who deliver these straight away win the deal. Vendors who get stuck in procurement for weeks lose it.

This article looks at processing from the vendor's perspective, not the customer's. We set out the obligations you carry yourself as a processor under GDPR Art. 28 and Swiss nDSG Art. 9, what the DPA your customers demand has to contain, and how to set up your processor records under Art. 30(2), your security under Art. 32, the breach notification chain and the international transfers of your sub-processors so that the answer to every vendor question is ready to hand.

The guide is written for founders, legal and compliance leads, CISOs and heads of security at SaaS companies, from the startup stage to the established ISV. At the end you will find a compact checklist you can hold up against your own status.

Clarifying roles is the starting point of any DPA. As a SaaS vendor you are a processor within the meaning of GDPR Art. 4(8) and nDSG Art. 5(k): you process personal data on behalf of and on the instructions of your customer, without deciding autonomously on the purposes and means of the processing. Your customer is the controller. This allocation applies to the customer data flowing through your platform.

It matters to separate out the data for which you are the controller yourself. For your own account, billing and marketing data, for your employees' usage data and for aggregated product analytics, you decide on purpose and means. Here you are a controller with your own information and rights obligations. A clean split between these two data categories belongs in every DPA and in your records of processing.

Product analytics and model training are the delicate part. The moment you use customer data for your own purposes, for example to improve your product or to train an AI model across all customers, you leave pure processing behind. For that processing you become a controller in your own right, you need your own legal basis and you have to address it transparently in the DPA. Many enterprise customers ask precisely this. A clear, honest answer is a selling point here.

Under GDPR Art. 28(3) the Data Processing Agreement is mandatory and must be concluded in writing (including electronically) before processing begins. nDSG Art. 9 requires the same in substance and is more open on form, but in practice writing is indispensable. As a vendor you ideally bring your own, reviewed DPA. That shortens negotiation, signals maturity and stops you signing a third party contract with unfavourable clauses for every customer.

Art. 28(3) lists the mandatory content: subject matter, duration, nature and purpose of the processing, the type of personal data and categories of data subjects, and the obligations and rights of the controller. It adds eight processor obligations: process only on documented instructions, ensure confidentiality of the persons involved, ensure security under Art. 32, observe the conditions for sub-processors, assist with data subject rights, assist with security, breaches and the data protection impact assessment, return or delete the data at the end, and make audits possible and demonstrate compliance.

For a CH/EU setup you build the DPA to the GDPR standard and add the Swiss specifics (reference to the nDSG, the Swiss adaptation of the Standard Contractual Clauses per FDPIC guidance). A pure nDSG DPA is not enough for customers with an EU nexus. A well built vendor DPA covers both legal areas in a single document.

Hardly any SaaS vendor operates without sub-processors: cloud hosting, email delivery, monitoring, support tooling, payments and, increasingly, AI inference providers. Every one of these providers that processes customer data is a further processor within the meaning of GDPR Art. 28(2) and (4). Three duties fall on you as the vendor.

Authorisation: you may engage a sub-processor only with the customer's prior specific or general written authorisation. In practice SaaS vendors work with general authorisation plus a change procedure: you maintain a current sub-processor list, announce new or replacement sub-processors with reasonable notice (typically 30 days) and grant the customer a right to object.

Flow-down: you have to impose on every sub-processor, by contract, the same data protection obligations you owe your customer (Art. 28(4)). This pass-through duty is no boilerplate: you remain liable to the customer for your sub-processors' compliance.

Transparency: a complete, maintained sub-processor list with name, location, processing purpose and the data categories involved is one of the first documents enterprise procurement asks for. Publish that list in your trust center, keep it current and set up a notification channel customers can subscribe to for changes. That answers a whole set of questionnaire items before they are even asked.

Processors have to keep their own records of processing activities (ROPA). GDPR Art. 30(2) defines their content separately and more leanly than the controller records under Art. 30(1). They must contain: the name and contact details of the processor (your company), of every controller on whose behalf you act, and where applicable of the representative and the data protection officer; the categories of processing carried out on behalf of each controller; where relevant, transfers to third countries with the country and the safeguards; and a general description of the technical and organisational security measures under Art. 32(1).

The nDSG sets out a records duty in Art. 12 as well. Small companies under 250 employees are partly exempt under the nDSG, but the exemption does not apply to extensive processing of sensitive personal data or to high-risk processing. A SaaS vendor processing large volumes for many customers can generally not rely on the exemption.

Beyond the legal duty, there is a practical benefit: a maintained Art. 30(2) record is the source you feed security questionnaires, data-flow diagrams and sub-processor lists from. Keep the record structured, for example in the Priverion Platform, and you answer vendor questions from a single, current data base instead of scattered spreadsheets.

GDPR Art. 32 and nDSG Art. 8 with the implementing ordinance require technical and organisational measures appropriate to the risk: pseudonymisation and encryption, confidentiality, integrity, availability and resilience of systems, the ability to restore access after an incident, and a process for regularly testing effectiveness. As a processor you carry this duty directly, not just by contract. This is exactly where questionnaires, ISO 27001 evidence, SOC 2 reports and penetration-test results your customers want to see come in.

On a personal data breach an important point applies to you as a processor: the 72-hour deadline to notify the supervisory authority under Art. 33(1) falls on the controller, not on you. Your duty under Art. 33(2) is to notify the controller without undue delay after becoming aware, so the controller can meet its 72-hour window. In practice, without undue delay for the vendor means a very short period, often contractually fixed at 24 to 48 hours from awareness.

Build a clear notice chain: detection, internal triage, classification as a notifiable breach, notification of every affected controller with the information it needs for its own filing (nature of the breach, the data categories and number of people affected, likely consequences, measures taken), and support for the controller's authority and data subject notices. The nDSG sets out its own notification logic to the FDPIC in Art. 24, triggered by the controller at high risk, with the processor notifying the controller. Keep the notice chain ready before the first incident occurs. SIDD is set up as a governance and advisory partner and does not run an in-house 24/7 SOC or a managed incident response service.

As soon as a sub-processor sits outside Switzerland, the EU/EEA and the countries with recognised adequate protection, you need an additional transfer safeguard. The standard today is the EU Standard Contractual Clauses (SCC, Implementing Decision 2021/914), supplemented for Swiss matters by the adaptations per FDPIC. For transfers to the US you can rely on the EU-US Data Privacy Framework (for EU data) or the Swiss-US DPF (recognised by the FDPIC), provided the recipient is certified and the relevant data type is covered by the framework. Check the certification of the specific sub-processor, not just of the group.

The SCCs come with a transfer impact assessment (TIA): a documented assessment of whether the law and practice in the destination country undermine the protection of the transferred data, and which supplementary measures (encryption with keys held by the customer or in the EU/CH area, pseudonymisation, strict access controls, transparency over government requests) secure the level of protection. The TIA is not a formality but a substantive part of the transfer decision and a document demanding enterprise customers want to see.

Data residency is increasingly a buying criterion. Many customers in Switzerland and the EU ask explicitly for EU or CH hosting. If you can offer region choice, EU/CH data residency or customer-held key management, document it clearly in your trust center. That shortens the transfer discussion and defuses many questionnaire items.

Hold your status up against these points:

• Roles cleanly separated: customer data (processor) vs your own data (controller), including product analytics and model training.
• Your own, reviewed vendor DPA under GDPR Art. 28 and nDSG Art. 9, ready to use without per-customer negotiation.
• A current sub-processor list with location, purpose and data categories, published in your trust center, with change notification and a right to object.
• Flow-down DPA concluded with every sub-processor.
• Records of processing under GDPR Art. 30(2) and nDSG Art. 12, maintained and usable as a source for questionnaires.
• Art. 32 measures documented and backed by ISO 27001, SOC 2 and pentest evidence.
• Notice chain to the controller defined, with a concrete deadline (24 to 48 hours) and a template.
• SCCs plus TIA for every non-EU/CH sub-processor, DPF certification checked.
• Data residency statement and AI feature governance prepared.

SIDD builds this layer as legally led advisory work. We draft your vendor DPA, the ROPA under Art. 30(2), the sub-processor and flow-down contracts, the SCCs with TIA and the notice chain. As your external data protection adviser (nDSG) and external Data Protection Officer (GDPR Art. 37) we take on the ongoing upkeep, and through an ISO 27001/ISMS mandate and penetration testing we deliver the security evidence your customers demand. That turns data protection from a cost item into a sales argument. Request a quote or write to us via the contact form.