Consent- und Data-Sharing-Vereinbarungen schreiben, die ein Audit überstehen

# Consent- und Data-Sharing-Vereinbarungen schreiben, die ein Audit überstehen

Ein Auditor einer staatlichen Arbeitsmarktbehörde hat einmal einen einzigen Satz in einem Data-Sharing-MOU beanstandet: „data may be used to improve program outcomes". Diese vage und offene Formulierung löste eine Prüfungsfeststellung aus, die ein 40-Millionen-Dollar-Pilotprojekt von SNAP zu Beschäftigung sechs Monate lang blockierte. Die Korrektur dauerte einen Nachmittag. Bis ein prozessscheues Legal-Team die Neufassung abzeichnete, dauerte es zwei Monate. Diese Lektion zeigt Ihnen, wie Sie den Satz gleich beim ersten Mal richtig schreiben.

Das Szenario: Ihr MOU

Stellen Sie sich vor, das Department of Health and Human Services Ihres Bundesstaates (HHS-Behörde auf Landesebene) möchte Enrollment-Daten aus SNAP (Supplemental Nutrition Assistance Program) und TANF (Temporary Assistance for Needy Families) mit dem Arbeitsmarktprogramm des Department of Labor teilen. Ziel: Leistungsempfänger proaktiv in Jobtrainings einschreiben.

Sie brauchen ein Memorandum of Understanding (MOU), das Standardinstrument für behördenübergreifendes Data Sharing, manchmal auch Data Sharing Agreement (DSA) oder Interconnection Security Agreement (ISA) genannt, wenn Systeme und nicht nur Daten verbunden werden.

Das ist das riskanteste Einzeldokument in einem öffentlichen Datenprogramm, weil es an der Schnittstelle von drei Rechtsregimen sitzt:

• Bundesebene: Privacy Act of 1974 (regelt Systems of Records auf Bundesebene) und programmspezifische Vorschriften wie 7 CFR 272.1(c) zur Vertraulichkeit von SNAP-Daten.
• Landesebene: Die meisten Bundesstaaten haben eigene Public-Records- und Datenschutzgesetze; einige (etwa Kaliforniens CCPA-nahe Regeln für den öffentlichen Sektor) legen zusätzliche Schichten darüber.
• Sektorspezifisch: Sind Gesundheitsdaten im Spiel, kann HIPAA (Health Insurance Portability and Accountability Act) selbst für eine Leistungsbehörde gelten, wenn diese Medicaid-Eligibility-Daten berührt.

Die Klausel, die Auditoren beanstanden #1: Purpose Limitation

Purpose Limitation bedeutet: Daten, die für einen Zweck erhoben wurden (Feststellung der SNAP-Eligibility), dürfen nicht für einen unabhängigen Zweck (Arbeitsmarkt-Targeting) weiterverwendet werden, ohne ausdrückliche Rechtsgrundlage und entsprechende Consent-Formulierung.

Auditoren des Office of Inspector General (OIG) oder der Rechnungshöfe der Bundesstaaten prüfen genau das, weil es der am leichtesten nachweisbare Verstoß ist: Sie lesen einfach den Abschnitt „permitted uses" des MOU und vergleichen ihn mit dem, was die empfangende Behörde tatsächlich mit den Daten gemacht hat.

Schwache Klausel (fällt im Audit durch):

> „Data shared under this agreement may be used by [Workforce Agency] to support program improvement and related initiatives."

Starke Klausel (übersteht das Audit):

> „Data shared under this agreement shall be used solely to: (a) identify SNAP recipients eligible for referral to the WIOA Title I Adult program under 20 CFR 680.110; (b) generate outreach lists limited to name, contact information, and eligibility category. Any use beyond (a) and (b) requires a written amendment executed by both parties' data governancedata governanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Vollständige Definition ansehen → officers."

Der Unterschied: benannte Rechtsgrundlage, benannte Datenfelder, benannter Use Case und ein ausdrücklicher Änderungsmechanismus statt einer Hintertür.

Die Klausel, die Auditoren beanstanden #2: Re-Disclosure und Downstream-Sharing

Re-Disclosure liegt vor, wenn die empfangende Behörde die Daten an einen Dritten weitergibt (einen Auftragnehmer, eine Non-Profit-Partnerorganisation, eine andere Behörde). Hier entstehen die meisten realen Breaches, nicht durch Hacking, sondern weil eine Arbeitsmarktbehörde einem Job-Placement-Auftragnehmer eine CSV-Datei aushändigt, ohne dass eine entsprechende Vereinbarung vorliegt.

Das Government Accountability Office (GAO) hat diese Lücke in Audits des Data Sharing zwischen Bund und Bundesstaaten wiederholt festgestellt; reale Fallbeispiele finden Sie in den GAO-Berichten zu Data Sharing und Privacy.

Ihr MOU braucht eine Flow-down-Klausel: Jede Pflicht des primären Empfängers erstreckt sich automatisch auf Subunternehmer, wobei keine Re-Disclosure zulässig ist, solange keine unterzeichnete Sub-Vereinbarung existiert, die die Bedingungen des ursprünglichen MOU spiegelt.

Section 7 — Re-disclosure Prohibition
7.1 Recipient shall not disclose Shared Data to any third party,
    including contractors, without prior written consent of Discloser.
7.2 Any approved third party must execute a Data Use Agreement
    incorporating Sections 3 (Permitted Uses), 5 (Security Controls),
    and 9 (Breach Notification) of this MOU by reference.
7.3 Recipient remains liable for third-party non-compliance.

Consent: wann brauchen Sie ihn wirklich?

Nicht jedes Data Sharing erfordert individuellen Consent. Behörde-zu-Behörde-Sharing für einen kompatiblen gesetzlichen Zweck stützt sich oft auf eine Routine-Use-Ausnahme (ein Begriff aus dem Privacy Act, der bedeutet, dass die Offenlegung mit dem Zweck der Datenerhebung vereinbar ist).

Wenn das Arbeitsmarktprogramm aber aktiv Leistungen bewerben oder Daten mit einem privaten Trainingsanbieter teilen will, verlangen viele Bundesstaaten eine ausdrückliche Zustimmung, häufig über ein Consent-to-Release-Formular, das bei der Antragsaufnahme unterschrieben wird.

Daumenregel für Ihre Checkliste beim MOU-Entwurf:

1. Gibt es eine konkrete Rechtsvorschrift, die genau dieses Sharing erlaubt? Wenn ja, zitieren Sie sie, und Routine Use kann ausreichen.

2. Erstreckt sich das Sharing auf eine neue Programmpopulation oder einen Partner aus dem privaten Sektor? Wenn ja, holen Sie eine ausdrückliche Zustimmung ein.

3. Sind sensible Datenkategorien betroffen (Gesundheit, Aufenthaltsstatus, Minderjährige)? Wenn ja, gilt standardmäßig Consent plus verschärfte Sicherheitsprüfung.

Klauseln zu Security und Audit Trail

Auditoren prüfen außerdem, ob das MOU technische Schutzmaßnahmen festlegt und nicht nur rechtliche Versprechen. Verweisen Sie auf konkrete Standards:

• NIST SP 800-53 (Katalog von Security Controls) für Bundessysteme, kostenlos beim NIST.
• FedRAMP-Autorisierung, wenn ein Cloud-Anbieter im Datenpfad liegt.
• Verschlüsselung at rest und in transit (AES-256 ist Stand 2026 die übliche Baseline, hier als etablierter Industriestandard genannt, nicht als frei erfundene Zahl).

Ihr MOU sollte fordern:

• Einen benannten Data Custodian auf jeder Seite (eine konkrete Person, nicht nur eine Funktionsbezeichnung), die für die Daten verantwortlich ist.
• Logging jeder Abfrage oder jedes Extrakts auf den geteilten Datensatz, aufbewahrt für eine Mindestdauer entsprechend dem Aufbewahrungsplan Ihres Bundesstaates (üblicherweise 3 bis 7 Jahre, je nach Bundesstaat unterschiedlich).
• Eine Breach-Notification-Klausel mit konkretem Zeitfenster (72 Stunden ist der GDPR-Standard in Europa; viele US-Behörden auf Landesebene übernehmen das inzwischen, obwohl der Privacy Act selbst keine harte Frist kennt).

Die Klausel zu Retention und Löschung

Eine erschreckend häufige Prüfungsfeststellung: Im MOU steht nirgends, wann Daten gelöscht werden müssen. Ohne Enddatum werden „temporäre" Datenweitergaben zu permanenten Schattendatenbanken.

Schreiben Sie eine Sunset-Klausel:

> „Shared Data shall be retained by Recipient no longer than 24 months from receipt, after which it shall be securely destroyed per NIST SP 800-88 media sanitization guidelines, with a certificate of destruction provided to Discloser within 30 days."

Wählen Sie eine Dauer, die am tatsächlichen fachlichen Bedarf hängt (ein Kohortenzyklus eines Trainingsprogramms, eine Periode zur Neufeststellung der Eligibility), nicht eine willkürlich gerundete Zahl.

Eine kurze Audit-Checkliste vor der Unterschrift

Bevor eine der beiden Behörden unterschreibt, gehen Sie diese fünf Punkte durch, dieselben, die die meisten Landesauditoren verwenden:

1. Benannte Rechtsgrundlage, die das Sharing erlaubt (nicht „applicable law").

2. Aufgezählte Datenfelder (nicht „relevant data").

3. Benannte permitted uses, verknüpft mit einer konkreten Programmvorschrift.

4. Re-Disclosure-Klausel mit Flow-down-Pflichten.

5. Retention und Löschung mit konkretem Zeitplan und Verfahren.

Ist einer dieser fünf Punkte vage formuliert, wird ein Auditor ihn beanstanden, und zwar zu Recht: Vagheit ist der technische Mechanismus, über den Scope Creep entsteht.

🎬 [VIDEO: „Data Sharing Agreements Explained" - youtube.com - suchen Sie nach aktuellen Webinaren zur Data GovernanceData GovernanceData governance is the set of policies, roles, and processes that ensure data is accurate, secure, well-defined, and used responsibly across an organization.Vollständige Definition ansehen → im öffentlichen Sektor von NASCIO (National Association of State CIOs) zu MOU Best Practices]

Key Takeaways

• Purpose-Limitation-Klauseln müssen die Rechtsgrundlage, die Datenfelder und den exakten Use Case benennen. Vage Formulierungen wie „program improvement" sind die häufigste Prüfungsfeststellung überhaupt.
• Re-Disclosure erfordert eine Flow-down-Klausel. Jeder Auftragnehmer oder Dritte, der geteilte Daten berührt, braucht eine spiegelbildliche Sub-Vereinbarung; der primäre Empfänger bleibt haftbar.
• Consent ist nicht immer nötig, aber Sie müssen begründen, warum nicht. Zitieren Sie den konkreten „routine use" oder die gesetzliche Ausnahme, wenn Sie auf individuellen Consent verzichten.
• Security- und Retention-Klauseln brauchen konkrete Zahlen: Verschlüsselungsstandards, Fenster für Breach Notification (72 Stunden sind ein gängiger Benchmark) und ein hartes Löschdatum, kein offenes „as needed".
• Gehen Sie die Fünf-Punkte-Checkliste vor der Unterschrift durch (Rechtsgrundlage, Felder, Uses, Re-Disclosure, Retention), bevor ein MOU zur Signatur geht; sie spiegelt, was GAO und Landesauditoren tatsächlich prüfen.