---
name: "DSGVO-Subprozessor-Register-Vorlage"
version: "1.0"
updated: "2026-07-24"
source: "https://www.orbiqhq.com/de/vorlagen/dsgvo-subprozessor-register-vorlage"
license: "Kostenlos nutz- und anpassbar innerhalb Ihrer Organisation. Namensnennung willkommen. Keine Rechtsberatung."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2016/679/oj"            # DSGVO — Art. 28(2), 28(3)(d), 28(4), 30(2), Kapitel V
  - "https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj"       # SCCs für Übermittlungen in Drittländer
  - "https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-222024-on-certain-obligations-following-from-the_en"  # EDSA-Stellungnahme 22/2024
---

# DSGVO-Subprozessor-Register-Vorlage (maschinenlesbar)

Zweck: die Subprozessor-Liste führen, die ein Auftragsverarbeiter nach DSGVO Artikel 28(2) und
der EDSA-Stellungnahme 22/2024 braucht — jeder Subprozessor in der Kette mit Identität, Dienst,
Datenkategorien, Verarbeitungsort, Übermittlungsmechanismus und Sicherheitsgarantien — zusammen
mit dem Änderungsprotokoll (der Nachweisspur der Mitteilungen nach Artikel 28(2)) und dem
Sorgfaltsprüfungs-Protokoll (dem laufenden Nachweis der „hinreichenden Garantien" nach
Artikel 28(1)). Diese Datei ist in sich geschlossen: Ein Agent kann aus den nachstehenden
Definitionen Registerdatensätze anlegen, die öffentliche Subprozessor-Liste erzeugen,
Änderungsmitteilungen anstoßen und den Sorgfaltsprüfungs-Zeitplan führen.

Strukturregeln:
1. EIN Registerdatensatz je Subprozessor, EINSCHLIESSLICH Sub-Subprozessoren weiter unten in
   der Kette (EDSA-Stellungnahme 22/2024: Der Verantwortliche muss jeden Akteur in der Kette
   identifizieren können). Kettenzugehörigkeit wird über `engaged_by` + `chain_tier`
   ausgedrückt, niemals durch Weglassen.
2. Das Register ist die QUELLE; die öffentliche Subprozessor-Seite / Trust-Center-Liste ist eine
   Projektion der Datensätze mit `status` in {active, announced}. Datensätze werden nie
   gelöscht — Entfernungen setzen `status` auf `removed` und behalten ihre Historie.
3. Eine neue Hinzuziehung folgt der Sequenz: Sorgfaltsprüfungs-Datensatz (freigegeben) →
   Registerdatensatz mit `status: announced` → Änderungsprotokoll-Datensatz mit versandter
   Mitteilung → `status: active` erst, nachdem `objection_deadline` ohne ungelösten Widerspruch
   verstrichen ist.
4. Dieses Register ist KEIN Verzeichnis von Verarbeitungstätigkeiten (DSGVO Art. 30 — siehe
   gdpr-ropa-template.md) und NICHT die Änderungsmitteilung selbst (siehe
   gdpr-subprocessor-change-notice.md). Die drei Dateien greifen über `subprocessor_name` und
   `notice_ref` ineinander.

Jurisdiktionshinweise: Die UK GDPR übernimmt Artikel 28 unverändert (der ICO erwartet eine
explizite Widerspruchsfrist). Norwegen wendet die DSGVO über das EWR-Abkommen an
(personopplysningsloven, Datatilsynet). Übermittlungen EWR→UK stützen sich auf die erneuerten
UK-Angemessenheitsbeschlüsse (2025 verlängert, Auslauf 2031-12-27); EWR-interne Verarbeitung
einschließlich Norwegens braucht keinen Übermittlungsmechanismus. In Deutschland ist das
DSK-Kurzpapier Nr. 13 die gemeinsame Position der Aufsichtsbehörden: Der AVV muss die
Hinzuziehung von Unterauftragsverarbeitern ausdrücklich regeln, erwartet werden eine benannte
aktuelle Liste, aktive (Push-)Benachrichtigung statt Seiten-Beobachtung und ein reales
Widerspruchsrecht.

---

## 1. Subprozessor-Register — ein Datensatz je Subprozessor in der Kette

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `subprocessor_name` | Text, eindeutig | PRIMÄRSCHLÜSSEL — juristischer Name der Einheit |
| 2 | `registered_address` | Text | Eingetragene Anschrift (EDSA 22/2024: Identität + Anschrift für jeden Ketten-Akteur) |
| 3 | `country_of_establishment` | Text (ISO 3166-1 alpha-2) | Wo die Einheit niedergelassen ist |
| 4 | `contact` | Text (E-Mail/URL) | Datenschutz-/DSB-Kontakt des Subprozessors |
| 5 | `service_description` | Text | Was der Subprozessor tut und welches Produkt / welchen Dienst er unterstützt |
| 6 | `data_categories` | Liste | Kategorien verarbeiteter personenbezogener Daten (z. B. Kontaktdaten, Nutzungsdaten, Kundeninhalte) |
| 7 | `special_categories` | Enum: `yes` / `no` | Besondere Kategorien nach Art. 9 betroffen? Bei `yes` steigen Prüf- und Mitteilungstiefe |
| 8 | `processing_locations` | Liste von Ländern | Wo die Daten tatsächlich verarbeitet werden (nicht der Hauptsitz) |
| 9 | `transfer_mechanism` | Enum | `none_eea_only` / `adequacy_decision` / `sccs_2021_914_plus_tia` / `binding_corporate_rules` / `other_art46_safeguard` / `art49_derogation_exceptional` |
| 10 | `transfer_detail` | Text | Welcher Angemessenheitsbeschluss, oder SCC-Modul + TIA-Datum. Pflicht, außer der Mechanismus ist `none_eea_only` |
| 11 | `security_guarantees` | Text | Zertifizierungen (ISO/IEC 27001, SOC 2) oder TOMs-Zusammenfassung als Stütze für Art. 28(1) |
| 12 | `engaged_by` | Text | Ketten-Elternteil: `us` für direkte Subprozessoren, sonst der Name des hinzuziehenden (Sub-)Auftragsverarbeiters |
| 13 | `chain_tier` | Enum: `tier1` / `tier2` / `tier3_or_deeper` | Tiefe in der Unterauftragskette |
| 14 | `flowdown_contract_date` | Datum (ISO 8601) | Datum des Weitergabevertrags nach Art. 28(4), der dieselben Pflichten auferlegt |
| 15 | `status` | Enum | `announced` (Widerspruchsfrist läuft) / `active` / `offboarding` / `removed` |
| 16 | `effective_date` | Datum | Wann die Verarbeitung beginnt/begann. Für `announced`-Datensätze MUSS dieses Datum nach `objection_deadline` liegen |
| 17 | `last_verified` | Datum | Letzte Re-Verifizierung der Sorgfaltsprüfung (Verknüpfung zum Sorgfaltsprüfungs-Protokoll) |
| 18 | `notice_ref` | Text | Jüngster Änderungsprotokoll-Datensatz zu diesem Subprozessor |

## 2. Änderungsprotokoll — ein Datensatz je Änderung

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `notice_ref` | Text, eindeutig | PRIMÄRSCHLÜSSEL, z. B. `SUB-2026-002` |
| 2 | `notice_sent` | Datum | Datum, an dem die Mitteilung an die Verantwortlichen ging (Push, nicht nur Seiten-Update) |
| 3 | `subprocessor_name` | Text | FK → Register |
| 4 | `change_type` | Enum | `addition` / `replacement` / `removal` / `material_change` |
| 5 | `summary` | Text | Was sich geändert hat, in für Verantwortliche lesbarer Sprache |
| 6 | `channels` | Liste | z. B. `email_subscribers`, `trust_center_update` — mindestens ein aktiver (Push-)Kanal erforderlich |
| 7 | `controllers_scope` | Text | Welche Verantwortlichen benachrichtigt wurden (alle / Segment) |
| 8 | `objection_deadline` | Datum | Explizite Frist; das Fenster ist vertraglich (~15 Tage typisch, 30–60 verhandelt, 90 selten) |
| 9 | `objections_received` | Ganzzahl | Anzahl der Widersprüche |
| 10 | `outcome` | Enum | `window_open` / `no_objection_effective` / `workaround_agreed` / `objection_upheld_not_engaged` / `contract_terminated_by_controller` / `withdrawn` |
| 11 | `effective_date` | Datum | Wann die Änderung wirksam wird/wurde |
| 12 | `register_updated` | Datum | Wann Register/öffentliche Liste aktualisiert wurden (muss ≤ `notice_sent` sein) |
| 13 | `evidence_link` | Text | Abgelegtes Mitteilungsdokument / Versandprotokoll |

## 3. Sorgfaltsprüfungs-Protokoll — ein Datensatz je Bewertung

| # | Feld | Typ | Definition / Regel |
|---|---|---|---|
| 1 | `subprocessor_name` | Text | FK → Register |
| 2 | `assessment_date` | Datum | Wann die Bewertung durchgeführt wurde |
| 3 | `assessor` | Text (Rolle) | z. B. DSB, Security Lead |
| 4 | `guarantees_reviewed` | Text | Was geprüft wurde: Zertifikate, Prüfberichte, TOMs, Vorfallshistorie |
| 5 | `certifications_verified` | Liste | z. B. `ISO/IEC 27001:2022`, `SOC 2 Type II` — Geltungsbereich + Gültigkeit verifizieren, nicht Logos |
| 6 | `toms_ref` | Text | Referenz auf die geprüften technischen und organisatorischen Maßnahmen |
| 7 | `tia_date` | Datum oder `n/a` | Datum der Transfer-Folgenabschätzung — PFLICHT, wenn `transfer_mechanism` = `sccs_2021_914_plus_tia` |
| 8 | `subsubprocessors_disclosed` | Enum: `yes` / `no` | Hat der Subprozessor seine eigene Kette offengelegt? (EDSA 22/2024 erwartet Transparenz über die ganze Kette) |
| 9 | `result` | Enum | `approved` / `approved_with_conditions` / `rejected` |
| 10 | `conditions` | Text | Follow-ups, z. B. Option auf EU-Region-Routing, Monitoring des DPF-Status |
| 11 | `next_review_due` | Datum | Re-Verifizierung ist laufend, nicht einmalig |

---

## Agent-Workflow-Hinweise

- Zum VERÖFFENTLICHEN der öffentlichen Liste: Registerdatensätze mit `status` in {`active`,
  `announced`} auswählen, die Felder 1, 3, 5, 6, 8, 9, 15, 16 projizieren und nach
  `subprocessor_name` sortieren. `announced`-Datensätze müssen die Widerspruchsfrist anzeigen.
- Zum HINZUFÜGEN eines Subprozessors: Sorgfaltsprüfungs-Datensatz anlegen; wenn `result` !=
  `rejected`, den Registerdatensatz mit `status: announced` anlegen, die Mitteilung aus
  gdpr-subprocessor-change-notice.md erzeugen, den Änderungsprotokoll-Datensatz anlegen und den
  Statuswechsel für `objection_deadline + 1 Tag` planen, bedingt darauf, dass
  `objections_received` gelöst ist.
- Zum PRÜFEN der Register-Gesundheit: Jeder `active`-Datensatz braucht (a) `last_verified`
  innerhalb der Überprüfungskadenz, (b) ein `flowdown_contract_date`, (c) ein befülltes
  `transfer_detail`, außer `transfer_mechanism` = `none_eea_only`, und (d) eine auflösbare
  `notice_ref`.
- DPF-Vorbehalt: Datensätze, die sich auf das EU-US Data Privacy Framework stützen, sollten zum
  Monitoring markiert werden — das Gericht der EU hat die Latombe-Klage abgewiesen
  (2025-09-03), aber das Rechtsmittel ist beim EuGH anhängig; SCCs + TIA bleiben der belastbare
  Standard für US-Subprozessoren.

## Beispieldatensätze (fiktiv — Aurora Software GmbH, Berliner B2B-SaaS)

```yaml
- subprocessor_name: "Helvetia Cloud AG"
  registered_address: "Werdstrasse 2, 8004 Zürich, Switzerland"
  country_of_establishment: "CH"
  contact: "privacy@helvetiacloud.example"
  service_description: "Produktions-Hosting und Storage für die Aurora-Plattform (EU-Region)"
  data_categories: ["Kontodaten", "Nutzungsdaten", "Kundeninhalte"]
  special_categories: "no"
  processing_locations: ["DE"]
  transfer_mechanism: "adequacy_decision"
  transfer_detail: "Angemessenheit Schweiz (Beschluss 2000/518/EG, bestätigt im Review 2024)"
  security_guarantees: "ISO/IEC 27001:2022, SOC 2 Type II"
  engaged_by: "us"
  chain_tier: "tier1"
  flowdown_contract_date: "2024-03-11"
  status: "active"
  effective_date: "2024-04-01"
  last_verified: "2026-05-14"
  notice_ref: "SUB-2024-001"

- subprocessor_name: "Frankfurt DC Ops GmbH"
  registered_address: "Hanauer Landstraße 300, Frankfurt, Germany"
  country_of_establishment: "DE"
  contact: "security@fdcops.example"
  service_description: "Rechenzentrumsbetrieb, hinzugezogen durch Helvetia Cloud AG"
  data_categories: ["Kundeninhalte (verschlüsselt at rest)"]
  special_categories: "no"
  processing_locations: ["DE"]
  transfer_mechanism: "none_eea_only"
  transfer_detail: "—"
  security_guarantees: "ISO/IEC 27001:2022, ISO 22301"
  engaged_by: "Helvetia Cloud AG"
  chain_tier: "tier2"
  flowdown_contract_date: "2024-03-11"
  status: "active"
  effective_date: "2024-04-01"
  last_verified: "2026-05-14"
  notice_ref: "SUB-2024-001"
```