Data Processing Agreements: How to Review DPAs and Assess Service Providers

Why data processing on behalf of a controller deserves so much attention

Almost every company today works with external service providers that process personal data. The payroll provider handles salary calculations, the cloud provider hosts the customer database, the ticket system stores support requests with names and email addresses, and the newsletter service manages thousands of contacts. All of this constitutes data processing on behalf of a controller under the DSGVO (GDPR), and for each of these relationships you need a DPA (Data Processing Agreement).

Art. 28 GDPR governs data processing on behalf of a controller and sets clear requirements for the contract between the controller and the processor. In practice, however, many companies have either never reviewed their DPAs, work with outdated templates, or fail to fully cover the obligations under Art. 28. This is risky, because as the controller you bear the accountability obligation under Art. 5(2) GDPR. If your service provider makes a mistake, you are liable to the data subjects.

This article gives you the tools to reliably identify when processing on behalf of a controller applies, review DPAs for completeness, and assess service providers by criticality and security posture.

When does data processing on behalf of a controller apply?

The distinction sounds simple but has its pitfalls. Data processing on behalf of a controller applies when an external service provider processes personal data on your behalf and under your instructions. As the controller, you determine the "whether" and "how" of the processing; the processor merely carries it out.

Typical cases of data processing on behalf of a controller:

• Cloud hosting and SaaS: The provider stores and processes personal data on its servers on your behalf. This applies to CRM systems, project management tools, cloud-based accounting software, and similar services.
• External payroll processing: The service provider processes your employees' salary data according to your specifications.
• Newsletter and email marketing: The delivery service provider stores email addresses and sends messages on your behalf.
• IT support and maintenance: When the IT service provider may have access to personal data during maintenance, data processing on behalf of a controller applies.
• Document destruction: The disposal service provider destroys data carriers containing personal data on your behalf.
• Call centers and customer support: External staff handle inquiries from your customers and access their data in the process.

Data processing on behalf of a controller does not apply in these cases:

• Professional secrecy holders: Tax advisors, lawyers, and auditors process data under their own professional responsibility. This constitutes independent controllership, not a processing relationship.
• Postal and courier services: The mere transport of letters and packages does not constitute data processing on behalf of a controller.
• Banking services: Your bank processes account data under its own responsibility, not on your behalf.
• Purely technical support activities without data access: When a technician repairs the air conditioning in the server room without being able to access data, no processing on behalf of a controller applies.
• Joint controllership: When both parties jointly decide on the purposes and means of processing, Art. 26 GDPR (Joint Controllership) applies instead of Art. 28.

The borderline cases are not always clear-cut in practice. If you are unsure, the following guiding question helps: Do you determine the purpose and essential means of processing, and the service provider merely implements it? Then it is data processing on behalf of a controller. If the service provider pursues its own purposes or independently decides on the "how" of processing, it may be independent controllership or joint controllership.

The 10 mandatory elements of a DPA under Art. 28 GDPR

Art. 28(3) GDPR lists the minimum contents that every DPA must include. A DPA missing any of these points is incomplete and can be challenged during an audit.

1. Subject matter and duration of processing

The DPA must clearly describe what processing is carried out and how long the contractual relationship lasts. "IT services" is not sufficient as a description of the subject matter. Better: "Hosting and operation of the CRM application Sample-CRM, including storage of customer master data, contact histories, and contract data contained therein."

2. Nature and purpose of the processing

In addition to the subject matter, the nature and purpose of the processing must be described: What processing operations take place (collection, storage, modification, retrieval, deletion) and for what purpose?

3. Type of personal data

What data categories are processed? Master data, contact data, contract data, payment data, health data? The more precise the listing, the better you can assess the appropriateness of the protective measures.

4. Categories of data subjects

Whose data is processed? Employees, customers, applicants, website visitors? Specifying the affected groups of persons helps assess the protection requirements.

5. Instruction-bound processing

The processor may only process data based on documented instructions from the controller. The DPA must define how instructions are issued (in writing, by email, via a ticket system) and what happens if the processor considers an instruction unlawful. In that case, the processor must inform the controller without delay.

6. Confidentiality

The processor must ensure that persons authorized to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.

7. Technical and organizational measures (TOMs)

The DPA must contain or reference the processor's TOMs. The TOMs must ensure a level of protection appropriate to the risk in accordance with Art. 32 GDPR. In practice, the TOMs are usually attached as an annex to the DPA.

8. Rules on sub-processors

The DPA must specify whether and under what conditions the processor may engage additional processors (sub-processors). There are two models: general written authorization (the controller is informed about planned changes and can object) or prior written authorization for each individual sub-processor. Most cloud providers operate under the first model.

9. Assistance obligations

The processor must assist the controller in fulfilling its obligations, particularly regarding data subject rights (access, deletion, rectification), data protection impact assessments, and the notification of personal data breaches. The DPA should specifically define the timeframes within which the processor must respond to requests.

10. Deletion and return after contract termination

After the processing ends, the processor must either delete or return all personal data, at the controller's choice. Existing retention obligations of the processor remain unaffected but must be specified in the DPA.

Checklist for reviewing existing DPAs

If you have already concluded DPAs with your service providers, you should review them regularly. The following checklist helps you with a systematic review.

Formal review

• Is there a written or electronic DPA in place (not just terms of service or a privacy policy)?
• Has the DPA been signed by both parties or otherwise validly concluded (electronic contract formation, platform acceptance)?
• Does the DPA reference the current GDPR and not the old German Federal Data Protection Act (BDSG-alt)?
• Is the date of the DPA documented, and does it precede the start of data processing?

Content review

• Are all 10 mandatory elements under Art. 28(3) GDPR covered?
• Is the subject matter of processing specifically described (not just generic "IT services")?
• Are the data categories and affected groups of persons listed correctly and completely?
• Does the DPA include a provision on instruction-bound processing with a clear procedure for issuing instructions?
• Are the TOMs attached as an annex and up to date in terms of content?
• Is the sub-processor provision clear (authorization model, right to object, current list)?
• Are assistance obligations for data subject requests regulated with specific timeframes?
• Is the reporting obligation for data breaches subject to a deadline (recommended: without delay, no later than 24-48 hours)?
• Is there a clear provision for deletion/return of data after contract termination?
• Are the controller's audit rights (audits, inspections, questionnaires) agreed upon?

Review of currency

• Do the data categories stated in the DPA still match the actual processing?
• Has the scope of the service provider's services changed since the DPA was concluded?
• Have new categories of personal data been added that are not mentioned in the DPA?
• Is the sub-processor list up to date? Has the processor engaged new sub-processors?
• Are the TOMs still current or based on an outdated version?
• Has the legal situation changed (e.g., new Standard Contractual Clauses, adequacy decisions)?

Third-country transfer review

• Is data transferred to third countries? If so: which country?
• On what legal basis is the transfer based (adequacy decision, SCCs, BCRs)?
• Are the current Standard Contractual Clauses of the EU Commission (version of June 2021) used? More on this in the context of international data transfers.
• For transfers to the USA, has it been verified whether the service provider is certified under the EU-US Data Privacy Framework?
• Has a Transfer Impact Assessment (TIA) been conducted where required?

Assessing service providers: criticality and security posture

Not every service provider poses the same risk. A newsletter delivery service processing email addresses and first names has a different risk profile than a cloud provider hosting your entire HR management system. A systematic service provider assessment helps you allocate your review resources where the risk is highest.

Criticality assessment

A service provider's criticality depends on several factors, each of which you can rate on a scale (e.g., low, medium, high):

Data sensitivity: Does the service provider process special categories of personal data (health data, religious affiliation, biometric data)? Or is it non-critical business contact data? The more sensitive the data, the more critical the service provider.

Volume of data: How many data records does the service provider process? A tool storing email addresses for 50 internal users is less critical than a CRM with 100,000 customer records.

Number of data subjects: Are only a few employees affected, or potentially all of the company's customers?

Business criticality: How dependent are you on this service provider? Can business operations continue if the service fails? A payroll provider outage has more severe consequences than a visitor management tool going down.

Third-country transfer: Is data transferred to third countries? Transfers to countries without an adequacy decision increase the risk.

Access capabilities: Does the service provider have read-only access to the data, or can it also modify and delete it? The broader the access capabilities, the more critical.

Based on these factors, you can assign each service provider to a criticality level:

• Low: Few non-critical data, small volume, no third-country transfer. Example: office supply vendor with contact person data.
• Medium: Business contact data or employee master data in moderate volume. Example: project management tool with user profiles.
• High: Sensitive data, large volume, business-critical dependency, or third-country transfer. Example: cloud HR system, CRM with extensive customer data, payroll service provider.

Assessing the security posture

In addition to criticality, you must evaluate the service provider's security posture. The more critical the service provider, the more thorough this review should be.

Certifications and attestations:

• ISO 27001: The international standard for information security management. A current certification issued by an accredited body is a strong quality signal.
• SOC 2 Type II: Common among US-based cloud providers. The Type II report confirms that controls were actually effective over a period (typically 12 months).
• BSI C5: The Cloud Computing Compliance Criteria Catalogue from the BSI, particularly relevant for cloud services in the German market.
• TISAX: Relevant if you operate in the automotive industry.

Note: A certification alone does not tell the whole story. Check the scope of the certification. If the service provider holds an ISO 27001 certification for its main location but your data is processed in a non-certified data center, the certification is of little value to you.

Reviewing TOM documentation: Request the service provider's current TOM documentation and review it substantively. Pay attention to the following points:

• Are the TOMs specific enough, or do they consist only of generic statements?
• Do the measures reflect the current state of the art?
• Are the measures appropriate to the risk (stricter measures for sensitive data)?
• Is there a version date? Are the TOMs regularly updated?

Audit results and questionnaires: For highly critical service providers, an on-site audit or at least a detailed questionnaire may be appropriate. Many larger processors also proactively provide audit reports or self-assessments. Use this information and document your assessment.

Sub-processors: approval and oversight

Most cloud providers and larger service providers themselves engage sub-processors. Your CRM provider may host its infrastructure on AWS or Azure, use an external email service for system notifications, or employ a monitoring service to oversee the platform. Each of these sub-processors potentially processes personal data that originally came from you.

Art. 28(2) GDPR provides that the processor shall not engage another processor without prior specific or general written authorization from the controller.

Understanding the authorization model

General written authorization (more common with cloud providers): You grant general authorization in the DPA for the engagement of sub-processors. In return, the processor must inform you of any planned change (addition or replacement of a sub-processor). You then have the opportunity to object. If you object and no agreement is reached, you typically have a special right of termination.

Prior individual authorization (less common, typical for individual contracts): You explicitly approve each individual sub-processor. New sub-processors may only be engaged after your written consent.

Reviewing the sub-processor list

Request the current sub-processor list from your processor. Most larger providers publish this on their website. For each sub-processor, check:

• Name and registered office: In which country is the sub-processor based? Is there a third-country transfer?
• Nature of processing: What exactly does the sub-processor do? Hosting, monitoring, support, data analytics?
• Data access: Does the sub-processor actually have access to personal data, or is it purely infrastructure without data access?
• Contractual safeguards: The DPA must stipulate that the processor imposes the same data protection obligations on the sub-processor as those applicable to you.

Actively tracking changes

Many cloud providers notify you of changes to their sub-processor list by email or via a change page on their website. Establish a process to ensure these notifications do not get lost. For larger providers, it is advisable to manually check the sub-processor page on a quarterly basis in case the notification does not work reliably.

Demanding proof of TOMs

As the controller, you are obligated to engage only processors that provide "sufficient guarantees" that processing is carried out in compliance with the GDPR (Art. 28(1) GDPR). This means: you must actively obtain and evaluate the service provider's TOMs.

Timing of the review

The TOM review should take place at three points:

1. Before contract conclusion: Before signing a DPA, review the service provider's TOMs. Only if the measures are appropriate to the risk may you engage the provider as a processor.
2. Upon changes: When the service provider updates its TOMs (e.g., due to migration to a new data center or change of encryption method), review the new TOMs.
3. Regularly: At least once a year, obtain the current TOM documentation and review whether it is still appropriate.

What you can demand

Depending on the size and type of service provider, you can demand different types of evidence:

• TOM documentation: The minimum. Every processor must be able to document its TOMs.
• Certificates and attestations: ISO 27001, SOC 2, BSI C5, or comparable evidence. Request a copy of the current certificate or attestation and verify the scope.
• Audit reports: Larger service providers often provide summary audit reports or self-assessments.
• Questionnaires: You can send the service provider a data protection questionnaire to complete. This is particularly practical for smaller service providers that cannot present certifications.
• On-site audit: For highly critical service providers, an on-site audit may be appropriate. The right to do so should be anchored in the DPA.

Not every service provider will readily supply all evidence. Large cloud providers such as Microsoft, Google, or AWS provide standardized compliance reports through their Trust Centers but generally do not accept individual questionnaires or on-site audits. This is acceptable as long as the evidence provided (certifications, SOC reports) is sufficiently informative.

For smaller, individual service providers, you have more negotiating power. Here you should insist on reviewing the TOM documentation and, for highly critical processing activities, also negotiate an audit right in the DPA.

Establishing regular reviews

A DPA is not a "fire-and-forget" document. Art. 28(3)(h) GDPR obliges the processor to make available to the controller all information necessary to demonstrate compliance with its obligations and to allow for and contribute to audits and inspections by the controller. As the controller, you are obligated to actually exercise these review options.

Review frequency by criticality

Not every service provider needs to be reviewed with the same intensity. Tier the review effort by criticality level:

Highly critical service providers (sensitive data, large volume, business-critical):

• Annual comprehensive DPA review
• Annual collection and review of current TOMs
• Review of the sub-processor list upon every change and at least semi-annually
• As needed: audit or questionnaire
• Immediate review upon known security incidents involving the service provider

Medium-critical service providers (moderate data volumes, no special categories):

• Annual DPA review for currency
• Annual verification that certifications are still valid
• Review of the sub-processor list upon notification

Low-critical service providers (few non-critical data):

• Biennial review for completeness and currency
• Event-driven review upon changes

Documenting review results

Document every review with the date, subject of review, and result — ideally in a dedicated ISMS tool like ISMS Lite that stores the review trail in an audit-proof manner. This documentation is part of your accountability obligation under Art. 5(2) GDPR. Even a result like "review conducted, no findings" is worth documenting, as it demonstrates that you are fulfilling your oversight obligation.

If you identify deficiencies during the review, document them and set a deadline for the service provider to remediate. Serious deficiencies that indicate an inadequate level of protection may, in extreme cases, require immediate termination of the DPA and cessation of data transfers.

Practical implementation: building a service provider register

Managing all processors, DPAs, and review results quickly becomes unwieldy without a structured approach. A service provider register creates transparency and helps you maintain oversight.

For each service provider, document the following information:

This register is closely linked to your record of processing activities under Art. 30 GDPR. The recipients and processors listed there should be reflected in the service provider register. Consistency between both documents is important. In ISMS Lite, the service provider register, DPAs, and TOM evidence are centrally linked, so you automatically keep track of review deadlines and never miss a document when changes occur.