GDPR Templates for IT Service Providers: DPA + TOM

1. Role: Controller or Processor?

The GDPR distinguishes two key roles that drive the entire compliance chain:

• Controller (Art. 4(7) GDPR): determines the purposes and means of processing. For an IT service provider, this is typically the customer.
• Processor (Art. 4(8) GDPR): processes personal data on behalf of the controller. That is the IT service provider when processing data for the customer, not about the customer.

The boundary matters: A pure software sale without data access (e.g., an on-premise licence the customer operates themselves) is not a processor case. Once the provider gains access to personal data or stores it in its systems, it usually becomes a processor.

2. Typical IT Service Provider Constellations

The following business models almost always require a DPA in practice:

• Web hosting and server hosting — the customer stores databases, web applications, or files on the provider's infrastructure
• Managed Service Provider (MSP) — remote maintenance, patch management, monitoring with access to customer systems including HR data
• Cloud reseller — IT service provider markets Microsoft 365 or AWS, sitting between the hyperscaler and the end customer
• SaaS provider — proprietary platform into which the customer feeds personal data (CRM, project management, HR tools)
• IT consulting with data access — database migration, ERP customization, training with live data access
• Development with customer data — test and staging systems loaded with production customer data

Pure sub-processor chains (cloud reseller → hyperscaler) require a two-tier contractual structure: a DPA between customer and reseller, plus a documented sub-DPA between reseller and hyperscaler.

3. Data Processing Agreement (DPA) under Art. 28

The DPA is the central contractual building block. Art. 28(3) GDPR exhaustively lists the mandatory contents:

• Subject matter and duration of the processing — the concrete IT product (e.g., "web hosting with a dedicated VM") and the term (typically linked to the main contract)
• Nature and purpose — e.g., "provision of e-mail services for business communication"
• Type of personal data — e.g., contact data, contract data, possibly special categories under Art. 9
• Categories of data subjects — employees, customers, suppliers, possibly minors
• Rights and obligations of the controller
• Processor obligations under Art. 28(3) lit. a–h:
  • Processing only on documented instructions
  • Confidentiality commitment of staff
  • Implementation of Art. 32 TOM
  • Sub-processor handling under Art. 28(2)/(4)
  • Assistance with data-subject rights (Art. 12–22)
  • Assistance with controller obligations (Art. 32–36)
  • Data deletion/return after contract end
  • Provision of evidence and tolerance of audits

The DPA must be concluded in writing or electronic form (Art. 28(9)). A purely oral arrangement is invalid.

4. Annexes to the DPA

Three standardized annexes have proven themselves in practice:

• Annex 1 — Description of processing: tabular listing of data types, data-subject categories, purposes, processing locations
• Annex 2 — TOM description: detailed presentation of technical and organizational measures (see Section 5)
• Annex 3 — List of sub-processors: name, address, processing location, task, date of authorization

5. TOM under Art. 32 GDPR

Art. 32 requires appropriate technical and organizational measures that ensure a level of security appropriate to the risk. The Regulation expressly names:

• Pseudonymization and encryption of personal data
• Confidentiality, integrity, availability, and resilience of processing systems
• Restoration of availability in a timely manner after a physical or technical incident
• Regular testing, assessing, and evaluating the effectiveness of the measures

In practice, structuring along the "eight-control system" has prevailed (analogous to the Annex to the former § 9 BDSG, still recognized as best practice by supervisory authorities):

• Admission control (physical access to data centres, server rooms)
• Access control (system authentication, MFA, password policy)
• Authorization control (privilege management, need-to-know, logging)
• Transfer control (encryption in transit, VPN, TLS 1.2+)
• Input control (logging who entered what and when)
• Instruction control (instruction binding, sub-processor management)
• Availability control (backup, disaster recovery, UPS, redundancy)
• Separation control (multi-tenant separation, separated test/production environments)

The TOM description should be specific enough that a supervisor can verify effectiveness — generic phrases like "data is protected" are insufficient.

6. Sub-Processor Obligation (Art. 28(2) and (4))

A processor must not engage another processor without prior specific or general written authorization by the controller (Art. 28(2)). Two models are permissible:

• Specific authorization: each new sub-processor must be expressly approved — impractical for larger providers
• General authorization: the controller approves a list of current sub-processors; for changes, the processor must give timely notice and grant a right to object

Important: The main processor must impose the same data protection obligations on the sub-processor as in its own DPA (Art. 28(4) — "back-to-back" clause). For breaches by the sub-processor, the main processor is liable as for its own fault.

7. Third-Country Transfers (Chapter V GDPR)

Whenever personal data is transferred to a third country — almost always the case with US hyperscalers — Chapter V GDPR additionally applies. Permitted transfer bases:

• Adequacy decision (Art. 45) — for the United States, currently the EU-US Data Privacy Framework (DPF), in force since 10.07.2023. Transfers to DPF-certified US recipients are permissible like intra-EU transfers
• Standard Contractual Clauses (SCC, Art. 46(2)(c)) — new EU Commission modules of June 2021, four modules depending on constellation (C2C, C2P, P2P, P2C)
• Binding Corporate Rules (BCR) — intra-group rulebooks for multinational groups

After CJEU C-311/18 ("Schrems II"), SCC alone are not sufficient when the third-country law undermines protection (US surveillance laws FISA 702, EO 12333). A Transfer Impact Assessment (TIA) is required, possibly with supplementary technical safeguards (e.g., end-to-end encryption with customer-side key management).

8. Data Breach Notification (Art. 33 + 34)

The role allocation for personal data breaches is clearly regulated:

• The controller reports within 72 hours to the supervisory authority (Art. 33(1)) and, where required, notifies data subjects (Art. 34)
• The processor notifies the controller without undue delay after becoming aware (Art. 33(2)) — there is no separate deadline towards the authority

"Without undue delay" in EDPB interpretation means: without culpable hesitation, typically within 24 hours, to leave the controller enough time for its own 72-hour report. Practical recommendation: contractually fix 24 or 48 hours with a defined notification channel (emergency e-mail address, telephone hotline, documented escalation protocol).

9. Record of Processing Activities (Art. 30(2))

While Art. 30(1) governs the controller's record, paragraph 2 obliges every processor to maintain its own record. Mandatory contents:

• Name and contact details of the processor, where applicable of the EU representative and the DPO
• Name and contact details of each controller on whose behalf processing is carried out
• Categories of processing carried out on behalf of each controller
• Where applicable, third-country transfers with documentation of safeguards
• General description of TOM under Art. 32

The exemption under Art. 30(5) (fewer than 250 employees) almost never applies to IT service providers in practice, since their processing is not merely "occasional".

10. Template Overview for IT Service Providers

A practice-ready template set usually contains:

• DPA model contract (Art. 28) with annexes 1–3
• TOM description based on the eight-control system with concrete status
• Record of processing activities as processor (Art. 30(2))
• Breach notification process plus escalation matrix plus reporting form to the controller
• Sub-processor notification template with objection period (typically 30 days)
• SCC module selection guide plus Transfer Impact Assessment template
• Deletion concept after contract end (return vs. destruction, evidence log)
• Audit checklist for customer audits (what is shown, what stays confidential)

Summary

IT service providers are the textbook example of the GDPR processor role. The DPA, TOM description, sub-processor list, and breach notification process are the four documents that supervisors and customers will request first. Build them once correctly with proper annex structure and they cover the entire customer base — instead of re-negotiating each contract from scratch.

View GDPR Kit →