C5-Themengebiet PI: Schnittstellen, Datenexport und Löschung prüffähig regeln

Diese Seite behandelt das Themengebiet PI (Portabilität und Interoperabilität) des C5:2026, Abschnitt 5.10 des Katalogs. Wie Kriterien und Unterkriterien grundsätzlich aufgebaut sind, erklärt die Seite C5-Kriterienkatalog.

Worum geht es im Themengebiet PI?

PI beantwortet drei Fragen, die Kunden vor einer Beschaffung stellen: Wie binde ich den Dienst an meine Systeme an? Bekomme ich meine Daten wieder, wenn ich gehe? Und was passiert danach mit ihnen beim Anbieter? Der Katalog fasst das in seiner Zielsetzung zusammen: den Dienst über andere Cloud-Dienste oder IT-Systeme der Kunden ansprechen zu können, die gespeicherten Kundendaten bei Beendigung des Auftragsverhältnisses zu beziehen und sie beim Anbieter sicher zu löschen (Abschnitt 5.10).

Das Gebiet umfasst drei Kriterien, PI-01 bis PI-03, mit 6 Basis-Unterkriterien und 5 erweiternden Zusatz-Unterkriterien; verschärfende gibt es nicht. Alle drei Kriterien gab es mit gleicher Nummer schon in C5:2020. Nach der Änderungshistorie des BSI ist die Pflicht, Schnittstellen zu dokumentieren, in das Gebiet PSS gewandert (PSS-01); PI-01 behandelt jetzt die Umsetzung der Schnittstellen. PI-03 lässt neu Ausnahmen von der Löschung zu, wenn eine gerichtliche Anordnung sie verlangt oder bekannte künftige finanzielle und rechtliche Pflichten die Daten noch erfordern.

Der Katalog verlangt keine neue Technik nur für die Portabilität: Der Anbieter muss nach den ergänzenden Informationen zu PI-01 weder neue Technologien entwickeln noch Informationen weitergeben, die als geistiges Eigentum oder Geschäftsgeheimnis geschützt sind.

Ausgangssituation: ein SaaS-Anbieter, dessen Kunden wechseln wollen

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt eine Software für Zeiterfassung und Projektabrechnung für Ingenieur- und Architekturbüros. Der Dienst läuft auf der Infrastruktur eines großen Cloud-Anbieters, mit verwalteter Datenbank, Objektspeicher für Belege und Pläne und einem Suchindex. Die Büros binden ihre Buchhaltung über eine REST-Schnittstelle an. Ein großer Kunde verlangt für die Vertragsverlängerung einen C5-Bericht und fragt im Fragebogen, wie er seine Daten bei Vertragsende zurückbekommt.

So sieht es vor dem Projekt aus:

• Die REST-Schnittstelle ist dokumentiert, die Buchungssätze lassen sich als CSV exportieren. Für Belege, Pläne und das Änderungsprotokoll gibt es keinen Export; Kunden müssen beim Support anfragen.
• Die Vertragsbedingungen sagen: „Nach Vertragsende werden die Daten gelöscht.“ Eine Frist für die Herausgabe, ein Löschzeitpunkt und die Mitwirkung der Kunden fehlen.
• Gelöscht wird ein Mandant mit einem Skript, das ein Entwickler bei Bedarf startet. Datensicherungen laufen nach ihrer Aufbewahrungszeit von selbst aus; ob der Suchindex mitgelöscht wird, weiß niemand genau.
• Einen Löschnachweis bekommt der Kunde nicht.

Keiner dieser Punkte fällt im laufenden Betrieb auf. Sie zeigen sich erst, wenn ein Kunde kündigt, und genau diesen Fall will der Prüfer belegt sehen.

Wer ist wofür verantwortlich: Anbieter, Plattform, Kunde?

Bei SaaS liegt PI zum größten Teil beim Anbieter: Der Kunde ist auf die Exportfunktionen angewiesen, die der Dienst bietet. Bei IaaS- und PaaS-ähnlichen Diensten ist es nach den ergänzenden Informationen zu PI-02 umgekehrt, dort extrahiert und sichert der Kunde seine Daten grundsätzlich selbst. Die Plattform ist im Beispiel ein Subdienstleister (Subservice-Organisation). Unsere Einordnung für das Beispiel:

Alle drei PI-Kriterien enthalten korrespondierende Kriterien für Kunden. Welche Kundenkontrollen Sie für Ihren Dienst voraussetzen, etwa dass der Kunde seine Daten innerhalb der Frist abruft, gehört als korrespondierende Kundenkontrollen (CUEC) in die Systembeschreibung. Der Prüfer prüft sie nicht beim Kunden, nur ob sie sachgerecht dargestellt sind.

Was muss im Vertrag zur Datenherausgabe stehen?

PI-02.01B verlangt, dass die vertraglichen Vereinbarungen die Bereitstellung der Kundendaten nach Vertragsende regeln, soweit die Punkte auf den Dienst anwendbar sind. Fehlt ein anwendbarer Punkt im Vertrag, ist das Kriterium nach den ergänzenden Informationen nicht erfüllt, und der Prüfer hält eine Abweichung fest. Den genauen Wortlaut der sieben Aspekte lesen Sie im Katalog. Für das Beispiel haben wir daraus Leitfragen und eigene Beispielregeln abgeleitet:

Die Fristen sind Beispielwerte, keine Katalogvorgaben; der Katalog legt keine bestimmte Dauer fest. Er nennt als mögliche rechtliche Anforderungen den EU Data Act und für Deutschland Aufbewahrungspflichten aus § 147 AO und § 257 HGB. Welche davon für Ihren Dienst und Ihre Verträge gelten, ist im Einzelfall rechtlich zu prüfen. Wer das erweiternde Unterkriterium PI-02.01AC aufnimmt, prüft diese Anforderungen mindestens einmal im Jahr und passt die Verträge an; mit PI-02.02AC gibt der Anbieter zusätzlich abgeleitete Cloud-Dienstdaten heraus, etwa Nutzungsprotokolle.

Beispiel-Kontrollbeschreibung zu PI-03

PI-03 verlangt drei Dinge: Die Löschung von Kundendaten, abgeleiteten Cloud-Dienstdaten und Kontodaten bei Vertragsende hält die vertraglichen Vereinbarungen ein (PI-03.01B), sie verhindert eine Wiederherstellung mit forensischen Mitteln nach dem Stand der Technik (PI-03.02B), und sie wird so dokumentiert, dass der Kunde einen Nachweis erhält (PI-03.03B). Als geeignete Methoden nennt der Katalog etwa mehrfaches Überschreiben oder die Löschung des Verschlüsselungsschlüssels. Unsere Beispiel-Kontrolle für den Anbieter oben (eigene Formulierung, kein Katalogtext):

Die Löschung über den Schlüssel ist unsere Empfehlung für Datensicherungen, die sich nicht einzeln bearbeiten lassen; sie setzt voraus, dass jeder Mandant einen eigenen Schlüssel hat. Wie Sie Schlüssel verwalten, behandelt das Gebiet CRY. Ob die Kontrolle alle Unterkriterien abdeckt, beurteilt der Prüfer.

Welche Nachweise der Prüfer sehen will

Für PI kommen die Nachweise aus Vertrag, Schnittstellendokumentation und den Fällen beendeter Verträge. Endet im Prüfungszeitraum kein Vertrag, gibt es keinen echten Löschfall; klären Sie dann früh mit dem Prüfer, wie Sie das Verfahren belegen. Beispiele aus unserem Szenario:

Ein Nachweisregister hält fest, welcher Nachweis zu welchem Unterkriterium gehört; wie Sie es führen, zeigt die Seite Nachweise und Dokumentation.

Mögliche Lücken: Ursache, Wirkung, Abhilfe

Die folgenden Lücken ergeben sich aus dem Wortlaut der Kriterien und dem Szenario oben. Ist ein einziges Unterkriterium nicht erfüllt, gilt das Kriterium als nicht erfüllt, und der Prüfer berichtet die Abweichung (Abschnitte 3.4.12 und 3.4.13).

Welche Lücken zuerst zu schließen sind, entscheidet die Maßnahmenplanung über alle Gebiete hinweg. Vertragsänderungen brauchen Vorlauf; planen Sie sie vor Beginn eines Typ-2-Zeitraums ein.

Alle Kriterien des Themengebiets PI

Titel nach der deutschen Fassung 1.1.0, Zählung der Unterkriterien nach Abschnitt 5 (B = Basis, AS = verschärfend, AC = erweiternd). Die Spalte „Worum es geht“ ist unsere eigene Kurzbeschreibung, kein Katalogtext; verbindlich ist der Wortlaut der Kriterien im Katalog.

Die erweiternden Unterkriterien von PI-01 betreffen Kundenanforderungen, die im Vertrieb auftauchen können: eine Anwendungs-Firewall vor Administrationsschnittstellen, die aus öffentlichen Netzen erreichbar sind (PI-01.01AC), und die Anbindung eigener Identitätsanbieter der Kunden über ein standardisiertes Protokoll mit klarer Dokumentation (PI-01.02AC, PI-01.03AC). Welche Sie aufnehmen, richtet sich nach Ihren Kunden.

Bezug zu ISO/IEC 27001:2022 Anhang A

Die folgende Zuordnung ist unsere eigene, nicht amtliche Einordnung nach Thema. Das BSI hat für C5:2026 noch keine Kreuzreferenz veröffentlicht, und auch eine amtliche Tabelle zeigt nach dem Katalog nur thematische Nähe, keine Erfüllung (Abschnitt 3.3). Die Kurzbezeichnungen sind unsere, keine Titel aus der Norm.