XML zu JSON und Datenschutz: DSGVO, SOAP-zu-REST-Migration und Standards

Wer XML in JSON umwandelt, denkt zuerst an Technik, nicht an Recht. Doch sobald die XML-Daten Personen betreffen, etwa Patientendaten in HL7-Nachrichten, Kundendaten in SOAP-Antworten oder Adressen in einem Datenexport, wird die Konvertierung zu einer datenschutzrelevanten Verarbeitung. Die entscheidende Frage lautet dann nicht, ob das Tool gut konvertiert, sondern wo es die Daten verarbeitet. Dieser Ratgeber erklärt, warum eine reine Browser-Verarbeitung unter der DSGVO klar im Vorteil ist, welche konkreten Risiken Upload-Dienste bergen und wie Sie die wichtigsten XML-Standards (SOAP, HL7, RSS) sauber und rechtssicher nach JSON überführen.

Lokal oder Server: Der entscheidende Unterschied für die DSGVO

Bei der XML-zu-JSON-Konvertierung gibt es zwei grundverschiedene Architekturen, und genau dieser Unterschied entscheidet über die datenschutzrechtliche Bewertung. Bei einem clientseitigen Tool läuft die gesamte Umwandlung als JavaScript im Browser des Nutzers. Die XML-Daten werden eingefügt, lokal geparst und in JSON umgewandelt, ohne dass auch nur ein Byte an einen Server gesendet wird. Bei einem serverbasierten Dienst dagegen wird die Datei hochgeladen, auf einem fremden Server verarbeitet und das Ergebnis zurückgeschickt.

Aus Sicht der Datenschutz-Grundverordnung ist das ein fundamentaler Unterschied. Verlassen personenbezogene Daten das Gerät nicht, findet keine Übermittlung an einen Dritten statt. Es gibt dann keinen externen Verantwortlichen und keinen Auftragsverarbeiter, dessen Tätigkeit abgesichert werden müsste. Wandern die Daten dagegen auf einen fremden Server, liegt eine Verarbeitung durch einen Dritten vor, die eine Rechtsgrundlage nach Artikel 6 DSGVO und in aller Regel einen Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO voraussetzt.

Was die DSGVO konkret verlangt

Sobald XML-Daten einen Personenbezug haben, greifen die Grundsätze aus Artikel 5 DSGVO. Besonders relevant sind hier zwei Prinzipien. Die Datenminimierung verlangt, dass nicht mehr Daten verarbeitet werden als nötig, und dass Daten nicht unnötig an Dritte gelangen. Genau dem läuft ein Upload entgegen, der die kompletten Inhalte an einen externen Dienst überträgt, obwohl die Aufgabe vollständig lokal lösbar wäre.

Der zweite Grundsatz ist die Integrität und Vertraulichkeit nach Artikel 5 Absatz 1 Buchstabe f DSGVO, oft als Prinzip von Privacy by Design (Artikel 25 DSGVO) zusammengefasst. Datenschutz soll bereits durch die Technikgestaltung erreicht werden. Ein Werkzeug, das gar keine Daten erst überträgt, erfüllt diesen Grundsatz am wirksamsten: Was technisch nie das Gerät verlässt, kann unterwegs weder abgefangen noch beim Anbieter gespeichert oder kompromittiert werden. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt in seinem IT-Grundschutz konsistent, die Übertragung schützenswerter Daten auf das notwendige Minimum zu beschränken.

Die Risiken von Upload-basierten Online-Convertern

Viele bekannte Online-Converter, darunter auch der im deutschsprachigen Raum verbreitete CoolUtils-Dienst, arbeiten serverbasiert: Die Datei wird hochgeladen, dort umgewandelt und mit einem Größenlimit (häufig 50 MB) zurückgegeben. Für unkritische, anonyme Daten ist das unproblematisch. Bei personenbezogenen oder sensiblen Inhalten entstehen jedoch konkrete Risiken, die in der Praxis oft unterschätzt werden.

Das gravierendste Problem ist der Kontrollverlust. Nach dem Upload wissen Sie nicht, ob die Datei geloggt, in einem Cache abgelegt, an Subdienstleister weitergereicht oder in ein Drittland übertragen wird. Liegt der Server in den USA, kommt die gesamte Komplexität des Drittlandtransfers nach Kapitel V DSGVO hinzu. Bei sensiblen Daten kann bereits der ungesicherte Upload eine meldepflichtige Verletzung des Schutzes personenbezogener Daten nach Artikel 33 DSGVO darstellen.

SOAP zu REST: Warum die Migration nach JSON heute Standard ist

Ein klassischer Anwendungsfall der XML-zu-JSON-Umwandlung ist die Modernisierung alter Schnittstellen. SOAP (Simple Object Access Protocol) war über Jahre der Standard für Webservices und ist bis heute in Behörden, Banken und Versicherungen weit verbreitet. SOAP-Nachrichten sind reines XML: Sie bestehen aus einem Envelope mit Header und Body und nutzen Namespaces wie soap: oder xsi:. Moderne Schnittstellen setzen dagegen fast durchgehend auf REST mit JSON, weil JSON kompakter, in JavaScript nativ verarbeitbar und für mobile Clients sparsamer ist.

Bei der Migration von SOAP zu REST entsteht regelmäßig die Aufgabe, bestehende SOAP-Antworten in JSON zu überführen, etwa um sie in einem neuen Frontend zu nutzen oder in Tests zu vergleichen. Ein einfaches Beispiel zeigt, wie aus einer SOAP-Antwort gültiges JSON wird:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <getKundeResponse>
      <kunde id="4711">
        <name>Erika Mustermann</name>
        <plz>25421</plz>
      </kunde>
    </getKundeResponse>
  </soap:Body>
</soap:Envelope>

wird nach den üblichen Mapping-Regeln zu:

{
  "soap:Envelope": {
    "soap:Body": {
      "getKundeResponse": {
        "kunde": {
          "@id": "4711",
          "name": "Erika Mustermann",
          "plz": "25421"
        }
      }
    }
  }
}

Beachten Sie zwei Details, die bei der Migration immer wieder Probleme machen: Das Namespace-Präfix soap: bleibt als reiner Bestandteil des Schlüsselnamens erhalten, weil JSON kein Namespace-Konzept kennt. Und das Attribut id wird mit einem Präfix abgebildet, hier dem verbreiteten @-Zeichen. Wer in der neuen REST-Schnittstelle saubere Schlüssel ohne Präfix möchte, entfernt diese in einem Nachbearbeitungsschritt. Die technischen Mapping-Details vertiefen wir im verwandten Ratgeber zu Attributen und Namespaces.

HL7, RSS und SVG: Sensible Standards richtig einordnen

XML ist die Grundlage zahlreicher Fachstandards, die sich datenschutzrechtlich stark unterscheiden. Die folgende Übersicht ordnet die wichtigsten ein und zeigt, worauf bei der Umwandlung zu achten ist.

Den höchsten Schutzbedarf hat HL7, der internationale Standard für den Austausch medizinischer Daten. HL7-Nachrichten und CDA-Dokumente enthalten Diagnosen, Medikationen und Patientennamen, also Gesundheitsdaten nach Artikel 9 DSGVO, deren Verarbeitung grundsätzlich verboten ist und nur unter engen Ausnahmen erlaubt wird. Für die Umwandlung solcher Daten verbietet sich jeder Upload an einen unkontrollierten Dienst. RSS- und Atom-Feeds dagegen sind per Definition zur Veröffentlichung bestimmt und damit datenschutzrechtlich meist unkritisch.

Praxis-Empfehlung: Eine einfache Entscheidungsregel

Sie müssen für jede Konvertierung keine Datenschutzfolgenabschätzung durchführen. In der Praxis genügt eine klare Faustregel: Enthält das XML keinerlei Personenbezug und ist ohnehin öffentlich, etwa ein RSS-Feed oder eine Beispiel-Konfiguration, ist die Wahl des Tools datenschutzrechtlich zweitrangig. Sobald aber auch nur die Möglichkeit besteht, dass Namen, Kennnummern, Adressen, Vertrags- oder Gesundheitsdaten enthalten sind, gilt: nur lokal verarbeiten.

Ein clientseitiges Tool ist hier nicht nur die rechtssichere, sondern auch die einfachere Wahl. Sie sparen sich die Prüfung von Serverstandort, Auftragsverarbeitungsvertrag und Drittlandtransfer komplett, weil keiner dieser Punkte überhaupt entsteht. Genau diesen Ansatz verfolgt unser Konverter: Die gesamte Umwandlung läuft als JavaScript in Ihrem Browser, ohne Upload, ohne Anmeldung und ohne Speicherung.

Häufige Fragen zu XML, JSON und Datenschutz