AVV: Auftragsverarbeitungsvertrag nach DSGVO | IT-Medienrecht

Der Auftragsverarbeitungsvertrag (AVV): Pflichten, Fallstricke und Praxisbeispiele

Auftragsverarbeitung ist Alltag: Cloud-Hosting, Newsletter-Versand, Support-Desk, Payment-Gateway, KI-Labeling, CRM-Betrieb. Spätestens wenn personenbezogene Daten im Auftrag verarbeitet werden, verlangt Art. 28 DSGVO einen belastbaren Auftragsverarbeitungsvertrag (AV-Vertrag, AVV). Der AVV ist kein Formularanhang, sondern die rechtsverbindliche Brücke zwischen Technik, Organisation und Haftung.

Dieser Beitrag bündelt die Pflichtinhalte aus Art. 28 Abs. 3 DSGVO in einem strukturierten Fließtext. Er zeigt praxistaugliche Klauselmechaniken für Subprozessoren, Audits, Technische und organisatorische Maßnahmen (TOMs) und Datenportabilität. Zudem grenzt er typische Fehlerbilder ab. Stilistisch knüpft der Text an die kompakten Wissensbeiträge auf itmedialaw.com an, vertieft aber die operative Ebene für SaaS-, Agentur-, Games- und KI-Setups.

Ausgangspunkt und Anwendungsbereich der Auftragsverarbeitung

Auftragsverarbeitung meint die Verarbeitung personenbezogener Daten „im Auftrag“ eines Verantwortlichen. Maßgeblich ist nicht die Etikette „Dienstleister“, sondern die Weisungsgebundenheit und Zweckbindung. Der Verarbeiter agiert nicht für eigene Zwecke, sondern ausschließlich innerhalb der dokumentierten Weisungen des Verantwortlichen. Typische Konstellationen sind Hosting, E-Mail-Versand, Analytik, Lohnabrechnung, Ticketsysteme, Content-Moderation oder Datenanreicherung.

Die Abgrenzung zu gemeinsamer Verantwortlichkeit (Art. 26 DSGVO) und zu eigenständiger Verantwortlichkeit ist zwingend. Wer Zwecke mitbestimmt, ist nicht mehr „bloß Verarbeiter“. Die rechtliche Trennschärfe schützt vor Rollenkonflikten und verhindert, dass Betroffenenrechte, Informationspflichten, Löschfristen oder Sicherheitsniveaus falsch verortet werden. Ein Blick in die kompakten itmedialaw-Einführungen zeigt die Praxisnähe des Themas im Vertrags- und Cloud-Kontext.

Die Kernpflichten im Auftragsverarbeitungsvertrag (AVV) nach Art. 28 Abs. 3 DSGVO

Gegenstand und Dauer der Verarbeitung

Ein AVV muss den Gegenstand und die Dauer der Verarbeitung benennen. Dies bedeutet nicht nur die Überschrift „Hosting“, sondern eine präzise Beschreibung der Verarbeitungsvorgänge. Dazu gehören Speichern, Abrufen, Übermitteln, Löschen, Sichern, Testen und Trainieren.

Die Dauer folgt der Lebenszeit des Hauptvertrags. Für Backups, Log-Retention und Nachlaufprozesse wird sie jedoch differenziert geregelt. Ohne diese Differenzierung bleiben Löschung und Herausgabe reine Theorie.

Art und Zweck der Verarbeitung

Erforderlich sind Art und Zweck der Verarbeitung. Betreibt man beispielsweise ein CRM, so verarbeitet man Stamm-, Kontakt- und Interaktionsdaten zur Kundenverwaltung. Ein DSP/AdTech-Partner verarbeitet pseudonyme IDs zur Kampagnenaussteuerung. Ein Annotation-Dienst bearbeitet Bild-, Text- oder Audiosegmente zum KI-Training.

Der Zweck ist strikt definiert. Eine „Zweckfortschreibung“ für interne Analytik des Verarbeiters ist ohne gesonderte Rechtsgrundlage unzulässig.

Art der Daten und Kategorien betroffener Personen

Zu nennen sind Art der personenbezogenen Daten und Kategorien betroffener Personen. Die Kategorien werden nicht generisch, sondern projektbezogen beschrieben. Beispiele sind Kund*innen, Leads, Beschäftigte, Creator oder Spieler-Accounts. Datenarten umfassen Identifikations-, Kommunikations-, Vertrags-, Nutzungs-, Support-, Zahlungs- oder Gesundheitsdaten.

Je sensibler die Daten (Art. 9 DSGVO), desto präziser muss die TOM-Tiefe sein und desto enger die Subprozessor-Steuerung. Ein Datenleck oder ein Sicherheitsvorfall kann hier weitreichende Folgen haben.

Rechte und Pflichten des Verantwortlichen

Der AVV verankert Rechte und Pflichten des Verantwortlichen, insbesondere das Weisungsrecht. Weisungen werden schriftlich oder in einem System dokumentiert. Der Verarbeiter prüft offenkundig rechtswidrige Weisungen und meldet Bedenken. Das Weisungsregime schließt Notfall-Weisungen ein, wenn Sicherheitsvorfälle ein sofortiges Handeln erfordern.

Vertraulichkeit, TOMs und Sicherheitsniveau

Kern der Verarbeiterpflichten sind Vertraulichkeit, TOMs (Technische und organisatorische Maßnahmen) und das Sicherheitsniveau. Jede Person mit Datenzugriff wird zur Vertraulichkeit verpflichtet. Die TOMs orientieren sich an Art. 32 DSGVO und werden als dynamische Anlage geführt.

Dazu gehört, dass der Stand der Technik, Implementierungskosten, Art, Umfang, Umstände und Zwecke der Verarbeitung berücksichtigt werden. Der AVV verweist nicht nur auf „ISO-Zertifikate“, sondern beschreibt konkrete Maßnahmen:

• Zugriffskontrollen
• Verschlüsselung und Schlüsselmanagement
• Netzwerksegmentierung und Härtung
• Logging und Monitoring
• Backup und Restore
• Schwachstellen-Management
• MFA-Pflichten (Multi-Faktor-Authentifizierung)
• Rollen- und Rechtekonzepte
• Pseudonymisierung und Datenminimierung
• Test- und Staging-Isolation
• Regelmäßige Wirksamkeitsprüfungen

Unterstützung bei Betroffenenrechten und Sicherheitsvorfällen

Der Verarbeiter unterstützt den Verantwortlichen bei:

• Betroffenenrechten (Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit, Widerspruch)
• Sicherheitsvorfällen (Art. 33/34 DSGVO)
• Datenschutz-Folgenabschätzungen (DSFA) (Art. 35 DSGVO)
• Kommunikation mit Aufsichtsbehörden

Dies geschieht jeweils mit klaren Reaktionszeiten und Prozessbeschreibungen. Ohne Service Level Agreements (SLAs) werden Fristen zur bloßen Hoffnung.

Löschung oder Rückgabe der Daten nach Auftragsende

Nach Auftragsende erfolgt die Löschung oder Rückgabe der personenbezogenen Daten. Dies umfasst Archiv-, Backup- und Log-Bestände, sofern keine gesetzliche Aufbewahrung entgegensteht. Der AVV regelt Exportformate und Prüfmechanismen, beispielsweise stichprobenhafte Delete-Nachweise oder Hash-basierte Abgleichsverfahren, um „Löschfiktionen“ zu vermeiden.

Nachweis- und Auditpflichten

Schließlich sind Nachweis- und Auditpflichten zu verankern. Der Verarbeiter stellt alle Informationen bereit, die zur Nachweisführung der Compliance erforderlich sind. Er ermöglicht Prüfungen durch den Verantwortlichen oder unabhängige Prüfer unter angemessenen Schutzvorkehrungen.

Der AVV balanciert dabei Vertraulichkeit, Frequenz und Kosten. Er erlaubt Remote-Audits, kombinierte Audit-Wochen, Report-Anerkennung (z. B. ISO/SOC) sowie Nachprüfungen nach Major-Incidents.

Wichtig für die Gestaltung: Die elektronische Form genügt (Art. 28 Abs. 9 DSGVO). Der AVV ist also signatur- oder portal-fähig. Gelebte Änderungsprotokolle und Versionsstände sichern die Beweisführung im Audit.

Subprozessoren: Erlaubnis, Kette, Kontrolle

Ohne Subprozessoren funktioniert kein modernes Setup. Gleichwohl verlangt Art. 28 Abs. 2/4 DSGVO eine vorgängige Genehmigung und die Durchreichung sämtlicher Pflichten an die Unterverarbeiter. Zwei Modelle sind üblich: spezifische Einzelfallgenehmigung oder allgemeine Genehmigung mit Subprozessor-Register und Widerspruchsrecht.

Praxisfest ist die allgemeine Genehmigung mit klaren Ankündigungsfristen bei Wechseln und Neuzugängen. Dies wird differenziert nach „kritisch“ (Storage, Core-Compute, Identity) und „nicht kritisch“ (z. B. E-Mail-Zustellung). Ein Register nennt Firma, Funktion, Land, Datenkategorien und die maßgeblichen TOM-Anker.

„Flow-Down“ bedeutet: Dieselben Datenschutzpflichten gelten in der Kette, einschließlich Audit-Kooperation und Incident-Meldewegen. Bei Drittlandbezug werden zusätzliche Garantien vereinbart (Standardvertragsklauseln, ggf. Transfer Impact Assessment). Ein schlanker, aber belastbarer Prozess verhindert „Schatten-Subprozessoren“ und adressiert Wechsel-Szenarien, ohne den Betriebsablauf zu blockieren.

Auditrechte ohne Stillstand: Nachweise, Remote-Prüfung, Anerkennungslogik

Audits sind kein Freibrief zur Betriebsunterbrechung. Der AVV definiert, wie geprüft wird: bevorzugt Remote-Audits, Einsicht in Policies, TOM-Anlagen, Risiko- und Maßnahmenregister, Stichproben von Tickets und Vorfällen, Einsicht in Pen-Test-Zusammenfassungen und Zertifizierungs-Reports. On-Site-Audits bleiben für sicherheitskritische Fälle und angekündigte Slots vorbehalten.

Ein Anerkennungsmechanismus stellt klar, welche externen Nachweise die Auditpflicht teilweise erfüllen (z. B. ISO 27001, SOC 2 Type II). Dies geschieht, ohne die gesetzlichen Kontrollrechte auszuhebeln. Fristen, Prüftage-Kontingente und Vertraulichkeits-Schleusen (Clean Rooms, View-Only-Zugriffe) verhindern Datenabflüsse und minimieren Geschäftsgeheimnis-Risiken.

TOMs richtig aufsetzen: Art. 32-Niveau, aber operativ

TOM-Anhänge geraten oft zu Schlagwortlisten. Wirksam wird der TOM-Anhang, wenn technische und organisatorische Maßnahmen kategorisiert, messbar und prüfbar sind. Dazu zählen:

• Identitäts- und Rechteverwaltung (RBAC/ABAC, Least Privilege, JIT-Admin)
• MFA für interne und externe Zugriffe
• Schlüsselmanagement (KMS/HSM, Rotation und Separation of Duties)
• Verschlüsselung „at rest“ und „in transit“
• Netzwerksegmentierung und Zero-Trust-Prinzipien
• Sicherheits-Logging mit fälschungssicheren Speichern
• Backup/Restore inklusive regelmäßiger Recovery-Tests
• Schwachstellen- und Patch-Prozesse
• Secure-SDLC (Code-Reviews, SAST/DAST, Secrets-Scanning, Build-Integrity)
• Data-Lifecycle-Management (Minimierung, Pseudonymisierung, Retention)
• Lieferketten-Kontrollen (SBOM, Abhängigkeits-Monitoring)
• Home-Office/BYOD-Regeln und Awareness-Programme

Die Wirksamkeitsprüfung erfolgt zyklisch und nach Major-Changes. Die Ergebnisse fließen in das Risikoregister. Die Aufsichtsbehörden erinnern daran, dass TOMs nicht zwingend im AVV selbst vollständig ausbuchstabiert sein müssen, sondern nachweisbar bewertet und dokumentiert werden. Operativ sinnvoll ist die Versionierung in einer Anlage mit Änderungsprotokoll.

Datenportabilität, Exit-Strategie und Löschnachweise

Der sauberste AVV verliert an Wert, wenn der Exit ungeklärt bleibt. Eine Portabilitäts-Klausel definiert deshalb Exportpfade:

• Formate (CSV, JSON, Parquet) und Schemata
• API-Zugänge
• Zeitleisten und Revisionsschleifen
• Kostenlogiken

Für komplexe Mandanten-Daten (z. B. in SaaS-Systemen) wird eine „Read-Only-Phase“ nach Vertragsende vereinbart. Während dieser Zeit ist der Zugriff noch möglich, aber es findet keine neue Verarbeitung statt.

Löschung bedeutet nicht nur das Entfernen aus Produktivsystemen. Der AVV bezieht Backups, Snapshots, Cold Storage, Crash Dumps und Protokolldaten ein. Stichprobenhafte Lösch-Atteste oder Hash-Vergleiche sichern die Nachweisführung, ohne Betriebsgeheimnisse zu entblößen. In Kettenverhältnissen verpflichtet der Verarbeiter Subprozessoren zur synchronen Löschung und dokumentiert deren Nachweise im Register.

Praxisbeispiele aus SaaS, KI und Games

SaaS-Betrieb eines CRM

Ein Verantwortlicher nutzt ein gehostetes CRM. Der AVV beschreibt Verarbeitungsvorgänge (Erfassen, Speichern, Segmentieren, Senden, Löschen), Datenarten (Stamm-, Kommunikations-, Nutzungsdaten) und Betroffenengruppen (Leads, Kund*innen). Das TOM-Niveau umfasst unter anderem Verschlüsselung, RBAC und MFA. Subprozessoren sind IaaS-Provider und E-Mail-Relays.

Die Audit-Mechanik erfolgt remote, mit SOC-Reports und jährlichen Slot-Prüfungen. Die Exit-Regelung umfasst Voll-Export, Datenlöschung und Log-Retention. Der Verantwortliche erhält Betroffenenkopien über den SaaS-Export; der Verarbeiter unterstützt, wenn Systemfelder nicht 1:1 auslesbar sind. So wird das in der itmedialaw-Wissensdatenbank oft skizzierte Datenschutz-Fundament in die Produktpraxis übersetzt.

KI-Annotation und Fine-Tuning

Ein Labeling-Dienst verarbeitet Bild- und Textdaten. Der AVV fixiert strenge Zweckbindung, Geheimhaltung und isolierte VDI-Umgebungen. Weitere Regelungen betreffen Wasserzeichen für Synthetic Data, den Umgang mit halluzinierten Inhalten und einen spezifischen Prozess zur Betroffenenrechte-Unterstützung bei Trainings-Datasets. Bei Drittlandbezug werden Standardvertragsklauseln (SCC) implementiert; Subprozessor-Wechsel werden 30 Tage zuvor angezeigt. DSFA-Unterstützung erhält eigene Reaktionsfenster. Messbare TOM-Kriterien (keine BYOD-Speicher, Copy/Paste-Blocker, Clipboardschutz) steigen in den Audit-Scope auf. Die zunehmende Verwendung von KI-generierten Inhalten erfordert präzise vertragliche Regelungen.

Games-Live-Ops mit externer Cloud

Telemetrie-Daten fließen in eine Analytics-Pipeline. Der IaaS-Provider ist Subprozessor; ein Event-Processing-Dienst und ein A/B-Testing-Tool ebenso. Der AVV verlangt Datenminimierung (nur erforderliche Events), getrennte Pseudonyme, Lösch-Propagation Richtung Subprozessoren und eine klare A/B-Datenaufbewahrung. Da Live-Ops schnell ist, regelt der AVV ein Express-Weisungsfenster für Hotfix-Änderungen an Event-Schemas, damit die Zweckbindung nicht „überholt“ wird. Besondere Aufmerksamkeit gilt dabei auch dem Jugendschutz bei Online-Games, da diese oft personenbezogene Daten von Minderjährigen verarbeiten.

Typische Fehler – und wie sie vermieden werden

Vermeiden Sie diese häufigen Fallstricke bei der Gestaltung und Umsetzung Ihres AV-Vertrags:

• Unbestimmter Scope: Formulierungen wie „Verarbeiter darf Daten zur Vertragserfüllung verarbeiten“ sind zu unpräzise. Sie beschreiben weder Vorgänge noch Zwecke.
  Abhilfe: Ein sprechender Scope inklusive Vorgangskatalog und Beispiel-Matrix, der den Rahmen zieht, ohne starre Technik zu verrechtlichen.
• Leere TOM-Schlagworte: „Verschlüsselung, Logging, Backup“ ohne Verfahren und Prüfpfade genügen nicht.
  Abhilfe: Ein TOM-Anhang benennt Verfahren (z. B. TLS-Versionen, KMS-Betrieb, Rotationszyklen), Kontrollen (Rollenzuordnung, Rezertifizierung) und Prüfungen (Recovery-Tests, Pen-Tests-Rhythmus).
• Schatten-Subprozessoren: Agenturen binden „kleine Helfer“ ein, ohne das Subprozessor-Register zu aktualisieren.
  Abhilfe: Eine allgemeine Genehmigung mit Register, Schwellenwerte für „kritische“ Subprozessoren, Benachrichtigungsfenster, Widerspruchs-Option und Exit-Varianten bei zwingenden Wechseln.
• Unrealistische Auditrechte: „Jederzeit, unangekündigt, vollständiger Systemzugriff“ ist in skalierenden Multi-Tenant-Umgebungen nicht praktikabel.
  Abhilfe: Ein kluger AVV koppelt Remote-Prüfungen, Report-Anerkennung und Slot-Audits mit Eskalationsstufen für Incidents.
• Exit ohne Portabilität: Eine „Löschung nach Ende“ ohne Exportformate führt zum Lock-In.
  Abhilfe: Ein Portabilitätsabschnitt definiert Formate, Fristen, Schnittstellen und Kostenlogik, damit Daten tatsächlich übergeben werden können.
• Art. 26-/28-Verwechslung: Joint-Controller-Modelle werden fälschlich als AVV etikettiert.
  Ergebnis: Falsche Informationspflichten, unklare Verantwortlichkeit bei Betroffenenrechten, Haftungsverschiebungen.
  Abgrenzung: Wer Zwecke mitbestimmt, ist am Steuer, nicht auf dem Beifahrersitz.
• „Datenschutz später“ in agilen Roll-outs: Feature-Teams gehen live, der AVV folgt. Dies ist riskant.
  Abhilfe: Verträge und TOM-Prozesse sind frühe Voraussetzungen – nicht nachrangige Formalitäten.
• Kopierte Muster ohne Datenwirklichkeit: Copy-&-Paste fremder Klauseln ignoriert reale Datenflüsse, Subprozessor-Ketten und Löschlogik. Das rächt sich im Audit oder nach einem Incident.
  Empfehlung: Praxisleitfäden erinnern daran, die Pflichtinhalte konkret zu verankern.

Mini-Musterlogik im AVV – ohne Formularästhetik

Ein Scope-Abschnitt benennt Verarbeitungsvorgänge, Zwecke, Datenarten, Betroffenenkategorien und die operativen Systeme. Er enthält einen dynamischen Anhang „Verarbeitungstätigkeiten“ mit Versionierung.

Ein Weisungs-Abschnitt beschreibt die Kanäle (Ticket, Portal, E-Mail-Signatur), Prioritäten, Reaktionsfenster und die Pflicht zur Beanstandung offenkundig rechtswidriger Weisungen.

Der TOM-Abschnitt verweist auf einen fortschreibbaren TOM-Anhang mit technischen und organisatorischen Maßnahmen, Prüf- und Review-Zyklen; Änderungen werden dokumentiert und angekündigt, ohne jedes Mal neu zu verhandeln.

Der Subprozessor-Abschnitt wählt die allgemeine Genehmigung, stellt ein Register bereit, regelt Ankündigungsfristen, Widerspruch und „Flow-Down“ inklusive Audit-Kooperation.

Der Audit-Abschnitt erlaubt Remote-Prüfungen, anerkennt ISO/SOC-Berichte, wahrt Mandanten- und Geheimnisschutz und macht On-Site-Audits zur Ausnahme mit Vorlauf.

Der Support-Abschnitt für Betroffenenrechte, DSFA und Incidents enthält SLA-Fenster (z. B. 48 Stunden für Erstreaktion bei Datenschutzvorfällen; 5 Werktage für betroffenenrechtliche Zuarbeit).

Der Datenübermittlungs-Abschnitt ordnet Drittlandsübermittlungen und SCC sauber ein und koppelt Transfer Impact Assessments an Subprozessor-Wechsel.

Portabilität und Exit definieren Exportformate, Prüfschritte, Lösch-Propagation und Nachweise. Haftung und Vertragsstrafe bleiben maßvoll und kausalitätsnah; sie sind kein Ersatz für gute TOMs, sondern flankieren Sorgfaltspflichten.

Verzahnung mit dem Hauptvertrag

Der AVV lebt nicht isoliert, sondern bezieht sich auf den Hauptvertrag. Servicebeschreibungen und SLAs müssen die Datenschutz-Pflichten spiegeln. Wenn 24/7-Support vereinbart ist, brauchen Incident-Prozesse 24/7-Erreichbarkeit. Wenn Near-/Offshore-Teams arbeiten, muss das Subprozessor-Register und die Transfer-Absicherung dieses Setup abbilden.

Preisblöcke berücksichtigen Datenschutz-Aufwände (z. B. Export-Aufwände oder zusätzliche Audittage) transparent, statt sie zu „verstecken“. Change-Prozesse sehen eine Datenschutz-Prüfung vor (Privacy by Design/Default), damit neue Features nicht an Art. 28 DSGVO scheitern. So entsteht eine konsistente Linie, die man auf itmedialaw.com im Cloud- und Vertragsumfeld wiedererkennt: Datenschutz wird als integraler Teil der Produktleistung verstanden, nicht als störende Beilage.

Operative Durchführung: Governance schlägt Formular

Ein unterschriebener AVV ist nur der Anfang. Verantwortliche prüfen vor Beginn eines Dienstleister-Einsatzes, ob hinreichende Garantien bestehen – nicht erst im Incident. Dazu gehört die Bewertung der TOMs, die Einsicht in Zertifikate/Reports, ein Risiko-Scoring und die Dokumentation im Vendor-Register.

Während der Laufzeit wird dieser Status turnusmäßig aktualisiert, bei Major-Changes und Incidents ad hoc. Der Verarbeiter führt Awareness-Programme durch, erneuert Vertraulichkeitsbindungen, kontrolliert Zugriffsrechte und pflegt die Subprozessor-Liste. Der gemeinsame Blick gilt der Nachweisführung: Wer in drei Klicks zeigen kann, welche TOM-Version galt, wann ein Subprozessor neu aufgenommen wurde und wann der letzte Restore-Test erfolgreich war, besteht jede Prüfung – vertraglich und faktisch. Diese Governance-Linie ergibt sich aus den Grundpflichten von Art. 28 Abs. 1, 3 DSGVO und der dort angelegten Nachweislogik. Auch Neuerungen im Datenschutzrecht müssen hierbei stets berücksichtigt werden.

Der AV-Vertrag in Kürze: Eine Checkliste für die Praxis

Was gehört in einen AVV? Ein klarer Verarbeitungsscope mit Dauer, Zwecken, Datenarten und Betroffenen; ein dokumentiertes Weisungsregime; belastbare TOMs nach Art. 32 DSGVO; transparente Subprozessor-Ketten mit Genehmigung, Ankündigungsfristen und „Flow-Down“; Audit- und Nachweismechanik; SLA-fähige Unterstützung bei Betroffenenrechten, DSFA und Incidents; Exit- und Portabilitäts-Regelungen; Löschung mit Nachweis; Drittland-Absicherung; und eine konsistente Verzahnung mit dem Hauptvertrag. Wer diese Elemente auf der Ebene von Verfahren, Fristen und Nachweisen verankert, hat nicht nur „einen AVV“, sondern eine überprüfbare Datenschutz-Architektur. Praxis-Checklisten zeigen denselben Kern – entscheidend ist die Übersetzung in den eigenen Tech-Stack.

Fazit

Ein guter AV-Vertrag ist präzise, prüfbar und betrieblich umsetzbar. Pflichtinhalte aus Art. 28 DSGVO bilden das Fundament. Subprozessor-Steuerung, Audit-Mechanik, TOM-Versionierung und Portabilität machen den Vertrag alltagstauglich. Muster helfen – entscheidend bleibt die Anpassung an reale Datenflüsse, Systeme und Verantwortlichkeiten. Für Cloud-, SaaS-, Games- und KI-Vorhaben gilt: Der AVV ist Produkt- und Prozessrecht zugleich. Wer ihn so versteht, reduziert Risiken, beschleunigt Audits und schafft Vertrauen bei Kundschaft, Partnern und Aufsicht.

Empfehlung: Vor Abschluss und bei größeren Änderungen die konkrete Datenwirklichkeit prüfen – und beraten lassen.