Auftragsverarbeitungsvertrag (AVV): When Art. 28 DSGVO Requires One and What It Must Contain

An Auftragsverarbeitungsvertrag, almost always shortened to AVV, is the contract Art. 28 DSGVO requires whenever one organisation has another organisation process personal data on its behalf. Cloud hosting, an email service, a payroll bureau, a newsletter tool, a support desk, an external IT firm with remote access: each of those is a service provider handling somebody else's data, and each is the standard case the article was written for.

The AVV has a reputation as paperwork, and the paperwork itself is genuinely routine. Nearly every serious provider publishes a standard AVV that can be accepted electronically. The part that is not routine is the question that comes before the contract, which is whether the other side is a processor at all.

That classification, Verantwortlicher against Auftragsverarbeiter, is where most of the real errors happen. Signing an AVV with a party that is actually an independent controller does not make it one, and skipping an AVV with a party that is a processor leaves a gap that a supervisory authority can see in a single question. This page works through the classification, the trigger, the mandatory contents under Art. 28 Abs. 3 DSGVO, sub-processors, and how the whole structure looks for a small business running ordinary software.

Information last verified on 20 July 2026. This page provides general legal information and does not constitute legal advice in an individual case.

Verantwortlicher or Auftragsverarbeiter: the question that decides everything

The DSGVO allocates duties by role. A Verantwortlicher, the controller, is the body that decides the purposes and the means of a processing operation. An Auftragsverarbeiter, the processor, processes personal data on behalf of that controller and, on the substance, does what it is told.

The test is not who owns the servers, who is bigger, or who wrote the contract. It is who decides why the data is processed. A hosting company that stores a customer database has no say in why the database exists, so it processes on behalf. A bank that receives a transfer instruction is not processing on behalf of its customer at all, because it has its own legal duties governing what it does with the payment data.

That produces three configurations rather than two:

• Controller and processor. The service provider acts on instructions. An AVV under Art. 28 DSGVO is the correct instrument.
• Two independent controllers. Each side decides its own purposes and answers for its own processing. There is a transfer of data between them, and a legal basis is needed for it, but an AVV would misdescribe the relationship.
• Joint controllers. Two bodies jointly determine purposes and means. Art. 26 DSGVO then requires an arrangement between them setting out who does what, which is a different document from an AVV.

Professional advisers are the classic argument. Tax advisers, lawyers and auditors are widely treated as independent controllers, because they owe their own professional and statutory duties and cannot be instructed on the substance of their work. The classification depends on the actual facts of the engagement rather than on the label the parties use, which is exactly why swapping in the wrong template does not fix anything.

One further rule closes the loop. Under Art. 28 DSGVO a processor that steps outside its instructions and decides for itself the purposes and means of a processing operation is treated as a controller in respect of that operation, with the full set of controller duties attached. Analytics or model training carried out by a provider on customer data for its own ends is the usual live example.

When an AVV is actually required

The trigger is narrow and mechanical: personal data, processed by an external party, on behalf of and on the instructions of the organisation whose data it is. Where all three are present, Art. 28 DSGVO requires a contract or another legal act binding the processor to the controller.

A few situations look like triggers and are not. Own employees are not processors, because they act within the controller and not on their own account. A partner that receives data and then decides for itself what to do with it is a separate controller. Where no personal data is involved at all, for example genuinely aggregated statistics that cannot be related to a person, Art. 28 DSGVO has nothing to attach to.

One situation looks like a non trigger and generally is one. An IT contractor with remote access to systems containing personal data is normally treated as a processor even where looking at the data is incidental to the job, because the possibility of access is the point. A maintenance arrangement with standing access is therefore the common case where a business discovers it needed an AVV it never signed.

The form requirement is light. Art. 28 DSGVO requires the contract to be in writing, and expressly includes electronic form, so accepting a provider standard AVV through an account portal satisfies it. What matters afterwards is that the accepted version can be produced when a supervisory authority asks for it.

What Art. 28 Abs. 3 DSGVO requires the contract to contain

Art. 28 Abs. 3 DSGVO works in two stages. First it requires the contract to describe the processing itself, then it requires the contract to impose a specific list of duties on the processor.

The descriptive frame consists of the subject matter of the processing, its duration, its nature and purpose, the type of personal data involved, the categories of data subjects concerned, and the obligations and rights of the controller. A contract that says only that the provider will process data in accordance with the DSGVO has not stated any of that, and it is the most common defect in short home made agreements.

The duties the contract has to impose on the processor are these:

Art. 28 Abs. 3 DSGVO also requires the processor to inform the controller immediately if, in its opinion, an instruction infringes the DSGVO or other data protection provisions. That clause is easy to overlook and is one of the items a supervisory authority can check for in seconds.

Two of these items carry more practical weight than the rest. The deletion or return clause is where a business finds out what happens to five years of customer records when it switches provider, and the choice under it belongs to the controller. The audit clause is what makes the rest enforceable at all, since a duty nobody can inspect is a duty nobody can test.

Sub-processors

Almost no modern provider works alone. A support desk tool sits on a cloud platform, sends transactional email through a delivery service and runs its error monitoring somewhere else again. Each of those is a sub-processor, and Art. 28 DSGVO handles them in two steps.

The first step is authorisation. A processor may not engage another processor without the prior authorisation of the controller. That authorisation can be specific, meaning named provider by named provider, or general, meaning a standing permission. Where it is general, the processor has to inform the controller of intended additions or replacements so that the controller has the opportunity to object.

The second step is the flow down. The processor has to impose on the sub-processor the same data protection obligations as those in its own contract with the controller, and it remains fully liable to the controller for the performance of those obligations. That structure is why a chain of five providers does not dilute the controller position: the counterpart stays the direct processor, whatever happens further down.

In practice the general authorisation model is what nearly every SaaS provider uses. The provider maintains a published sub-processor list and a notification channel for changes, and the AVV points at both. The list is worth reading once, because it is usually where a business first learns which countries its data actually sits in.

Instructions, security and transfers

The instruction concept is what separates an AVV from an ordinary service agreement. Everything the processor does with the data has to trace back to something the controller asked for, and that includes any transfer of the data to a third country outside the EU and the EEA.

The AVV is not, however, the whole story on transfers. The separate transfer regime in the DSGVO applies on top, and a valid AVV does not by itself make a transfer to a third country lawful. Those are two different questions that get merged in vendor marketing material, and the transfer question needs its own answer.

Security enters through Art. 32 DSGVO, the technical and organisational measures. The AVV binds the processor to take them, and in practice the measures are set out in an annex describing encryption, access control, logging, backup and similar. An annex that lists nothing concrete is a signal worth noticing.

A small German business, in practice

Take a fictional twelve person design agency established in Munich. It uses a cloud office suite for email and files, an accounting tool, a newsletter platform, a support inbox, a payroll service, and an external IT contractor with remote access. It also has a Steuerberater and a business bank account.

The first six are the standard processor cases. Each of them handles personal data belonging to the agency, whether client contacts, newsletter recipients, support correspondence or employee payroll data, and none of them decides why that data exists. The AVV in each case is normally the provider standard document, accepted electronically, plus its sub-processor list and its security annex.

The bank is not a processor. It processes payment data under its own regulatory duties and decides for itself how to meet them, so it is an independent controller. The Steuerberater is very widely treated the same way, for the professional duty reasons described above, though the precise classification turns on the facts of the engagement rather than on a general rule.

The remaining work is unglamorous and is where the value sits. It amounts to keeping a list of which tool holds which category of data, keeping the accepted AVV where it can be produced, and noticing when a provider changes its sub-processors. This is a description of how the rules apply to a typical structure, not an assessment of any particular business, and nothing here evaluates whether a given company is compliant.

One point of realism about scale. An agency of twelve people accepts the contract its provider offers and has no negotiating position on the wording, and that is normal rather than a defect. What Art. 28 DSGVO does not let the contract do is move accountability. The controller still answers for having chosen a provider that offers sufficient guarantees, and the contract is evidence of that choice rather than a substitute for it.

Who supervises this, and what a breach costs

Supervision in Germany is split by the type of body, not shared. Under § 40 Abs. 1 BDSG the authorities designated under the law of each Land supervise non public bodies, which means virtually the entire private economy. Under § 9 Abs. 1 BDSG the BfDI supervises federal public bodies and companies processing data for the commercial provision of telecommunications services, alongside its role for postal services.

So for an ordinary German company the competent authority is the Landesdatenschutzbehoerde of the Land where it is established. For the Munich agency above that is the Bavarian authority for the private sector, not the BfDI, and a complaint or an inquiry about an AVV belongs there.

The fine tiers are the part most often stated wrongly. A breach of the controller and processor obligations, which is where Art. 28 DSGVO sits, falls under Art. 83 Abs. 4 DSGVO: up to ten million Euro, or up to two percent of total worldwide annual turnover of the preceding financial year, whichever is higher. The higher tier in Art. 83 Abs. 5 DSGVO, up to twenty million Euro or four percent, covers breaches of the basic principles and of the data subject rights, including the right of access. A missing AVV and an ignored access request are not in the same bracket.

§ 43 BDSG is not the relevant provision here at all, although it turns up in circulation as if it were. It penalises only the mishandling of an Auskunftsverlangen under § 30 Abs. 1 BDSG and the failure to inform a consumer under § 30 Abs. 2 BDSG, both concerning credit reference agencies and consumer credit, with a ceiling of fifty thousand Euro. § 43 Abs. 3 BDSG also provides that no fines are imposed on authorities and other public bodies.

Processors are not spectators in this. The DSGVO imposes obligations on them directly and a supervisory authority can act against a processor in its own right, which is why provider standard AVV documents have become as thorough as they are.

Processing for police and criminal justice purposes

One parallel regime is worth naming so it is not mistaken for the general rule. Where processing falls under the German transposition of Directive (EU) 2016/680, meaning law enforcement and criminal justice purposes, the relevant provision is § 62 BDSG rather than Art. 28 DSGVO.

The structure is closely comparable. § 62 Abs. 3 BDSG requires prior written approval before a processor brings in a further processor, § 62 Abs. 4 BDSG flows the same obligations down the chain and keeps the engaging processor liable, and § 62 Abs. 5 BDSG requires a contract stating the subject matter, duration, nature and purpose of the processing, the type of personal data, the categories of data subjects and the rights and duties of the controller. A private business will not normally be inside that regime, but the wording is close enough that documents drafted for one context are sometimes recycled into the other.

For how an individual can ask what any of these systems hold, see the right of access. Employee monitoring data, which sits in several of the tools described above, is covered at workplace surveillance. The rest of the German data protection material is collected at the data privacy overview, and the wider guide to German law is at Germany.