As soon as a website accepts enquiries, other parties are working alongside you: the server sits with a hosting provider, the contact form drops messages into an inbox, visits are counted, a backup runs overnight, and someone may book an appointment through a calendar. Each of these building blocks processes personal data, and it does so not for itself but for the business the website belongs to. That is exactly what processing on behalf of a controller means. The General Data Protection Regulation requires a contract with a fixed set of minimum contents for it, plus a record describing what is processed in the business at all. Both sound like corporate bureaucracy, and neither has to be: for a business with five employees the documentation fits on two pages once it has been set up properly. This guide shows when a contract is needed, what belongs in it, where the typical gaps sit and how to keep the effort permanently small. It does not replace legal advice in an individual case.
Anyone processing on your behalf belongs in a contract
The General Data Protection Regulation distinguishes two roles cleanly. The controller is the party that decides on the purposes and means of processing, in other words the party that answers the question: why is this data being collected in the first place? Under Article 4(8) a processor is a body that processes personal data on behalf of the controller (General Data Protection Regulation, Article 4). For a trades business, a practice or a restaurant that means: the business decides that enquiries will be received through a form. The vendor operating that form technically does not share in that decision, it carries it out. Decisions on technical and organisational questions may well rest with the vendor without the role tipping over (German Data Protection Conference, Short Paper No. 13). Choosing an encryption algorithm or running a data centre does not turn a vendor into a controller.
The practical advantage of this construction is often overlooked. Under Article 29 a processor acts only on instructions and is specifically not a third party within the meaning of Article 4(10); an internal relationship exists between controller and processor, and the processing is attributed to the controller (German Data Protection Conference, Short Paper No. 13). This is why passing data to the vendor generally needs no separate legal basis under Articles 6 to 10; the basis on which the business relies for the processing itself is sufficient (German Data Protection Conference, Short Paper No. 13). The contract is therefore not bureaucratic decoration but the very thing that carries this simplification. Without it, a data transfer without a basis is left standing in the room.
What the contract does not do: it does not shift responsibility. Under Article 24(1) and Article 28(1) responsibility for the data protection compliance of the entire processing remains with the business, and it is not diminished by engaging vendors, regardless of the number and complexity of the processing relationships (European Data Protection Board, Opinion 22/2024). Added to this is the accountability duty in Article 5(2): the business must not only ensure compliance but be able to demonstrate it. The contract and the record are precisely that demonstration. Whoever keeps both properly has an answer when a supervisory authority asks; whoever does not ends up searching old invoices and mailboxes for evidence while the clock runs.
This article does not replace legal advice
When Article 28 applies and when it does not
The decisive question is not how close the cooperation is but who determines the purpose. A vendor that processes the business's data solely according to its specifications is a processor. A vendor that needs the data in order to fulfil its own statutory or professional task is a controller in its own right, and then no Article 28 contract is concluded; instead the transfer needs its own legal basis. The German Data Protection Conference has published example catalogues for both sides that work well as a starting point (German Data Protection Conference, Short Paper No. 13). The most important practical case in the second group is the tax adviser: professionals bound by professional secrecy such as tax advisers, lawyers, external company doctors and auditors are explicitly not classified as processors (German Data Protection Conference, Short Paper No. 13). Sending a data processing agreement to the tax office documents a role that does not exist.
| Party involved | Role | What follows from it |
|---|---|---|
| Hosting and delivery of the website | processor | Article 28 contract, entry in the record |
| Inbox for form messages | processor | Article 28 contract, agree an erasure concept |
| Audience measurement on your instructions | processor | Article 28 contract, plus clarify the consent question |
| Backup and archiving | processor | Article 28 contract, record retention periods |
| Remote maintenance with possible data access | processor | Article 28 contract, log the access |
| Tax adviser, lawyer, company doctor | controller in its own right | no Article 28 contract, transfer needs a basis |
| Bank for payment transactions | controller in its own right | no Article 28 contract |
| Postal service for letter transport | controller in its own right | no Article 28 contract |
Two arrangements regularly cause uncertainty. The first is remote maintenance. Where a vendor analyses faults or provides support inside the business's systems and access to personal data cannot be ruled out, this constitutes a partial activity of processing on behalf of the controller, because reading, querying and using data already amount to processing under Article 4(2) (German Data Protection Conference, Short Paper No. 13). The position differs for purely technical maintenance of the infrastructure, for example work on power supply, cooling or heating: such work does not lead to classification as a processor (German Data Protection Conference, Short Paper No. 13). The distinction matters in practice, because many businesses put the electrician in the server room on the list yet forget the external IT support with remote access.
The second arrangement is the vendor that derives its own purposes from the data provided, for example statistics used to improve its own product, or advertising profiles. Article 28(10) settles this clearly: a party that determines the purposes and means of processing itself is considered a controller in respect of that processing, with all the consequences down to its own duty to fulfil data subject rights (General Data Protection Regulation, Article 28). For the business this means the vendor's terms deserve a second read. A clause providing for use of the data for its own analytics or product improvement leaves the scope of processing on behalf of a controller. Alongside this sits joint controllership under Article 26, where two parties jointly determine purposes and means; that too is not processing on behalf of a controller and requires an arrangement of its own (German Data Protection Conference, Short Paper No. 13).
The contract follows the role, not the form
What a data processing agreement must contain
Article 28(3) is unusually concrete. The contract first sets the frame: the subject matter and duration of the processing, its nature and purpose, the type of personal data, the categories of data subjects and the obligations and rights of the controller. This is followed by a catalogue of eight (General Data Protection Regulation, Article 28) points set out in points (a) to (h). Those eight points are the real test. Anyone assessing a contract that has been put in front of them can tick them off in order; if one is missing, the contract has a gap, no matter how extensive it is otherwise. Infringements of Article 28 also fall within the fine range of up to 10 million euros or up to 2 percent of the total worldwide annual turnover of the preceding financial year (General Data Protection Regulation, Article 83).
Documented instructions
The vendor processes the data only on documented instructions, including for any transfer to a third country, unless required to do otherwise by law.
Confidentiality
The people involved are committed to confidentiality or are under an appropriate statutory obligation of secrecy.
Security under Article 32
The technical and organisational measures are described concretely, not as a statement of intent but as an annex to the contract.
Sub-processors
The use of further processors is regulated, including authorisation, notice of changes and the option to object.
Duties to assist
The vendor assists with access, rectification and erasure as well as with security, breach notification and impact assessments.
Erasure and evidence
After the service ends the data is deleted or returned, and the vendor supplies evidence and makes reviews possible.
As to form, Article 28(9) requires writing, expressly including an electronic format (General Data Protection Regulation, Article 28). A printed and signed version is therefore not mandatory; a signed document, or one accepted inside a customer account, is sufficient as long as it stays retrievable and its version is identifiable. For the contract content, individual clauses may be agreed, or standard contractual clauses adopted by the European Commission or the competent supervisory authority may be used (German Data Protection Conference, Short Paper No. 13). The Commission published such clauses for the relationship between controller and processor in Implementing Decision (EU) 2021/915 of 4 June 2021 (European Commission, Implementing Decision (EU) 2021/915). Using them removes the argument about the base text and lets you concentrate on the annexes, where the actual work sits.
- Annex 1 describes the subject matter: which service is provided, which data types arise, which groups of people are affected and how long the processing lasts.
- Annex 2 describes the technical and organisational measures under Article 32, at minimum pseudonymisation and encryption, confidentiality, integrity, availability and resilience of the systems, plus a procedure for regular review.
- Annex 3 lists the authorised sub-processors with name, service and place of processing, so the chain stays traceable at any time.
- The contract names a point of contact on both sides and a reporting route for security incidents, so the deadline in Article 33 can be met in practice.
- It settles what happens when the contract ends: erasure or return, within what period, in which format and with what evidence.
- It records how evidence is supplied, for example through audit reports, certificates or a self-assessment, and when an on-site review comes into play.
Sub-processors: the chain behind your vendor
Hardly any vendor delivers its service entirely on its own. The provider of the form inbox uses a data centre, the data centre uses a network operator, the appointment booking provider perhaps a delivery service for confirmation emails. Article 28(2) requires prior specific or general written authorisation from the controller for each of these further processors; with a general authorisation the vendor must give notice of intended changes in advance, and the controller may object (General Data Protection Regulation, Article 28). If no agreement is reached, the controller must prohibit the sub-processing by instruction or end the processing relationship (German Data Protection Conference, Short Paper No. 13). Under Article 28(4) the contract with the sub-processor must contain the same obligations, and the first vendor remains liable to the controller for its conduct.
The controller may use only processors providing sufficient guarantees that they apply appropriate technical and organisational measures for an adequate level of data protection.
How deeply a small business has to examine this chain was long an open question. The European Data Protection Board provided several clarifications in its Opinion 22/2024, summarised by the Bavarian Data Protection Authority in its 2024 activity report. First, throughout the entire period of processing the controller must know the identity of all processors and sub-processors, if only because it must be able to name the specific recipients when responding to an access request (Bavarian Data Protection Authority, activity report 2024). The Court of Justice of the European Union has held that data subjects are to be told the specific recipients and that the controller cannot fall back on categories where the recipients are known (Court of Justice of the European Union, Case C-154/21). Second, the scope and level of detail of the controller's own checks depend on the risk of the processing: the higher the risk, the more the controller has to examine itself (Bavarian Data Protection Authority, activity report 2024).
Third, and this is the most useful statement in practice: the controller has the right at any time to demand that the vendor produce all sub-processing contracts it has concluded (Bavarian Data Protection Authority, activity report 2024). It is not obliged to do this systematically for every contract; as soon as doubts arise about a sub-processor's guarantees, however, it becomes necessary. For a website with a contact form and audience measurement the risk is manageable, and a documented list of sub-processors including the place of processing is generally sufficient. With health data, applicant data or employee data the bar is higher. Anyone planning a booking function that collects sensitive details should limit the scope of processing beforehand rather than examine the chain afterwards. The article on contact forms and handling enquiries describes how to reduce form fields to what is genuinely needed.
- Is there a current list of all sub-processors with name, service and place of processing?
- Is it settled how changes are notified and within what period an objection is possible?
- Do the contracts with sub-processors contain the same obligations as the main contract?
- Is there a named reporting route through which the vendor reports an incident without undue delay?
- Is it documented which evidence the vendor supplies, for example audit reports or certificates?
- Is it recorded in which country the data sits and whether a copy is created outside the EU?
- Does the contract state what happens at the end: erasure or return, with a deadline and evidence?
One case from supervisory practice shows why the chain is more than a formality. A successful attack on a single Bavarian IT service provider led to 40 (Bavarian Data Protection Authority, activity report 2022) follow-up notifications from controllers in the non-public sector in Bavaria alone that had engaged this provider as a processor. In total the authority received 2,991 (Bavarian Data Protection Authority, activity report 2022) notifications under Article 33 that year. Each of those 40 businesses had to answer within a short time which data was affected, which groups of people sit behind it and how long the data had been held there. Those that had kept a contract and a record could answer from their own files. The link to the attack surface of your own website is direct: fewer embedded services mean fewer places where someone else's incident becomes your own.
Third country transfers and where processing happens
As soon as a vendor or one of its sub-processors processes data outside the European Union, Chapter V of the General Data Protection Regulation comes into play. Where an adequacy decision of the European Commission exists for the destination country, the business does not have to examine the level of protection at the recipient again, because that assessment has already been made by the decision (Bavarian Data Protection Authority, activity report 2024). For transfers to certified organisations in the United States such a decision has applied since 10 July 2023 under the transatlantic data protection framework (European Commission, adequacy decision of 10 July 2023). Where no adequacy decision exists, standard data protection clauses are usually used in practice (European Commission, Implementing Decision (EU) 2021/914), and an assessment of the legal situation in the recipient country is required in addition, the so-called transfer impact assessment.
For a business with five employees that assessment is a considerable effort, and it cannot be delegated entirely. Where it is carried out by a processor established in the Union that in turn transfers to a sub-processor in a third country, the controller may not rely on it blindly; depending on the risk it may be obliged to check at least the plausibility itself (Bavarian Data Protection Authority, activity report 2024). That this field is gaining weight is visible in the authority's intake figures: complaints in the area of international data traffic rose by 170 percent (Bavarian Data Protection Authority, activity report 2022) in 2022, while the total number of complaints fell by 16 percent in the same year.
The simplest route runs through the place of processing
The Article 30 record on two pages
The record of processing activities is the second pillar. For each processing activity, Article 30(1) requires the controller to state: the name and contact details of the controller, the purposes of the processing, a description of the categories of data subjects and the categories of personal data, the categories of recipients, where applicable transfers to a third country together with the appropriate safeguards, where possible the envisaged erasure periods, and a general description of the technical and organisational measures (General Data Protection Regulation, Article 30). That is seven columns, no more. Under Article 30(2) processors keep their own, shorter record of the activities they carry out on behalf of controllers (German Data Protection Conference, Short Paper No. 13). Both records must be kept in writing under Article 30(3), including in electronic form, and made available to the supervisory authority on request under Article 30(4) (General Data Protection Regulation, Article 30).
The frequently quoted exemption for small businesses rarely helps in practice. Article 30(5) exempts enterprises with fewer than 250 (General Data Protection Regulation, Article 30) employees, but only where none of the three counter-exceptions applies: the processing must not be likely to result in a risk to the rights and freedoms of data subjects, it must not be other than occasional, and it must not include special categories of data under Article 9(1) or data on criminal convictions under Article 10 (General Data Protection Regulation, Article 30). A website that permanently accepts enquiries does not process only occasionally. The duty therefore remains in practice, and the exemption is no justification for documenting nothing at all. The better approach is to treat the record as a working tool anyway: it answers the question of which data sits in the business and who takes part in handling it, and that question comes up sooner or later on its own.
| Processing activity | Data subjects and data | Recipients | Erasure period |
|---|---|---|---|
| Enquiries through the contact form | prospects: name, email, message | hosting, inbox | 6 months after completion |
| Website server logs | visitors: truncated IP, time, page | hosting | 7 days |
| Audience measurement | visitors: page views, source, device | analysis service | 14 months |
| Consent records | visitors: choice, time, version | hosting | 3 years |
| Quotes and orders | customers: master data, service, amount | tax adviser, bank | statutory periods |
| Applications via the careers page | applicants: CV, contact details | hosting, inbox | 6 months after rejection |
A small business needs nothing beyond this structure. Add a header with the controller's contact details, a column for third country transfers and a short section on the technical and organisational measures, and the result fits on two pages. More important than the length is the upkeep: every new function on the website creates a line or changes an existing one. An application form on the careers page, a newsletter, a booking calendar or a chat window is each a processing activity in its own right. Building the record into the same routine that already maintains website content and technology keeps it current without noticeable extra effort. Setting it up once and then leaving it alone produces a document that, after two years, raises more questions than it answers.
{
"controller": {
"name": "Sample Business Ltd",
"address": "1 Sample Street, 12345 Sampletown",
"contact": "privacy@sample-business.com",
"version": "2026-07-04"
},
"activities": [
{
"no": 1,
"name": "Enquiries through the contact form",
"purpose": "Handling and answering enquiries",
"legal_basis": "Art. 6(1)(b) and (f) GDPR",
"data_subjects": ["prospects", "customers"],
"data_types": ["name", "email address", "message"],
"recipients": ["hosting (processor)", "inbox (processor)"],
"third_country": null,
"erasure_period": "6 months after the case is closed",
"measures": ["transport encryption", "access restriction", "logging"],
"dpa": { "in_place": true, "date": "2026-02-11" }
},
{
"no": 2,
"name": "Website server logs",
"purpose": "Operational security and fault analysis",
"legal_basis": "Art. 6(1)(f) GDPR",
"data_subjects": ["website visitors"],
"data_types": ["truncated IP address", "time", "page requested"],
"recipients": ["hosting (processor)"],
"third_country": null,
"erasure_period": "7 days",
"measures": ["access restriction", "automatic deletion"],
"dpa": { "in_place": true, "date": "2026-02-11" }
}
]
}Checklist: which vendors do you actually have
The hardest part is rarely the contract but the inventory. Hardly any business knows off the top of its head how many parties work on its website, because the services accumulated over years, often set up by different people. A form provider embedded by a former intern, a map service on the contact page, a font service in the stylesheet, a review widget in the footer: each of these elements can trigger processing. The most reliable method is to search several places at once, because no single place is complete. Anyone going through the source code anyway can take the opportunity to check which of these embeds is still needed at all.
- Bank statements and invoices from the last twelve months: recurring amounts to IT vendors, hosting providers, domain registrars or software suppliers.
- The source code of the home page and one subpage: every address pointing to an external domain and every script loaded later.
- The browser network panel: which connections are actually established when the page loads, even without a visible element.
- The mailbox: forwarding rules, distribution lists, automated notifications and systems that receive enquiries.
- The password manager or the list of logins: every account with an external service belongs on the list.
- Domain administration: who manages the domain, who runs name resolution, who issues certificates.
- Backup and archive: where the nightly backup is written and who has access to it.
- Remote access: which external people can look into systems remotely, including occasionally and on request.
- Your own privacy policy: it names processing operations that frequently do not appear on the vendor list.
- The list of templates and building blocks: embedded fonts, maps, videos, reviews or booking windows.
Shadow services are the most common gap
The inventory produces a table with four columns: vendor, service, role and contract status. That table is the bridge between Article 28 and Article 30, because both can be derived from it. Every line with the role of processor needs a contract; every line with processing of its own needs an entry in the record. Once the table exists, it also becomes immediately visible how many parties are involved in a comparatively simple website. In many cases it is five to eight, and few of them are indispensable. The question of which pages a business website actually needs therefore has a data protection dimension: every function added because it is technically possible drags documentation along with it.
Every service you drop saves a contract
The effort of data protection documentation does not grow with the size of the business but with the number of parties involved. A business with five employees and six vendors has more to document than a business with twenty employees and two vendors. The reason lies in the multiplication: each additional service creates a contract with eight mandatory points, a line in the record, a section in the privacy policy, a review of sub-processors, a reporting route for incidents and a follow-up whenever something changes at the provider. Six services therefore add up not to six tasks but to roughly three dozen small duties that nobody keeps fully in mind.
| Task | Chain of six providers | Bundled processing |
|---|---|---|
| Article 28 contracts | six contracts, six sets of annexes | one contract, one set of annexes |
| Sub-processors | six lists, six notification routes | one list, one notification route |
| Incident reporting routes | six contacts and deadlines | one contact |
| Checking the place of processing | six checks, repeated per provider | one check |
| Privacy policy | six sections, six text versions | one coherent section |
| Annual review | six appointments with six response times | one appointment |
This is not a plea for doing without at any price. Some functions contribute so much to the business that the extra contract is money well spent. It is, however, an argument for asking the question at all before another service is embedded: what does it bring, and what does it cost in documentation and review? A related question concerns consent, because many of the services that generate documentation also require the visitor's agreement. How that assessment works is described in the article on consent and cookie banners on your website; this article deals with the contracts and the documentation behind them, that one with the question of what may be loaded at all without agreement. The two belong together but are not the same thing.
A third connection concerns the texts. The privacy policy describes exactly the processing operations listed in the record and names the categories of recipients. Maintaining both from the same source avoids the most common contradiction: a policy that lists services switched off long ago, and one that stays silent about the booking calendar that has been running for months. How to set up the mandatory pages properly is described in the article on the imprint and the privacy policy. And because these texts are meant to be read, the same standard applies as to all other content: website copy written to be understood reaches its readers more readily than a string of legal terms. Article 12 requires a concise, transparent and intelligible form in any case.
One contracting partner instead of a chain
This is exactly where XICflow comes in. Hosting, form handling and analysis come from one source and are processed inside the European Union. For the business that means one data processing agreement instead of a chain of individual arrangements, one list of sub-processors instead of six, one reporting route for security incidents instead of six contacts with different response times. The data flows are documented because they come from the same configuration the website itself is generated from: which form collects which fields, where the message goes and how long it is kept does not sit in a separate spreadsheet but follows from what is actually published. Which building blocks are part of it is shown in the feature overview.
One contract instead of six
Hosting, form handling and analysis sit in one place, so a single data processing agreement with one annex on measures is enough.
Documented data flows
Which data a form collects, where it goes and how long it stays follows from the site configuration and can be carried straight into the record.
Processing in the EU
Processing takes place inside the European Union, so the assessment of the legal situation in a third country is not needed for these building blocks.
This replaces neither your own inventory nor a professional review. A business that also runs an inventory system, a payroll service and a ticketing tool still has contracts to conclude and lines to keep; the website is only one section. The difference is that this section does not turn into a building site of its own. What the path from the first description to the published page looks like is shown in the overview of how the process works. What is included and to what extent is set out in the pricing overview, and the results can be seen in the example sites. Anyone looking for the distinction from other routes will find it in the comparison of approaches.
Two points belong to an honest picture. First, responsibility stays with the business, even with a bundled offering; nobody can take it over, and any promise claiming otherwise deserves careful reading. Second, bundled offerings are not free of sub-processors either, because a data centre, a network operator and a certificate provider sit behind them. The difference is the number of chains a business has to keep track of itself, and whether the list is already available or has to be assembled first. Anyone who wants to know who stands behind the offering will find the details on the about page; for an assessment of your own inventory a short message through the contact page is enough. The basics count too: your own domain with a proper business email mailbox keeps the circle of recipients smaller than a private mailbox that takes customer enquiries on the side.