GDPR for SaaS Providers: 10 Obligations 2026

Main article: Creating a record of processing activities 2026 — how to build the record of processing activities under Art. 30 GDPR step by step.

As a SaaS provider you generally process customer data on instructions — you are a Data Processor under Art. 28 GDPR. That role triggers its own, clearly delimited set of obligations that differs from the set applying to your customers. The following ten points therefore consistently separate three levels: what a legal provision requires, what the Controller owes and what is your own practical decision. Each point makes clear whether it rests on a legal provision, on an obligation of your customer or on practice — and names the source where there is one.

1. Clarifying the provider/Controller role

Determine the role for each processing activity, not in a blanket way for each contract — one product can trigger both roles at the same time. For standard SaaS: the provider is a Data Processor. For analytics/pricing: often own controllership. Clarify this contractually.

The GDPR recognises three allocations that you must keep apart: Controller (Art. 4 no. 7 GDPR), Data Processor (Art. 4 no. 8 GDPR) and joint controllers (Art. 26 GDPR). A recurring documentation error in practice is to confuse processing on behalf with joint controllership — the consequential obligations are different.

Practical consequence: if you evaluate data for your own purposes — product telemetry for your own roadmap, pricing, benchmarking across tenants — own controllership may arise for that processing; you then need your own legal basis under Art. 6(1) GDPR. Processing is lawful only if at least one of the six conditions named there is met ((a) to (f)), for example consent ((a)) or the pursuit of legitimate interests ((f)). The DPA does not cover this case: it governs processing on behalf of the Controller (Art. 28(1) GDPR), whereas processing for your own purposes needs its own legal basis under Art. 6(1) GDPR.

Practical recommendation: keep a role matrix for each processing activity (core service, support, telemetry, billing, marketing) and mirror the result in the DPA, the Privacy notice and the record. Changes of role typically arise when new features are rolled out, not when the contract is signed.

2. Providing a standard DPA

Provide a ready-made data processing agreement that fully reflects the statutory minimum content — otherwise every customer review turns into an individual negotiation. A template under Art. 28 with all 8 mandatory items + sub-processor list + Schrems II annex.

Two levels of legal provisions interlock. First, Controllers may only work with Data Processors that provide sufficient guarantees of appropriate technical and organisational measures (Art. 28(1) GDPR) — your description of those measures is therefore in practice a precondition for selling. Second, processing takes place on the basis of a contract or other legal act that sets out (Art. 28(3) GDPR):

• the subject matter and duration of the processing
• the nature and purpose of the processing
• the type of personal data
• the categories of data subjects
• the obligations and rights of the Controller

These items form the framework; within it sit the eight individual obligations of Art. 28(3)(a)–(h) GDPR, three of which are dealt with separately in this article: assistance with data subject requests ((e), point 10), assistance with Art. 32 to 36 including the DPIA ((f), point 7) and evidence as well as inspections ((h), point 9).

Practical recommendation: keep the DPA as a versioned document in the customer portal, with a change history and a date. Anyone who sends the DPA by email only on request loses track, with every contract change, of which version applies to which customer.

3. Documenting sub-processors

Keep a complete, versioned list of all sub-processors — and a separate DPA for each of them. Hosting (AWS/Azure/GCP), mail (SendGrid/Postmark), analytics, support tools — all with a DPA.

Under Art. 28(1) GDPR your customers may only work with Data Processors that provide sufficient guarantees of appropriate technical and organisational measures. You apply the same standard in practice when selecting your sub-contractors. In parallel, Art. 30(2)(c) GDPR requires you to document transfers to Third Countries in your own record, including the documentation of appropriate safeguards.

In practical experience, two errors appear again and again and concern exactly this list: outdated recipient lists in which discontinued services are still named, and missing Third Country information for US tools. Both become apparent immediately as soon as a customer compares your list against their own record.

Practical recommendation: for each entry, at minimum the company name, registered office, processing purpose, data categories, region and the basis of the safeguards where a Third Country is involved. Announce changes with advance notice and version the list publicly — that spares your customers the follow-up question and you the individual proof.

4. Data protection by design + by default

Enforce privacy-friendly default settings technically instead of describing them in documentation. Default-off for tracking/advertising, Pseudonymisation in logs, encryption at rest + in transit.

The following requirements follow from Art. 32 and Art. 34(3) GDPR as well as from national telemedia and telecommunications law.

Encryption works in two ways. It is part of the appropriate technical and organisational measures under Art. 32 GDPR. Where appropriate protective measures — in particular encryption — have been applied, the communication under Art. 34(1) GDPR may not be required (Art. 34(3) GDPR); that assessment is made by the Controller. Customer-held keys are in practice the most robust starting position for this.

Tracking defaults are regulated nationally. In Germany, the storage of information in the end user's terminal equipment and access to information already stored are permitted only where the end user has consented on the basis of clear and comprehensive information; no consent is required where the sole purpose is carrying out the transmission of a message or where access is strictly necessary in order to provide a digital service expressly requested by the user (§ 25(1) and (2) of the German Telecommunications-Digital-Services Data Protection Act (TDDDG)). In Austria, the opt-in for tracking cookies follows from § 165 of the Austrian Telecommunications Act 2021 (TKG 2021). Where consent matters, the Controller must be able to demonstrate it (Art. 7(1) GDPR) and withdrawal must be as easy as giving consent (Art. 7(3) GDPR) — in the product this means: the off switch sits in the same place as the on switch.

If you expect customers to enter special categories of personal data under Art. 9(1) GDPR into your system (for example health data in HR or medical practice software), that belongs in the risk assessment of your default settings and of your technical and organisational measures. The legal basis for such processing is owed by the Controller.

5. Customer lockbox function

Support access to customer data should be approved per access, time-limited and logged — this is a practical recommendation and best practice for enterprise customers. Where support accesses customer data: approval is required for each access.

The link to the GDPR is indirect: Art. 28(1) GDPR requires sufficient guarantees of appropriate technical and organisational measures, and access control to production data is the point where, in practice, customer reviews ask in the greatest detail. A lockbox procedure makes that guarantee verifiable instead of merely asserted.

Austrian particularity: under § 6 DSG, Controllers, Data Processors and their employees are subject to a duty of confidentiality (data secrecy). Practical recommendation: implement this for support teams with access to data of Austrian customers by way of a documented confidentiality undertaking for each employee.

Practical recommendation: approval by the customer rather than by your own line manager, automatic withdrawal of rights once the period has elapsed, a log the customer can inspect, and a documented break-glass procedure for incidents, the use of which is justified after the fact.

6. Activating an EU data boundary

Fix primary hosting and every sub-processor to an EU region — and check whether the commitment also holds for backups, logs and support access. Hosting in the EU + sub-processors with an EU region. With hyperscalers: this can be activated.

Legal classification: EU hosting is not a GDPR obligation. A transfer to a Third Country is permitted where the Controller and the Data Processor comply with the conditions of Chapter V (Art. 44 GDPR), that is in particular on the basis of an adequacy decision (Art. 45 GDPR) or appropriate safeguards such as standard contractual clauses (Art. 46 GDPR). An EU data boundary is therefore a risk and sales decision that saves your customers review effort — not a statutory requirement.

What you must document regardless of that decision: transfers to Third Countries belong in your own record under Art. 30(2)(c) GDPR, including the documentation of appropriate safeguards. This also applies where you operate primary hosting in the EU but a single sub-processor — mail delivery, error telemetry, support tooling — is located outside it.

Practical recommendation: keep the allocation of regions per sub-processor as a separate column of your list (point 3) and not as running text in the DPA. Only sell an "EU region" as a commitment if it applies to the entire chain — including backups, logs and support access.

7. DPIA for high-risk functions

The data protection impact assessment is owed by your customer, your task is to contribute — the trigger is product functions likely to involve a high risk. For example AI features, profiling, automated decision-making. A 7-step template.

Clarification of roles: the data protection impact assessment is owed by the Controller (Art. 35(1) GDPR). As a Data Processor you are under a duty to assist them — the DPA provides that you assist the Controller in complying with Art. 32 to 36 GDPR (Art. 28(3)(f) GDPR).

When the threshold is reached: a DPIA must be carried out in advance where a type of processing — in particular using new technologies — is likely to result in a high risk to the rights and freedoms of natural persons, taking into account the nature, scope, context and purposes (Art. 35(1) GDPR). Art. 35(3) GDPR names three standard cases that map directly onto product functions:

• Scoring and profiling features: systematic and extensive evaluation of personal aspects producing legal effects
• Health, biometric or comparable modules: processing on a large scale of special categories of data under Art. 9 GDPR
• Monitoring functions: systematic monitoring of a publicly accessible area on a large scale

Practical recommendation: supply your customers with a DPIA contribution package rather than a finished DPIA — a data flow diagram, data categories, storage locations, deletion logic, an extract of the technical and organisational measures and a description of the models used. The assessment and the decision remain with the Controller; your contribution is the factual basis. Note in addition that processing operations subject to a DPIA can trigger a separate obligation in Germany to designate a data protection officer (see the section "Evidence you owe yourself as a Data Processor").

8. Personal Data Breach procedure with 24h customer notification

Build a notification procedure that reaches each affected Controller individually and without undue delay. In an incident: your customer must meet the GDPR deadline of 72 hours. Hence customer notification within 24 hours.

The deadlines belong to two different parties. The 72 hours apply to the Controller vis-à-vis the supervisory authority: they notify without undue delay and, where feasible, within 72 hours after having become aware of the breach; where the notification is made later, reasons for the delay must be given (Art. 33(1) GDPR). Your own obligation as a Data Processor is to notify the Controller without undue delay (Art. 33(2) GDPR). The 24-hour commitment is a practical recommendation agreed contractually through the DPA — it voluntarily tightens the statutory requirement so that your customer can realistically meet their own deadline.

What your notification must contain to be usable. The Controller must supply the supervisory authority with the mandatory information under Art. 33(3) GDPR — they can only do so if your notification provides it: a description of the breach by nature and circumstances, the approximate number of data subjects and records concerned, the data categories, the likely consequences, the measures taken to address it and to mitigate damage, as well as contact details.

Second stage. Where the breach is likely to result in a high risk to the rights and freedoms of natural persons, the Controller communicates it to the data subjects without undue delay (Art. 34(1) GDPR). That communication is not required where appropriate protective measures — in particular encryption — have been applied, where the high risk no longer exists as a result of subsequent measures or where it would involve disproportionate effort; a public communication then takes its place (Art. 34(3) GDPR).

Practical recommendation: detection and containment run technically, classification (which tenants, which data types, what scope) runs in parallel — and the notification goes to each affected Controller individually, not as a collective status message. Keep a notification form with the fields of Art. 33(3) GDPR ready so that nobody has to invent the structure in an emergency.

9. Enabling the right to audit

Enable reviews actively and answer the standard questions in advance with a ready-made evidence package. Provide at least a SOC 2 report. For critical customers: enable on-site audits.

Legal basis: the obligation is to make available to the Controller all information necessary to demonstrate compliance with the Data Processor's obligations and to allow for and contribute to audits, including inspections (Art. 28(3)(h) GDPR). A SOC 2 report is a customary aid for this, but is not required by law.

What certificates achieve and what they do not. Certification is voluntary (Art. 42(3) GDPR) and does not reduce the responsibility for compliance with the Regulation (Art. 42(4) GDPR). It may, however, be used as an element to demonstrate sufficient guarantees (Art. 28(5) GDPR) and to demonstrate compliance with the requirements for the security of processing (Art. 32(3) GDPR). A certificate therefore shortens your customer's review, but replaces neither the DPA nor the information provided in an individual case.

Practical recommendation: keep an audit package ready that answers the typical questions without an appointment — a description of the technical and organisational measures, the current sub-processor list, certification evidence, a summary of the most recent penetration test, the Personal Data Breach procedure. For on-site audits, agree lead time, scope, confidentiality and the bearing of costs in the DPA instead of negotiating each case anew.

10. Data export API for Art. 20

Provide an export that your customer can trigger without your involvement and within their statutory response deadline. A machine-readable format (JSON/CSV/XML) for customer data export.

Clarification of roles: the right to data portability is directed against the Controller; your obligation as a Data Processor is to assist them by appropriate technical and organisational measures in responding to data subject requests (Art. 28(3)(e) GDPR).

The time frame your function must fit into. The Controller provides the data subject with information on action taken on a request under Art. 15 to 22 GDPR without undue delay and in any event within one month of receipt of the request; that period may be extended by two further months where necessary, taking into account the complexity and number of the requests, and the data subject must be informed of this within one month together with the reasons (Art. 12(3) GDPR). An export that runs as a support ticket with an indeterminate processing time puts your customer's deadline at risk.

Practical recommendation: self-service in the customer portal beats any ticket procedure — across the tenant and per data subject, with a time stamp and a log for the evidence. The committed processing time for cases that cannot be automated belongs in the DPA, as does a return and deletion concept for the end of the contract.

Evidence you owe yourself as a Data Processor

Alongside the ten product-related points, you owe two separate pieces of evidence that your customers cannot provide for you: your own record of processing activities and — under certain conditions — the designation of a data protection officer.

Your own record (Art. 30(2) GDPR). A separate, shorter catalogue with four mandatory items applies to Data Processors ((a)–(d)): (a) the name and contact details of the Data Processor and of each Controller on behalf of which it is acting (where applicable, the representative, where applicable, the data protection officer); (b) the categories of processing carried out on behalf of each Controller; (c) where applicable, Third Country transfers including the documentation of appropriate safeguards; (d) where possible, a general description of the technical and organisational measures under Art. 32(1) GDPR. This record is not to be confused with the DPA — the DPA is the contract, the record is your own accountability documentation.

Data protection officer. The designation obligation of Art. 37(1) GDPR is expressly addressed to the Controller and the Data Processor: where processing is carried out by a public authority or body ((a)), where the core activities consist of regular and systematic monitoring on a large scale ((b)) or where the core activities consist of processing on a large scale of special categories of data under Art. 9 or of data relating to criminal convictions under Art. 10 ((c)). In Germany, § 38(1) BDSG is added: a designation obligation insofar as, as a rule, at least 20 persons are constantly engaged in automated processing — and irrespective of the number of persons where processing operations are subject to a DPIA under Art. 35 GDPR or where data are processed commercially for the purpose of transfer, anonymised transfer or for purposes of market or opinion research. Austria provides for no numerical threshold beyond this; there, the obligation follows directly from Art. 37 GDPR, and § 5 DSG additionally governs confidentiality and — in the public sector — freedom from instructions.

Practical assessment of the order: in enquiries from supervisory authorities and customers, the record usually comes first, followed by the DPA, the concept for technical and organisational measures and the DPIA — this is practical experience, not a review sequence laid down by law. Anyone who cannot deliver on the record loses the basis for discussing everything else.

Deadlines and practical rhythms at a glance

The following two tables separate matters strictly: the first names only statutory deadlines together with the party that owes them. The second names only practical rhythms that are not based on any statutory deadline.

Germany and Austria: what is identical and what is not

As an EU regulation, the GDPR applies unchanged in both countries — all the articles named above (Art. 28, 32, 33, 35, 42, 44 et seq., 83) are identical in wording. What differs is supervision and the national supplementary legislation:

• Supervision in Germany: for non-public bodies — that is, for SaaS companies — the state data protection authorities (Landesdatenschutzbehörden) competent under state law supervise the application of data protection law (§ 40(1) BDSG). For federal public bodies and certain providers of telecommunications services, the Federal Commissioner for Data Protection (BfDI) is competent (§ 9(1) BDSG).
• Supervision in Austria: the competent body is the Austrian Data Protection Authority (Datenschutzbehörde, DSB), which is established as the national supervisory authority under Art. 51 GDPR (§ 18(1) DSG).
• Notification channel for Personal Data Breaches: in Germany, companies as non-public bodies notify the authority competent under state law (§ 40(1) BDSG); each federal state operates its own notification portal — in Bavaria, for example, the Bavarian Data Protection Authority (Bayerisches Landesamt für Datenschutzaufsicht) for the non-public sector. The BfDI, by contrast, is competent only for federal public bodies and certain providers of telecommunications services (§ 9(1) BDSG). In Austria, the notification goes to the Austrian Data Protection Authority (Datenschutzbehörde).
• Data protection officer: in addition to Art. 37(1)(b) and (c) GDPR, Germany requires a data protection officer where, as a rule, at least 20 persons are constantly engaged in automated processing (§ 38(1) BDSG). Austria has no such numerical threshold; the designation obligation follows directly from Art. 37 GDPR, and § 5 DSG additionally governs confidentiality and freedom from instructions.
• Data secrecy (Austria): under § 6 DSG, Controllers, Data Processors and their employees are subject to a duty of confidentiality — for support and operations teams with access to data of Austrian customers this is a documentation point in its own right.
• Reprimand instead of a fine (Austria only): § 11 DSG provides for the proportionate application of Art. 83 GDPR, in particular a reprimand instead of a fine for first-time infringements.
• National sanctions alongside Art. 83 GDPR: in Germany, § 43(2) and (3) BDSG penalises certain infringements as an administrative offence with a fine of up to EUR 50,000. In Austria, § 62(1) DSG provides for administrative penalties of up to EUR 50,000, insofar as the act is not already covered by Art. 83 GDPR.
• Employee data in HR modules: Germany has a dedicated provision on employee data protection in § 26 BDSG. Austria has no corresponding section in the DSG; the relevant provisions are Art. 6 and Art. 88 GDPR, supplemented by § 12(4) no. 2 DSG (image recording for the purpose of monitoring employees is not permitted) and § 96(1) no. 3 of the Austrian Labour Constitution Act (ArbVG) (monitoring measures that affect human dignity only with a works agreement).
• Video data (Austria only): for image recordings, §§ 12 and 13 DSG apply as a special regime — with a labelling obligation (§ 13(5) DSG) and the requirement that retention lasting longer than 72 hours must be proportionate and must be logged and justified separately (§ 13(3) DSG). Relevant for any software that stores video recordings.
• BSI C5: a German audit catalogue — voluntary in both countries and required by law in neither (cf. Art. 42(3) and (4) GDPR).

NIS2: a separate regime alongside the GDPR

Your role as a Data Processor says nothing about whether you fall within NIS2 — the classification follows from the allocation to a sector type and — outside the entity types covered irrespective of size — from size criteria, not from data protection law.

Germany (BSIG 2025). Particularly important entities are operators of critical installations, qualified trust service providers, top-level domain name registries and DNS service providers as well as certain providers of telecommunications services — these irrespective of size — and, in addition, large undertakings of a type specified in Annex 1, that is with at least 250 employees or an annual turnover of more than EUR 50 million and, in addition, an annual balance sheet total of more than EUR 43 million (§ 28(1) and (2) of the German BSI Act (BSIG)). Important entities are trust service providers, certain smaller providers of telecommunications services as well as entities of a type specified in Annex 1 or Annex 2 with at least 50 employees or an annual turnover and an annual balance sheet total each exceeding EUR 10 million — in each case insofar as they are not already particularly important entities. Annex 1 covers, among other things, digital infrastructure including the management of ICT services (managed services); Annex 2 names, among other things, providers of digital services. Whether your offering is to be allocated to one of these types must be assessed case by case.

Austria (NISG 2026). The Austrian Network and Information Systems Security Act 2026 (NISG 2026, BGBl. I Nr. 94/2025) applies from 1 October 2026; the obligations set out there do not yet apply as at the date of this article. It distinguishes essential and important entities (§ 24 NISG 2026) and defines large undertakings as having at least 250 employees or an annual turnover of more than EUR 50 million with an annual balance sheet total exceeding EUR 43 million, and medium-sized undertakings as having at least 50 employees or an annual turnover of more than EUR 10 million with an annual balance sheet total exceeding EUR 10 million (§ 25(2) and (3) NISG 2026). The competent body there is the Cybersecurity Authority (Cybersicherheitsbehörde, Austria), in Germany the Federal Office for Information Security (BSI).

Why this matters for the DPA: if one of your customers falls within NIS2, they are subject to supply chain security requirements as part of their risk management measures — in Germany under § 30(2) BSIG, in Austria under § 32(4) NISG 2026 from the date it becomes applicable on 1 October 2026. They will pass these on to you — regardless of whether you are covered yourself.