Schutz vor Drittlandzugriff und IoT-Datenzugang unter dem Data Act

Problem in der Praxis

In vielen Organisationen sind Produktdaten, Telemetrie und Cloud-Datenbestände historisch gewachsen. Oft ist unklar, welche Daten ein vernetztes Produkt erzeugt, wo sie liegen, wer sie verarbeitet und welche Unterauftragnehmer in Drittländern beteiligt sind. Solange niemand Zugang verlangt und keine Behörde anfragt, fällt das nicht auf.

Der Data Act macht diese Unklarheit zum Risiko. Verlangt ein Nutzer Zugang oder die Weitergabe an einen Dritten, muss das Unternehmen liefern, ohne Geschäftsgeheimnisse, Sicherheit oder personenbezogene Daten zu gefährden. Verlangt eine Drittlandbehörde Herausgabe oder Übermittlung nicht-personenbezogener Daten, muss der Dienst angemessene Schutzmaßnahmen belegen können. Beide Szenarien treffen unvorbereitet, wenn Datenflusslandkarten fehlen, Cloud-Verträge keine Klauseln enthalten und kein Reaktionsweg für Drittlandanfragen definiert ist.

CISO-Einordnung

Das Thema zerfällt in drei Fähigkeiten.

• IoT-Datenzugang: Die Verordnung verfolgt einen Access-by-design-Ansatz. Nutzer sollen Zugang zu den bei der Produktnutzung anfallenden Daten erhalten; auf ihren Wunsch ist auch an Dritte weiterzugeben. Die Bereitstellung erfolgt zu fairen, angemessenen und nichtdiskriminierenden Bedingungen, und der Schutz von Geschäftsgeheimnissen bleibt zu wahren.
• Schutz vor Drittlandzugriff (Art. 32): Anbieter von Datenverarbeitungsdiensten müssen alle angemessenen technischen, organisatorischen und rechtlichen, einschließlich vertraglicher, Maßnahmen treffen, um einen behördlichen Zugriff oder eine Übermittlung nicht-personenbezogener Daten aus einem Drittland zu verhindern, der gegen Unionsrecht oder das Recht eines Mitgliedstaats verstößt. Das ist das Pendant zur Drittlandlogik der DSGVO, hier für nicht-personenbezogene Daten.
• Interoperabilität (Art. 33 ff.): Anforderungen an die Interoperabilität von Daten und Datenräumen sowie an Smart Contracts. Praktisch heißt das strukturierte, gängige und maschinenlesbare Formate sowie offene Schnittstellen, damit Zugang und Weitergabe sicher umsetzbar sind.

Die drei Fähigkeiten hängen zusammen: Ohne saubere Datenflusskenntnis ist weder kontrollierter Zugang noch belastbare Abschirmung möglich.

Umsetzungsperspektive

Sinnvoll ist ein schlanker, betreibbarer Kern statt einer Einzelmaßnahmensammlung:

• Datenflusslandkarte für Produkt- und Dienstdaten: Welche Daten entstehen, wo liegen sie, wer verarbeitet sie, welche Drittlandbeteiligung gibt es?
• Datenklassifizierung mit klarer Markierung von Geschäftsgeheimnissen und personenbezogenen Anteilen.
• Zugangs- und Weitergabeprozess für Nutzer- und Drittanfragen mit Identitäts- und Berechtigungsprüfung sowie Protokollierung.
• Reaktionsverfahren für behördliche Drittlandanfragen: Wer prüft die Rechtmäßigkeit, wer entscheidet, welche Eskalation gilt.
• Vertraglicher Durchgriff auf Cloud- und Edge-Anbieter samt Unterauftragnehmern, inklusive Standortwahl, Verschlüsselung und Schlüsselhoheit.

Da Art. 32 ausdrücklich vertragliche Maßnahmen nennt, sollte der CISO Lieferantenverträge als Steuerungshebel begreifen und die Anforderungen in Beschaffung und Vertragsmanagement verankern, statt sie rein technisch zu behandeln.

Typische Fehler

1. Der Drittlandschutz nach Art. 32 wird mit der DSGVO verwechselt und nur für personenbezogene Daten gedacht, obwohl Art. 32 gerade nicht-personenbezogene Daten adressiert.
2. IoT-Datenzugang wird als reines Rechtsthema behandelt, ohne sichere Schnittstellen und Datenklassifizierung.
3. Geschäftsgeheimnisse werden bei Zugangsanfragen ungeschützt mitgeliefert oder als pauschale Verweigerungsbegründung missbraucht.
4. Es gibt kein vorbereitetes Verfahren für behördliche Drittlandanfragen, sodass im Ernstfall ad hoc entschieden wird.
5. Cloud-Verträge werden nicht angepasst, obwohl Art. 32 vertragliche Maßnahmen verlangt.

Risiken und Trade-offs

Der Grundkonflikt liegt zwischen Offenheit und Schutz. Wer Datenzugang großzügig automatisiert, riskiert die Preisgabe von Geschäftsgeheimnissen und schafft Angriffsfläche; wer zu restriktiv agiert, verletzt Zugangsrechte. Architektonisch erhöhen strenge Datenlokalisierung und Schlüsselhoheit den Schutz gegen Drittlandzugriffe, steigern aber Kosten und Komplexität.

Schließlich besteht ein Rechtskonflikt: Eine Drittlandbehörde kann Druck ausüben, während Unions- oder mitgliedstaatliches Recht die Übermittlung untersagt. Der CISO kann das nicht auflösen, aber durch Vorbereitung, Dokumentation und Eskalationswege beherrschbar machen. Konkrete Rechtsfragen gehören in die Rechtsfunktion; dieser Beitrag ersetzt keine Rechtsberatung.

Entscheidungspunkte

• Welche Datenbestände sind nicht-personenbezogen und fallen unter Art. 32, und wo liegen die Übergänge zu personenbezogenen Daten?
• Wie tief reicht der vertragliche Durchgriff auf Cloud-Anbieter und Unterauftragnehmer, und welche Standort- und Schlüsselanforderungen werden Pflicht?
• Wer entscheidet bei einer behördlichen Drittlandanfrage, und in welcher Frist?
• Welche IoT-Datenzugangsanfragen werden automatisiert, welche manuell geprüft?
• Welche Interoperabilitäts- und Formatstandards werden gesetzt, damit Zugang sicher und einheitlich erfolgt?

Praktische Empfehlungen

1. Erstellen Sie zuerst eine Datenflusslandkarte für Produkt- und Dienstdaten inklusive Drittlandbeteiligung.
2. Klassifizieren Sie Daten und markieren Sie Geschäftsgeheimnisse explizit, damit Zugangsanfragen präzise beantwortet werden.
3. Verankern Sie die Anforderungen des Art. 32 vertraglich in Cloud- und Edge-Verträgen, inklusive Standort, Verschlüsselung und Schlüsselhoheit.
4. Definieren Sie ein vorbereitetes Reaktionsverfahren für behördliche Drittlandanfragen mit klaren Rollen und Eskalation.
5. Bauen Sie sichere, interoperable Schnittstellen mit strukturierten, maschinenlesbaren Formaten und dokumentieren Sie die getroffenen Maßnahmen nachweisbar.

Relevante Normreferenzen

• Verordnung (EU) 2023/2854 (Data Act): zentrale Rechtsgrundlage; Art. 3 ff. zu IoT-Datenzugang, Art. 32 zum Schutz vor unrechtmäßigem behördlichem Drittlandzugriff auf nicht-personenbezogene Daten, Art. 33 ff. zu Interoperabilität. Erlassen am 13.12.2023, in Kraft seit 11.01.2024, anwendbar seit 12.09.2025. Der IoT-Datenzugang nach Art. 3 Abs. 1 gilt für vernetzte Produkte, die nach dem 12.09.2026 in Verkehr gebracht werden; weitere Detailfristen der Übergangsregelungen sind anhand des Verordnungstexts zu prüfen.
• DADG (Datenverordnung-Anwendungs- und Durchsetzungs-Gesetz): deutsches Durchführungsrecht. Die Bundesnetzagentur ist zentrale zuständige Behörde für den Data Act (horizontale Zuweisung nach Art. 37, nicht die sektorale KRITIS-Aufsicht). Exaktes Verkündungsdatum und BGBl.-Fundstelle, Detailfristen, der konkrete Bußgeldrahmen sowie die genaue Abgrenzung und Zusammenarbeit mit dem BfDI bei personenbezogenen Anteilen sind anhand der Primärquellen zu prüfen.
• ISO/IEC 27001:2022: nur als Referenz für die Operationalisierung über ein ISMS (z. B. Lieferanten- und Vertragsmanagement, Zugriffskontrolle, Kryptografie, sichere Datenübertragung). Keine Zertifizierung des Data Act über ISO 27001; kein Volltext und keine Control-Liste.