What is the difference between a controller and a processor?

The controller is the party that determines the purposes and means of processing personal data. That is your organisation when you process customer and employee data. The processor is the party that processes personal data on behalf of the controller, following instructions. That is typically your SaaS vendors: Microsoft, Google, your accounting system, your CRM. EDPB Guidelines 07/2020 explains the distinction in detail. The basic rule is straightforward: if a vendor stores or processes personal data on your behalf but does not determine the purpose itself, they are a processor, and a data processing agreement under Article 28 is required.

Do we need a data processing agreement with Microsoft and Google?

Yes. Both Microsoft 365 and Google Workspace process large volumes of personal data on your behalf: email, documents, calendars, contacts. Both have a standard data processing agreement (Microsoft calls it the Data Protection Addendum; Google has the Cloud Data Processing Addendum) available in the admin console. For Microsoft, it is often already accepted as part of the volume licensing agreement. For Google, it usually has to be activated manually in the admin settings. Most organisations have the agreement in place without knowing it, but you should verify that it has actually been accepted and keep a copy in your processor register.

What happens if we don't have a data processing agreement?

Missing a data processing agreement is itself a violation of GDPR Article 28, regardless of whether anything has gone wrong with the data. It is also one of the first things Datatilsynet requests during an inspection, because it is easy to verify. In practice, a first-time breach at an SMB is more likely to result in an order to remedy the situation than an immediate fine, but a missing agreement with a key vendor counts against you in an overall assessment if a case is opened. Datatilsynet issued fines in the range of 150,000 to 250,000 kr in 2024 to organisations with shortcomings in vendor and data management, including the University of Agder (150,000 kr for inadequate data security in Microsoft Teams). The agreement is free to put in place, so the risk is easy to close.

Do we need to approve the sub-processors our vendor uses?

Yes. GDPR Article 28(2) requires the processor to have your permission to use sub-processors. The permission can be specific (you approve each one) or general (you agree that the vendor may use sub-processors, but must be notified of changes and may object). Most SaaS vendors publish a list of their sub-processors online, typically cloud providers such as AWS, Azure, or Google Cloud. You do not need a direct agreement with the sub-processor, but you should have reviewed the list, accepted it, and documented that in your register.

Is the vendor's standard agreement sufficient, or do we need our own template?

For most established SaaS vendors, their standard agreement is sufficient. Large vendors have lawyers who have drafted agreements covering Article 28(3), and it is not practical to negotiate custom text with Microsoft. Consider using your own template in two situations: when you are the controller and are engaging a small vendor that has no agreement of its own, and when you are yourself a processor for your customers. Datatilsynet provides free guidance and a template on its website covering the minimum requirements. For most SMBs, the right approach is to accept the standard agreement from large vendors and use Datatilsynet's template with smaller ones.

How do we handle data processing agreements for US SaaS services after Schrems II?

The data processing agreement itself (Article 28) covers only half the picture. For US vendors, you additionally need a valid transfer basis under GDPR Chapter 5, because data is processed outside the EEA. Following the Schrems II ruling in 2020 and the new EU–US Data Privacy Framework from 2023, the basis for certified US companies is in place, but the framework remains under legal pressure and could fall as its predecessors did. In the agreement or an addendum, document which basis the transfer rests on: the Data Privacy Framework, Standard Contractual Clauses (SCCs), or supplementary measures such as encryption where you hold the keys. If you do not want to transfer data abroad at all, an EU-hosted or self-hosted solution is the alternative.

Who in our organisation should sign the data processing agreement?

The data processing agreement is entered into between two organisations, not two individuals, so it is signed by someone with authority to bind the company – typically the managing director. For large vendors where the agreement is accepted in the admin console, it is the administrator who clicks approve, and it should be clear internally that they are authorised to do so. What matters is not the job title, but that someone is responsible for ensuring the agreements exist, knows where they are kept, and can respond if Datatilsynet or a customer asks. In a company with 5 to 25 employees, this is typically the managing director or the person handling IT on a part-time basis.

Do the rules also apply if we are ourselves a data processor for others?

Yes, and then the perspective reverses. If you provide a service in which you process personal data on behalf of your customers, you are the processor and your customers are the controllers. You must then be able to offer a data processing agreement to your customers, keep track of your own sub-processors, and fulfil the obligations in Article 28(3) towards your customers: process only on instructions, have security measures in place, assist with access requests and breaches, and delete or return data at contract end. Many SMBs are both at the same time – controller for their own employee data, and processor for their customers' data.

Published: 28 May 2026 · Roy Morken, Datafolka

Data Processing Agreements under the Personal Data Act: a guide for Norwegian SMBs

Two people signing an agreement at a desk with documents and a laptop – illustration for data processing agreements — Photo: 2H Media / Unsplash

Every time you adopt a new cloud service that stores customer or employee data, GDPR Article 28 requires you to have a data processing agreement in place before the vendor begins processing your data. This applies to Microsoft 365, your accounting system, your CRM, your newsletter tool, and the AI assistant you just connected. The agreement is free to put in place, yet it remains one of the first documents Datatilsynet requests when opening a case, and it is missing more often than most SMBs realise.

Most Norwegian businesses have an unclear relationship with data processing agreements. They know GDPR exists, they have a privacy policy they have never read closely, and they assume the vendor "handles it automatically". Sometimes that is true – large vendors have the agreement ready in the admin console – but it often must be actively accepted, and for smaller vendors there is no automatic process at all. This guide covers what a data processing agreement actually is, what it must contain, when you need one, how to handle sub-processors and US services, and where to find a free template.

Everything in this article is based on GDPR Article 28, Datatilsynet's guidance on data processing agreements, and EDPB Guidelines 07/2020 on controllers and processors. No anonymised client cases, no "we have seen" anecdotes. Just legal text and public guidance translated into practical language for Norwegian SMBs.

What a data processing agreement is (and what it is not)

A data processing agreement is a legally binding contract between a controller and a processor that regulates how the processor may process personal data on behalf of the controller. The requirement is set out in GDPR Article 28(3), and the content is not optional: the regulation lists eight things the agreement must contain as a minimum.

To understand the agreement, you need to know three roles:

Controller. The party that determines the purposes and means of processing personal data. That is you as a business, for your customer and employee data.
Processor. The party that processes personal data on behalf of the controller, following instructions. That is your SaaS vendors.
Sub-processor. The processor's own vendors, typically cloud providers such as AWS, Azure, or Google Cloud, who process data further down the chain.

EDPB Guidelines 07/2020 spends considerable space on exactly this distinction, because it determines who bears which obligations. The basic rule is clear: if a vendor stores or processes personal data on your behalf but does not determine the purpose itself, they are a processor, and an agreement under Article 28 is required.

A data processing agreement is not the same as a privacy notice (which is directed at data subjects), not the same as an ordinary purchase or licence agreement (which governs price and delivery), and not a one-time document you can file away. It must be updated when the vendor changes sub-processors or when you change what data is being processed.

The eight mandatory clauses of Article 28(3)

GDPR Article 28(3) lists what the agreement must cover as a minimum. These are the core of any data processing agreement, and the checklist you use when evaluating a vendor's template.

Clause (art. 28(3))	What it means in practice
a) Documented instruction	The processor may only process data pursuant to your documented instructions, not for its own purposes.
b) Confidentiality obligation	Personnel at the vendor who access the data must be bound by a confidentiality obligation.
c) Security measures (art. 32)	Appropriate technical and organisational measures: encryption, access controls, resilience.
d) Sub-processors	Conditions for using sub-processors, requiring your approval and imposing the same obligations further down the chain.
e) Assistance with rights	The vendor must help you respond to access requests, rectification, erasure, and data portability.
f) Assistance with breaches and DPIAs	Help with security, breach notification, and data protection impact assessments (art. 32–36).
g) Deletion or return	At contract end, data must be deleted or returned at your choice.
h) Audit right	The vendor must provide information and allow audits to demonstrate compliance.

In practice, clauses d) and h) cause the most friction. Smaller vendors often have agreements covering a) through c) but are vague about sub-processors and reluctant to grant full audit rights. Large vendors cover all eight but replace physical audits with third-party certifications (ISO 27001, SOC 2) as evidence, which is accepted practice.

When reviewing a vendor's template, these are the eight clauses you are looking for. If one is missing, the agreement does not comply with Article 28, regardless of how professional it looks.

When you need a data processing agreement – and with whom

The rule of thumb: every vendor that processes personal data on your behalf needs a data processing agreement. In practice, that is more vendors than most SMBs realise. Here are the typical ones, and what type of agreement they have:

Service	What they process	Agreement
Microsoft 365	Email, documents, contacts, Teams	Data Protection Addendum in the licence agreement
Google Workspace	Email, Drive, calendar	Cloud Data Processing Addendum (activated in admin)
Tripletex / Visma / PowerOffice	Payroll, employee and customer data	Standard data processing agreement from the vendor
Slack / Microsoft Teams	Internal communications, files	Covered by the platform's main agreement
HubSpot / other CRM	Customer and prospect data	Separate DPA, often signed digitally
Zendesk / support tools	Customer enquiries, contact details	Separate DPA
Stripe / payment services	Payment and customer data	Separate DPA (often also an independent controller role)
Notion / file sharing	Documents that may contain personal data	Separate DPA, accepted at account level

An important exception: Stripe and certain payment services often act as an independent controller for parts of the data processing (for example fraud prevention), not merely as a processor. Different rules apply than those under Article 28. Read what the agreement actually says about their role, and do not assume every relationship is a pure processor arrangement.

You do not need a data processing agreement with vendors that do not process personal data on your behalf: a utility provider, a hardware retailer you buy a server from, or a consultant delivering an anonymised analysis. The distinction rests on whether they process personal data on your behalf, not on whether you have a supplier relationship.

Person working with contracts and documents on a laptop – illustration for reviewing data processing agreements — Photo: Austin Distel / Unsplash

Sub-processors: the chain you easily overlook

Almost no SaaS vendor operates everything in-house. They use cloud providers underneath, often AWS, Microsoft Azure, or Google Cloud, and possibly support services for email, analytics, or customer support. These are sub-processors, and GDPR Article 28(2) requires that you have approved their use.

Approval can be given in two ways. Specific approval means you approve each sub-processor individually. General approval means you agree that the vendor may use sub-processors, provided they notify you of changes so you can object. Most modern SaaS agreements use the general model and publish an updated list of sub-processors online.

Practically speaking: find the vendor's sub-processor list (search for the vendor name plus "subprocessors"), review where data is processed, and document that you have accepted the list. If a sub-processor processes data outside the EEA, that ties into the Schrems II question in the next section.

Schrems II and US SaaS services

The data processing agreement under Article 28 governs how data is processed. It says nothing about where data is stored. For vendors that process personal data outside the EEA – typically in the US – an additional layer applies: the transfer basis under GDPR Chapter 5.

The background is the Schrems II ruling of 2020, in which the Court of Justice of the EU invalidated the then-existing EU–US Privacy Shield. The reasoning was that US law (including FISA 702) gives US authorities access to data held by US vendors in a manner incompatible with GDPR. The replacement, the EU–US Data Privacy Framework from 2023, provides a formal basis for transfers to certified US companies, but the framework remains under legal challenge and could fall as its predecessors did.

For the data processing agreement, this means you should be able to document which basis each third-country transfer rests on. In practice, it is one of three:

Data Privacy Framework. The vendor is certified under the framework. Check whether they are on the official DPF list. Simple, but dependent on the framework remaining in force.
Standard Contractual Clauses (SCCs). Standardised contractual terms approved by the European Commission, often attached to the data processing agreement for US vendors.
Supplementary measures. Technical measures such as encryption where you hold the keys, so the vendor cannot read the content even if compelled to disclose it.

For data you do not want to export at all, the alternative is an EU-hosted or self-hosted solution. This is particularly relevant for AI services, where it is tempting to paste customer data into an open ChatGPT or Copilot. Datafolka builds and operates Private AI solutions for SMBs that want the benefits of AI without sending customer data outside the EEA. That is not necessary for everyone, but it is a genuine consideration when you regularly process sensitive data.

Template: where to find a free data processing agreement

You rarely need to draft a data processing agreement from scratch. Good free templates exist, and for large vendors the agreement is already written.

Datatilsynet's guidance and template. Datatilsynet has a dedicated page on data processing agreements with free guidance covering the minimum requirements of Article 28(3). Use it as a starting point when you are the controller and engaging a smaller vendor.
The vendor's standard agreement. For Microsoft, Google, and other established SaaS providers, the agreement is already written, legally reviewed, and covers all eight clauses. Accept it and keep a copy.
Industry templates. Some industry associations and vendor organisations have their own templates tailored to typical assignments.

What matters is not where the template comes from, but that it actually covers the eight clauses, that it is signed by both parties, and that you have it stored somewhere you can find it again. Datafolka is happy to help set up an extended template and a processor register tailored to your setup, available on request as part of an IT advisory review .

What happens if you don't have a data processing agreement

Missing a data processing agreement is a breach of GDPR Article 28 in itself, regardless of whether anything has gone wrong with the data. This does not mean you automatically face a fine, but it does mean you have an obvious shortcoming that will be noted if a case is ever opened.

The data processing agreement is also one of the first documents Datatilsynet requests during an inspection, precisely because it is easy to verify. Datatilsynet's decision register for 2024 shows that organisations with shortcomings in data security and vendor management received fines in the range of 150,000 to 250,000 kr. The University of Agder received 150,000 kr for inadequate data security in Microsoft Teams. Eidskog and Grue municipalities each received 250,000 kr for, respectively, a missing legal basis and a confidentiality breach. For private SMBs, it is more likely that a first-time case ends in an order to remedy the situation than in a direct fine, but a missing agreement counts against you in the overall assessment.

The sober conclusion: the risk of a large fine is real but low for an SMB that remedies shortcomings when asked. The risk of not having a basic document in place on the day a customer or Datatilsynet asks, however, is high if you have never set it up. And since the template is free and the work takes a few days, this is one of the cheapest compliance tasks you can close.

Next steps

Start with the mapping in the six-step list above. Most SMBs spend 3 to 5 days spread over a couple of weeks getting an overview of their processors, obtaining the agreements, and compiling everything in a register. After that, it is ongoing maintenance: no new SaaS vendor is brought into use before the agreement is in place.

If you would like a sparring partner to lead a privacy and vendor review over 1 to 2 days, we can help. It is typically a combination of IT advisory and IT security assessment in which we review your processors, check the agreements against the eight clauses, and set up the register together with you.

Send an email to Roy.Morken@Datafolka.no , and we will arrange a call.

Sources

GDPR Article 28 (processor) and Articles 30 and 32: lovdata.no/personopplysningsloven
Datatilsynet – data processing agreement (guidance): datatilsynet.no/databehandleravtale
EDPB Guidelines 07/2020 on the concepts of controller and processor: edpb.europa.eu/guidelines-07-2020
Datatilsynet decisions 2024 – decision register: datatilsynet.no/avgjorelser-2024
Schrems II (C-311/18) and the EU–US Data Privacy Framework: commission.europa.eu/eu-us-data-transfers

Roy Morken, co-founder of Datafolka. The article is based on GDPR Article 28, Datatilsynet's guidance on data processing agreements, EDPB Guidelines 07/2020, and Datatilsynet's decision register, translated into practical language for Norwegian SMBs. No client data or anonymised cases were used. Last updated 28 May 2026.