Skip to content

Was ist ein Data Sharing Agreement?

Image of Budi Voogt
Budi Voogt 25. Aug. 2026

Ein Data Sharing Agreement (DSA) ist ein Vertrag zwischen zwei oder mehr Organisationen, der festlegt, welche Daten die eine Seite der anderen überlässt, zu welchen Zwecken, unter welchen Schutzmaßnahmen und was die empfangende Seite mit den Daten nicht tun darf. Er benennt die Datensätze, fixiert die zulässigen Verwendungen, verteilt die Verantwortung für Sicherheit und Datenpannen und regelt, was mit den Daten geschieht, wenn die Zusammenarbeit endet.

Datenverantwortliche im Krankenhaus protokolliert ein versiegeltes Laufwerk, Forscher unterzeichnet Data Sharing Agreement

Das prägende Merkmal ist, dass die empfangende Seite die Daten in der Regel für eigene Zwecke nutzen darf, innerhalb der Grenzen, die die Vereinbarung zieht. Genau das unterscheidet ein Data Sharing Agreement von einem Data Processing Agreement, bei dem ein Dienstleister Daten ausschließlich nach den dokumentierten Weisungen des Kunden verarbeitet und keinen eigenen Zweck verfolgt. Nach der General Data Protection Regulation (GDPR) der Europäischen Union (EU) ist es dieses reine Weisungsverhältnis, das ein Vertrag mit einem Auftragsverarbeiter verbindlich festschreiben muss, einschließlich Vertraulichkeitszusagen, Sicherheitsmaßnahmen, Bedingungen für Unterauftragsverarbeiter sowie Löschung oder Rückgabe der Daten am Ende der Leistung [1]. Ein Data Sharing Agreement hat einen anderen Zuschnitt: zwei Organisationen, von denen jede einen eigenen Grund hat, die Daten haben zu wollen.

Dieser Leitfaden beschreibt die Praxis in den Vereinigten Staaten. Für Organisationen in Deutschland ist das vor allem dann relevant, wenn sie Daten mit US-Vertragspartnern, Forschungspartnern oder Kunden austauschen. Mehrere der nachfolgenden Regeln stammen aus einem bestimmten bundesrechtlichen Regime oder aus einem einzelnen einzelstaatlichen Gesetz und nicht aus einer allgemein geltenden nationalen Regel, und die jeweilige Grundlage wird in dem Satz genannt, in dem sie gilt. Es handelt sich um allgemeine Informationen und nicht um Rechtsberatung zu einer konkreten Vereinbarung.

Die Bezeichnung auf dem Deckblatt hat kein rechtliches Gewicht. Das UK Information Commissioner's Office (ICO), dessen Data Sharing Code eine der ausführlichsten öffentlich zugänglichen Darstellungen dieses Dokuments ist, weist darauf hin, dass Organisationen für dasselbe Instrument Titel wie information sharing agreement, data or information sharing protocol und personal information sharing agreement verwenden [2]. In der US-Praxis begegnen Ihnen zusätzlich data use agreement, data transfer agreement, data exchange agreement oder schlicht ein Datenanhang, der an einen größeren Vertrag angehängt wird.

Manche Dokumente wirken verwandt, sind aber nicht dasselbe. Der ICO Code stellt fest, dass ein Memorandum of Understanding für sich genommen kein Data Sharing Agreement darstellt, außer zwischen Regierungsbehörden und bestimmten anderen öffentlichen Stellen wie Aufsichts- und Strafverfolgungsbehörden, und dass weder eine Liste von Standards noch ein Nachtrag zu einem Kaufvertrag oder einer Bestellung diese Anforderung erfüllt [2]. Das ist britische Guidance, doch der zugrunde liegende Gedanke lässt sich übertragen: Ein Dokument, das guten Willen festhält, ohne eine der beiden Seiten auf konkrete Pflichten im Umgang mit Daten zu verpflichten, erfüllt diesen Zweck nicht.

Zwei US-Untertypen sind Regulierungsinstrumente mit festgelegtem Inhalt und keine frei verhandelten kommerziellen Dokumente.

Der erste ist das data use agreement nach dem Health Insurance Portability and Accountability Act (HIPAA). Eine Covered Entity darf einen Limited Data Set für Forschung, öffentliche Gesundheit oder Health Care Operations nur dann offenlegen, wenn sie mit der empfangenden Stelle ein data use agreement schließt. Die Regelung schreibt vor, was diese Vereinbarung leisten muss: die zulässigen Nutzungen und Offenlegungen bestimmen, bestimmen, wer die Daten nutzen oder erhalten darf, und die empfangende Stelle verpflichten, die Informationen nicht anders als erlaubt zu nutzen oder weiterzugeben, angemessene Schutzmaßnahmen anzuwenden, jede nicht vorgesehene Nutzung oder Offenlegung zu melden, ihre eigenen Beauftragten denselben Beschränkungen zu unterwerfen und die Informationen weder zu reidentifizieren noch die betroffenen Personen zu kontaktieren [3]. Ein Limited Data Set ist kein de-identifizierter Datensatz. Es sind Daten, aus denen eine festgelegte Liste direkter Identifikatoren entfernt wurde, darunter Namen, Straßenanschrift, Telefon- und Faxnummern, E-Mail-Adressen, Sozialversicherungs- und Patientenaktennummern, Gerätekennungen, Internet-Protocol-Adressen (IP-Adressen), biometrische Identifikatoren und Aufnahmen des vollen Gesichts, während Datumsangaben sowie Ort, Bundesstaat und Postleitzahl verbleiben dürfen [3].

Der zweite ist die Familie der behördenübergreifenden Vereinbarungen auf Bundesebene. Bei den Centers for Medicare & Medicaid Services (CMS) richtet sich die Art der Vereinbarung nach den Daten und dem Zweck: ein data use agreement, wenn eine andere Behörde die Offenlegung von personenbezogenen identifizierbaren Informationen (PII) oder geschützten Gesundheitsinformationen (PHI) durch CMS verlangt, ein information exchange agreement, wenn PII von CMS mit einer anderen Behörde des Bundes oder eines Bundesstaats ausgetauscht werden, ohne dass sich dies nachteilig auf die Leistungsansprüche einer Person auswirkt, und ein computer matching agreement, wenn automatisierte Systems of Record so abgeglichen werden, dass Bundesleistungen betroffen sind oder der Abgleich der Rückforderung von Zahlungen oder der Aufklärung von Betrug dient [4]. Wenn eine Gegenpartei nach einem DSA fragt, lohnt es sich, vor dem Entwurf zu klären, welches dieser Dokumente gemeint ist.

Zweck und typische Anwendungsfälle

Ein Data Sharing Agreement existiert, damit die Bedingungen des Austauschs nachweisbar sind, bevor die Daten fließen, und damit beide Seiten hinterher etwas in der Hand haben, auf das sie verweisen können. Es hält fest, warum die Weitergabe erforderlich ist, was tatsächlich übergeben wurde, wer sie genehmigt hat und welche Beschränkungen die empfangende Seite akzeptiert hat. Der ICO Code fasst das als Rechenschaftspflicht: Ein Data Sharing Agreement ist nach britischem Recht nicht verpflichtend, aber es hilft einer Organisation zu belegen, dass sie die relevanten Compliance-Fragen geprüft und dokumentiert hat, und das ICO erklärt, es werde eine einschlägige Vereinbarung bei der Bewertung einer Beschwerde über Datenweitergabe berücksichtigen [2].

In manchen US-Kontexten ist eine schriftliche Vereinbarung überhaupt nicht optional.

Forschung. Daten mit kontrolliertem Zugang werden an zugelassene Nutzer nur gegen eine unterzeichnete Vereinbarung herausgegeben und nicht frei zum Download angeboten. Das Genomic Data Sharing Framework der NIH beruht auf einem Data Use Certification Agreement mit Bedingungen wie der Nichtübertragbarkeit, weshalb ein Imputationsserver hochgeladene Genotypen nur kurz vorhalten darf, bevor sie gelöscht werden. Die NIH haben im Dezember 2025 einen Vorschlag veröffentlicht, eine umfassendere Controlled-Access Data Policy einzuführen und die Genomic Data Sharing Policy zu überarbeiten, mit einer Kommentarfrist bis zum 18. März 2026, sodass Einrichtungen mit laufenden Forschungsdatenflüssen mit Bewegung in diesem Rahmen rechnen sollten [5].

Bildung. Der Family Educational Rights and Privacy Act (FERPA) erlaubt die Offenlegung von Education Records an Organisationen, die Studien für Schulen oder in deren Auftrag durchführen, um prognostische Tests zu entwickeln oder zu validieren, Studienbeihilfen zu verwalten oder den Unterricht zu verbessern, allerdings nur auf Grundlage einer schriftlichen Vereinbarung, die Zweck, Umfang und Dauer der Studie sowie die offenzulegenden Informationen bestimmt, die Nutzung auf diesen Zweck beschränkt, eine Identifizierung von Personen durch andere als die Vertreter der Organisation verhindert und die Vernichtung aller personenbezogen identifizierbaren Informationen verlangt, sobald sie nicht mehr benötigt werden [6].

Kommerzielle Offenlegung nach einzelstaatlichem Datenschutzrecht. California verlangt von einem Unternehmen, das personenbezogene Informationen an einen Dritten verkauft, mit einem Dritten teilt oder gegenüber einem Service Provider oder Contractor offenlegt, eine Vereinbarung zu schließen, die die begrenzten und ausdrücklich benannten Zwecke bestimmt, die empfangende Seite verpflichtet, dasselbe Datenschutzniveau zu gewährleisten, das das Gesetz verlangt, dem Unternehmen Rechte einräumt, angemessene Schritte zur Sicherstellung einer vereinbarungskonformen Nutzung zu unternehmen, die empfangende Seite verpflichtet, das Unternehmen zu benachrichtigen, wenn sie ihre Pflichten nicht mehr erfüllen kann, und dem Unternehmen das Recht gibt, unbefugte Nutzung zu unterbinden und abzustellen [7].

Gemeinsame Programme und Empfehlungsprozesse. Zwei Organisationen, die einen gemeinsamen Dienst, eine Co-Marketing-Vereinbarung oder einen Empfehlungsprozess betreiben, verfolgen jeweils einen eigenen Zweck mit den Daten, sodass keine von beiden nach Weisung der anderen verarbeitet. Nach der GDPR sind zwei oder mehr Verantwortliche, die gemeinsam die Zwecke und Mittel der Verarbeitung festlegen, gemeinsam Verantwortliche und müssen ihre jeweiligen Zuständigkeiten in einer Vereinbarung zwischen ihnen festlegen, und die wesentlichen Inhalte dieser Vereinbarung müssen den betroffenen Personen zur Verfügung gestellt werden [1].

Parteien eines Data Sharing Agreements

In der Regel gibt es zwei benannte Parteien: die offenlegende Organisation, teils als Data Provider oder Quelle bezeichnet, und die empfangende Organisation, teils als Recipient oder Data User bezeichnet. Die richtige juristische Person zu erfassen ist hier so wichtig wie in jedem anderen Vertrag. Handelt es sich bei der empfangenden Seite um eine Forschungseinrichtung, bindet sie üblicherweise die Unterschrift eines zeichnungsberechtigten Vertreters der Einrichtung und nicht die des einzelnen Forschers, der die Daten anfordert.

Die offenlegende Partei ist dafür verantwortlich, überhaupt die Befugnis oder Rechtsgrundlage für die Offenlegung zu besitzen, nur die in der Vereinbarung genannten Felder zu übergeben und für die Richtigkeit zum Zeitpunkt der Übermittlung einzustehen. Nach HIPAA bleibt sie auch danach in der Pflicht: Erfährt eine Covered Entity von einem Verhaltensmuster oder einer Praxis der empfangenden Seite, die einen wesentlichen Verstoß gegen das data use agreement darstellt, muss sie angemessene Schritte unternehmen, um den Verstoß zu heilen oder die Offenlegung zu beenden, und den Vorgang an den Secretary melden, wenn beides nicht möglich ist [3].

Die empfangende Partei trägt die operative Last. Sie hält die Daten an die genannten Zwecke gebunden, wendet die vereinbarten Schutzmaßnahmen an, hält eigene Beschäftigte und Beauftragte innerhalb derselben Beschränkungen, meldet Vorfälle und gibt die Daten fristgerecht zurück oder vernichtet sie.

Zwei weitere Gruppen sind wichtig, ohne zu unterschreiben. Beauftragte, Subunternehmer und nachgelagerte Empfänger müssen über Flow-down-Klauseln gebunden werden, und genau das verlangt das HIPAA data use agreement für jeden Beauftragten [3]. Und die Personen, die die Daten beschreiben, sind keine Vertragsparteien, behalten aber Rechte gegenüber den Organisationen, die ihre Daten halten. Deshalb muss die Vereinbarung regeln, wer ein Auskunftsersuchen beantwortet. Nach der GDPR kann eine betroffene Person ihre Rechte gegenüber jedem gemeinsam Verantwortlichen geltend machen, unabhängig davon, was die Verantwortlichen untereinander vereinbart haben [1].

Zentrale Bestimmungen und Klauseln

Data Sharing Agreement, verschlüsseltes Laufwerk und Zugangskarten auf einem hellen modernen Tisch

Die meisten tragfähigen Data Sharing Agreements decken dasselbe Terrain ab. Die Bezeichnungen der Klauseln variieren, die Fragen dahinter nicht.

Datenspezifikation. Genau welche Datensätze, Tabellen und Felder übergeben werden. Der ICO Code verlangt diese Präzision und weist darauf hin, dass in manchen Fällen nur bestimmte Informationen einer Datei geteilt und sensiblere Inhalte weggelassen werden sollten und dass Berechtigungen an einzelne Datenelemente geknüpft werden können, sodass nur geschulte Beschäftigte in bestimmten Rollen darauf zugreifen dürfen [2]. Eine Spezifikation, die „Kundendaten" sagt, ist keine Spezifikation.

Zweck und zulässige Nutzungen. Was die empfangende Seite mit den Daten tun darf, eng genug formuliert, um überprüfbar zu sein. Jedes der oben genannten Regime baut auf dieser Klausel auf, und sie entscheidet darüber, ob eine spätere Nutzung ein Verstoß oder Alltagsgeschäft ist.

Zugelassene Empfänger und Zugriff. Wer innerhalb der empfangenden Organisation die Daten berühren darf und ob namentlich benannte Personen, Rollen oder verbundene Unternehmen erfasst sind.

Rechtsgrundlage oder Befugnis. Die Grundlage, auf der jede Seite Daten weitergibt oder empfängt. Der ICO Code weist darauf hin, dass die Rechtsgrundlage der einen Organisation in einer Sharing-Konstellation nicht dieselbe sein muss wie die der anderen und dass die Vereinbarung die herangezogene rechtliche Befugnis festhalten sollte [2].

Sicherheit und Schutzmaßnahmen. Technische und organisatorische Maßnahmen, Übertragungsweg, Speicherort und Zugriffskontrollen. Üblich ist es, einen Standard zu benennen statt einer vagen Sorgfaltspflicht.

Keine Reidentifizierung und keine Kontaktaufnahme. Eine Standardklausel im Gesundheits- und Forschungsbereich und ein Pflichtbestandteil des HIPAA data use agreement [3].

Meldung von Vorfällen. Was als meldepflichtiges Ereignis gilt und wie schnell es gemeldet werden muss, von der empfangenden an die offenlegende Seite und weiter an eine etwaige Aufsichtsbehörde.

Weitergabe an Dritte. Diese Klausel ist für US-Unternehmen, die Daten über Grenzen hinweg teilen, tragend geworden. Die Regelung des Department of Justice zur Umsetzung der Executive Order 14117, in Kraft seit dem 8. April 2025, untersagt es einer US-Person, wissentlich Data Brokerage zu betreiben, die einer ausländischen Person Zugang zu Government-Related Data oder zu Bulk US Sensitive Personal Data verschafft, sofern die US-Person diese ausländische Person nicht vertraglich verpflichtet, dieselben Daten nicht per Data Brokerage an ein Country of Concern oder eine Covered Person weiterzugeben, und jeden bekannten oder vermuteten Verstoß gegen diese vertragliche Vorgabe innerhalb von 14 Tagen meldet [8]. Countries of Concern sind China einschließlich Hongkong und Macau, Kuba, Iran, Nordkorea, Russland und Venezuela [8].

Rechte betroffener Personen. Wer Auskunfts-, Widerspruchs-, Berichtigungs- und Löschersuchen bearbeitet und wer die zentrale Ansprechstelle ist. Der ICO Code stellt ausdrücklich klar, dass alle Verantwortlichen für die Einhaltung verantwortlich bleiben, auch wenn die Vereinbarung Aufgaben zuweist, und dass die Vereinbarung benennen sollte, wer die Gesamtverantwortung dafür trägt, einer Person den Zugang zu allen ihren geteilten Daten zu ermöglichen [2].

Aufbewahrung, Rückgabe und Vernichtung. Wie lange die empfangende Seite die Daten halten darf und welcher Nachweis der Vernichtung verlangt wird. Die Studies Exception von FERPA macht die Vernichtung zur Bedingung der Offenlegung und nicht zur Gefälligkeit [6].

Audit- und Abhilferechte. Das Gesetz in California verlangt, dass das offenlegende Unternehmen Rechte behält, angemessene und geeignete Schritte zu unternehmen, um eine vereinbarungskonforme Nutzung sicherzustellen, und nach Mitteilung unbefugte Nutzung zu unterbinden und abzustellen [7]. Nach der Regelung des United States Department of Justice (DOJ) muss eine US-Person, die Restricted Transactions durchführt, für jedes Kalenderjahr, in dem sie solche Transaktionen durchführt, einmal ein unabhängiges Audit durchführen lassen, das die vorangegangenen 12 Monate abdeckt [8].

Laufzeit, Kündigung und Fortgeltung. Welche Pflichten die Vereinbarung überdauern. Vertraulichkeit, Nichtreidentifizierung und Vernichtungspflichten tun das normalerweise.

Wichtige Termine und Ereignisse im Lebenszyklus

Data Sharing Agreements scheitern leise, denn das meiste, was schiefgeht, ist ein Termin, den niemand im Blick hatte. Die Termine, die sich vom ersten Tag an zu erfassen lohnen:

EreignisWarum es zählt
Inkrafttreten und LaufzeitLegt fest, wann die zulässige Nutzung beginnt und endet
Ablauf der zugrunde liegenden GenehmigungEine IRB-Genehmigung, eine Einwilligung oder eine Förderperiode kann vor dem Vertrag enden
Zeitplan für Datenaktualisierungen oder FeedsEine ungeplante zusätzliche Übermittlung ist eine unbefugte
Frist für Vernichtung oder RückgabeMeist an das Projektende gekoppelt, nicht an das Vertragsende
Meldefrist bei VorfällenDie Regelung des DOJ setzt 14 Tage für die Meldung eines vermuteten Verstoßes bei der Weitergabe an Dritte [8]
Jährliches AuditNach der Regelung des United States Department of Justice (DOJ) für jedes Kalenderjahr mit Restricted Transactions erforderlich [8]
ÜberprüfungsterminKeine gesetzliche Frist, aber das Einzige, was das Dokument aktuell hält

Der Überprüfungstermin verdient eine eigene Zeile. Der ICO Code hält fest, dass Vereinbarungen regelmäßig überprüft werden sollten und insbesondere dann, wenn sich die Umstände oder die Begründung für die Weitergabe ändern, dass die Vereinbarung an jede Änderung angepasst werden sollte und dass eine erhebliche Beschwerde oder eine Sicherheitsverletzung für sich genommen eine Überprüfung auslösen sollte [2]. Die Aufnahme einer weiteren Organisation ist ein zusätzlicher Auslöser, und das ICO empfiehlt, dass die Vereinbarung Verfahren für die Aufnahme zusätzlicher Organisationen und für den Ausschluss einer Organisation enthält [2].

Risiken und häufige Fehler

Das falsche Instrument wählen. Eine Auftragsverarbeitungskonstellation im Gewand eines Data Sharing Agreements erhält den falschen Klauselsatz. Wenn die andere Seite ausschließlich nach Ihren dokumentierten Weisungen handelt, brauchen Sie einen Verarbeitungsvertrag und keine Sharing-Vereinbarung. Zu dieser Seite der Grenze siehe Was ist ein Data Processing Agreement (DPA)?.

Annehmen, de-identifizierte Daten fielen aus dem Anwendungsbereich. Oft tun sie das nicht. Die Regelung des DOJ definiert Bulk US Sensitive Personal Data als Daten, die ihre Schwellenwerte erreichen, „unabhängig davon, ob die Daten anonymisiert, pseudonymisiert, de-identifiziert oder verschlüsselt sind", und die Schwellenwerte liegen niedriger, als die meisten erwarten: mehr als 100 US-Personen bei humangenomischen Daten, mehr als 1.000 US-Personen bei anderen humanen Omics-Daten oder biometrischen Identifikatoren, mehr als 1.000 US-Geräte bei präzisen Standortdaten, mehr als 10.000 US-Personen bei personenbezogenen Gesundheits- oder Finanzdaten und mehr als 100.000 US-Personen bei Covered Personal Identifiers [8].

Annehmen, ein definierter Begriff bedeute das, wonach er klingt. Nach kalifornischem Recht ist „share" kein allgemeines Wort. Es meint die Offenlegung personenbezogener Informationen gegenüber einem Dritten zum Zweck kontextübergreifender verhaltensbasierter Werbung, und „sell" ist der weitere Begriff, der die Offenlegung gegen Geld oder einen anderen geldwerten Vorteil erfasst [7]. Eine interne Richtlinie mit dem Satz „Wir teilen keine Daten" beschreibt womöglich etwas Engeres, als die Lesenden vermuten.

Eine offene Zweckklausel. „Für geschäftliche Zwecke" gibt der empfangenden Seite alles und Ihnen nichts, was sich durchsetzen ließe.

Kein Flow-down. Ist der Subunternehmer der empfangenden Seite nicht gebunden, enden die Beschränkungen nach der ersten Station.

Kein Nachweis der Vernichtung. Eine Vernichtungspflicht ohne Zertifikat und ohne Frist ist eine Pflicht, die niemand erfüllt.

Einmal unterzeichnen und ablegen. Der mit Abstand häufigste Fehler. Die Vereinbarung wird unterschrieben, die Daten fließen, und drei Jahre später kann niemand die aktuell zulässigen Nutzungen, das Vernichtungsdatum oder die zuständige Person benennen.

Keine benannte verantwortliche Person. Wenn diejenige Person, die die Vereinbarung verhandelt hat, das Unternehmen verlässt, läuft die Konstellation weiter, ohne dass jemand dafür einsteht.

Checkliste für das Vertragsmanagement

Wenn die Vereinbarung unterzeichnet ist

  1. Erfassen Sie die beiden juristischen Personen exakt so, wie unterzeichnet wurde, dazu die unterzeichnende Person und die intern verantwortliche Person auf Ihrer Seite.
  2. Erfassen Sie die Datenspezifikation als strukturierte Metadaten und nicht als Satz in einem PDF, damit Sie die Frage „Was haben wir übermittelt?" beantworten können, ohne das Dokument erneut zu öffnen.
  3. Halten Sie die zulässigen Zwecke wörtlich in einem Feld fest, das sich in zehn Sekunden lesen lässt.
  4. Dokumentieren Sie den Sicherheitsstandard, auf den die Vereinbarung beide Seiten verpflichtet, und prüfen Sie, ob er dem entspricht, was Ihre Systeme tatsächlich leisten.
  5. Vermerken Sie, ob Flow-down-Klauseln für Beauftragte und Subunternehmer vorhanden sind, und listen Sie bereits bekannte nachgelagerte Empfänger auf.

Termine setzen, bevor Sie sie brauchen

  1. Setzen Sie das Ende der Laufzeit, die Frist für Vernichtung oder Rückgabe und jede Kündigungsfrist als getrennte Erinnerungen an, jeweils mit Vorlauf statt auf den Stichtag.
  2. Nehmen Sie den Ablauf all dessen in den Kalender, wovon die Weitergabe abhängt: IRB-Genehmigung, Einwilligung, Förderperiode, Lizenz oder Förderzusage.
  3. Nehmen Sie das jährliche Audit in den Kalender, wenn die Konstellation Restricted Transactions nach der Regelung des DOJ umfasst [8].
  4. Legen Sie einen festen Überprüfungstermin fest und ergänzen Sie Ihren Vorfallsprozess um Überprüfungsauslöser, damit eine Sicherheitsverletzung oder eine erhebliche Beschwerde die Vereinbarung wieder auf den Tisch bringt [2].

Regelmäßig überprüfen

  1. Gleichen Sie einmal jährlich die tatsächlich fließenden Daten mit der Spezifikation in der Vereinbarung ab. Feeds wachsen um Felder.
  2. Prüfen Sie die Empfängerliste erneut. Neue verbundene Unternehmen, Zukäufe und Support-Teams im Ausland verändern den Zugriff, ohne dass jemand den Vertrag ändert.
  3. Bestätigen Sie, dass jede beendete Konstellation tatsächlich zu Vernichtung oder Rückgabe geführt hat und dass Ihnen der Nachweis vorliegt.
  4. Ändern Sie schriftlich, wenn sich Zweck, Datensätze oder Parteien ändern, und legen Sie den Nachtrag zur Akte, statt ihn per E-Mail zu verschicken.
  5. Übertragen Sie die interne Verantwortung neu, sobald die bisher zuständige Person die Rolle wechselt, und prüfen Sie, dass keine Vereinbarung ohne verantwortliche Person bleibt.

Das meiste davon ist Nachhalten, und genau dieser Teil verfällt zuerst. Contracko ist KI-gestützte Vertragsmanagement-Software, die dafür gebaut ist. Die KI-Vertragsanalyse liest eine hochgeladene Vereinbarung und zeigt die wichtigen Termine, ungünstigen Bedingungen und leicht zu übersehenden Probleme auf, das Vertragsarchiv hält das unterzeichnete Dokument, seine Dateien und seine Metadaten an einem Ort durchsuchbar, und Ablauferinnerungen lassen sich mehr als einmal pro Vertrag setzen, der Person zuweisen, die den Datensatz verantwortet, und so einstellen, dass sie sich bei einer Vertragsverlängerung wiederholen. Für die umfassendere Arbeitsroutine siehe Best Practices im Vertragsmanagement, und für den kommerziellen Kontext Preise.

Starten Sie eine kostenlose Testphase mit den Data Sharing Agreements, die Sie bereits haben, und sehen Sie jede Vernichtungsfrist, jeden Überprüfungstermin und jede Zweckklausel in einer Ansicht.

Quellen

[1] European Union, General Data Protection Regulation, Articles 26 and 28 (Vereinbarungen gemeinsam Verantwortlicher und die Pflichtinhalte eines Vertrags mit einem Auftragsverarbeiter). gdpr-info.eu/art-26-gdpr and gdpr-info.eu/art-28-gdpr

[2] UK Information Commissioner's Office, Data sharing: a code of practice, the data sharing agreements chapter (alternative Bezeichnungen, notwendige Inhalte und wann zu überprüfen ist). ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/data-sharing-a-code-of-practice/data-sharing-agreements

[3] HIPAA Privacy Rule, 45 CFR 164.504(e) and 164.514(e) (Verträge mit Business Associates, der Limited Data Set und jeder Pflichtbestandteil eines data use agreement). govinfo.gov/content/pkg/CFR-2023-title45-vol2/xml/CFR-2023-title45-vol2-sec164-514.xml

[4] Centers for Medicare and Medicaid Services Information Security and Privacy Program. Wann CMS ein data use agreement, ein information exchange agreement oder ein computer matching agreement verlangt. security.cms.gov/learn/data-sharing-agreements

[5] National Institutes of Health, NIH Controlled-Access Data Policy and Proposed Revisions to NIH Genomic Data Sharing Policy, 90 FR 59131 (das Data Use Certification Agreement und die Kommentarfrist bis zum 18. März 2026). govinfo.gov/content/pkg/FR-2025-12-18/html/2025-23246.htm

[6] FERPA regulations, 34 CFR 99.31(a)(6) (die Studies Exception und die von ihr verlangte schriftliche Vereinbarung). govinfo.gov/content/pkg/CFR-2023-title34-vol1/xml/CFR-2023-title34-vol1-sec99-31.xml

[7] California Consumer Privacy Act, Cal. Civ. Code 1798.100(d) and 1798.140 (die vorgeschriebenen Vertragsinhalte und die Definitionen von share und sell). leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.100

[8] Department of Justice, 28 CFR part 202, sections 202.205, 202.206, 202.301, 202.302, 202.401, and 202.601 (Bulk-Schwellenwerte, die vertragliche Vorgabe zur Weitergabe an Dritte und die Meldung binnen 14 Tagen, das jährliche Audit und die Countries of Concern). govinfo.gov/content/pkg/FR-2025-01-08/html/2024-31486.htm

Die Bilder in diesem Artikel wurden mithilfe von KI erstellt.

Legen Sie mit Contracko los

Nehmen Sie sich den Stress aus dem Vertragsmanagement. Mit Contracko bleiben Sie organisiert, pünktlich und in Kontrolle. Beginnen Sie noch heute mit der Vereinfachung.

ennldefresitptsvpl