C5-Themengebiet INQ: behördliche Auskunfts- und Herausgabeverlangen prüffähig bearbeiten

Diese Seite behandelt das Themengebiet INQ (Umgang mit behördlichen Auskunfts- und Herausgabeverlangen) des C5:2026, Abschnitt 5.16 des Katalogs. Wie Kriterien und Unterkriterien grundsätzlich aufgebaut sind, erklärt die Seite C5-Kriterienkatalog. Diese Seite beschreibt, was der Katalog an Verfahren verlangt; ob eine einzelne Anfrage rechtmäßig ist, beurteilen Ihre Rechtsabteilung oder eine beauftragte Kanzlei.

Worum geht es im Themengebiet INQ?

INQ soll einen angemessenen Umgang mit behördlichen Auskunfts- und Herausgabeverlangen sicherstellen, der Katalog nennt drei Bausteine: juristische Überprüfung, Information der Kunden und Begrenzung des Zugriffs auf oder der Offenlegung von Kundendaten oder abgeleiteten Cloud-Dienstdaten (Zielsetzung in Abschnitt 5.16). In der Suche heißen solche Verlangen auch „Ermittlungsanfragen“ oder „Behördenanfragen“; der Katalog verwendet diese Wörter nicht als Begriff. Gemeint sind etwa Anfragen von Strafverfolgungsbehörden oder Nachrichtendiensten; welche Stellen das sind und auf welcher Grundlage sie handeln, unterscheidet sich nach den Hinweisen zu GC-05 von Land zu Land.

Das Gebiet umfasst vier Kriterien, INQ-01 bis INQ-04, mit 8 Basis-Unterkriterien und 2 erweiternden Zusatz-Unterkriterien. Nach der Änderungshistorie des BSI sind die früheren Kriterien INQ-01 und INQ-03 aus C5:2020 zu INQ-01 zusammengelegt, das frühere INQ-04 heißt jetzt INQ-03. INQ-04 ist neu: Der Anbieter dokumentiert die technischen Verfahren, mit denen er Kundendaten bei solchen Verlangen bereitstellt oder offenlegt, und stellt sie seinen Kunden zur Verfügung.

Eng verwandt ist die Rahmenbedingung GC-05: Dort beschreibt der Anbieter in der Systembeschreibung, wie er solche Anfragen behandelt, und nennt die Zahl der Anfragen und ihre Herkunftsländer, siehe Rahmenbedingungen. INQ sind die Kontrollen, GC-05 ist die Auskunft darüber.

Ausgangssituation: ein SaaS-Anbieter ohne Ablauf für Behördenanfragen

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt ein Hinweisgebersystem als SaaS für Unternehmen und Kommunen: Hinweisgebende melden Verstöße über ein Webformular, auf Wunsch anonym, die Meldestelle des Kunden bearbeitet die Meldungen im Dienst. Der Dienst läuft in einer deutschen Region eines großen Cloud-Anbieters. Die Meldungen sind verschlüsselt gespeichert, die Schlüssel verwaltet der Anbieter.

So sieht es vor dem Projekt aus:

• Eine Staatsanwaltschaft hat im Vorjahr per E-Mail an den Support um die Daten zu einer bestimmten Meldung gebeten. Der Support hat die Geschäftsführung gefragt, die Geschäftsführung einen befreundeten Anwalt.
• Ob und wann der betroffene Kunde informiert wurde, ist nicht dokumentiert.
• Für die Herausgabe hat ein Entwickler einen Datenbankauszug gezogen, der mehr Felder enthielt als angefragt.
• Kunden fragen in Sicherheitsfragebögen, ob der Anbieter Meldungen entschlüsseln kann. Eine abgestimmte Antwort gibt es nicht.

Für die Prüfung braucht der Anbieter einen Ablauf, der jede Anfrage gleich behandelt, auch die, die nicht zu einer Herausgabe führen.

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

INQ liegt beim Anbieter, der Kunde muss die Risiken aber in sein eigenes Risikomanagement aufnehmen. Die Plattform ist im Beispiel ein Subdienstleister (Subservice-Organisation). Unsere Einordnung für das Beispiel:

INQ-01, INQ-02 und INQ-04 enthalten korrespondierende Kriterien für Kunden, INQ-03 nicht. Welche Kundenkontrollen Sie voraussetzen, gehört als korrespondierende Kundenkontrollen (CUEC) in die Systembeschreibung. Der Prüfer prüft sie nicht beim Kunden, nur ob sie sachgerecht dargestellt sind.

Wie sieht ein Ablauf für Behördenanfragen aus?

Den Ablauf schreiben Sie als Arbeitsanweisung, die jede Person kennt, die eine Anfrage erreichen kann: Support, Vertrieb, Geschäftsführung. So könnte er für das Beispiel aussehen (eigener Vorschlag, kein Katalogtext):

Vier-Augen-Prinzip und eigenes Konto sind unsere Empfehlung. Die Pflicht zur unverzüglichen Information nach INQ-02 berührt nach den ergänzenden Informationen keine anderen gesetzlichen oder regulatorischen Anforderungen, die eine frühere Information der Kunden verlangen.

Was gehört in die Offenlegung nach INQ-04?

INQ-04.02B nennt sechs Mindestaspekte, nach denen sich das Dokument für Kunden richtet: den Prozess der Bereitstellung und Offenlegung, die technischen Fähigkeiten und Beschränkungen des Anbieters, die Protokollierung solcher Zugriffe, die Einsichtsmöglichkeiten der Kunden in diese Protokolle, die Methoden je Dienst und die rechtlichen Mittel, die die Information der Kunden einschränken können. Das Kriterium ist nach den ergänzenden Informationen auf Kundendaten beschränkt. Für das Beispiel heißt das vor allem, die Frage aus den Fragebögen ehrlich zu beantworten: Der Anbieter verwaltet die Schlüssel und kann Meldungen deshalb grundsätzlich entschlüsseln. Wer das ändern will, prüft Verfahren mit kundenverwalteten Schlüsseln, siehe CRY; die Offenlegung beschreibt dann den neuen Stand. Das Dokument wird nach SP-01 gepflegt und an den Leitlinien zur Minimierung des Zugriffs auf Kundendaten ausgerichtet (INQ-04.03B).

Beispiel-Kontrollbeschreibung zu INQ-01

INQ-01 ist der Kern des Gebiets: Jedes behördliche Verlangen nach Kundendaten, abgeleiteten Cloud-Dienstdaten und Kontodaten unterliegt einer dokumentierten juristischen Bewertung durch sachverständiges Personal (INQ-01.01B), und Zugriff oder Offenlegung sind nur zulässig, wenn diese Bewertung eine anwendbare und gültige Rechtsgrundlage bestätigt und dass dem Verlangen stattgegeben werden muss (INQ-01.02B). Unsere Beispiel-Kontrolle für den Anbieter oben (eigene Formulierung, kein Katalogtext):

Ob die Kontrolle alle Unterkriterien abdeckt, beurteilt der Prüfer; bei einem Typ-2-Bericht prüft er zusätzlich, ob sie über den ganzen Zeitraum wirksam war.

Welche Nachweise der Prüfer sehen will

Der Katalog legt die Grundgesamtheit für die Prüfung ausdrücklich fest: alle behördlichen Verlangen, die im Zeitraum vollständig bearbeitet wurden, unabhängig davon, ob sie zu einer Offenlegung geführt haben (ergänzende Informationen zu INQ-01.01B). Ein vollständiges Register ist deshalb der wichtigste Nachweis. 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).

Alle Kriterien des Themengebiets INQ

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 beiden erweiternden Unterkriterien gehören zu INQ-03: Der Anbieter überwacht Zugriffe und Tätigkeiten von oder im Namen von Ermittlern (INQ-03.01AC) und behebt dabei festgestellte Abweichungen rechtzeitig (INQ-03.02AC).

Bezug zu ISO/IEC 27001:2022 Anhang A

Für INQ gibt es in ISO/IEC 27001 kein direktes Gegenstück. Die folgende Zuordnung ist unsere eigene, nicht amtliche Einordnung nach Thema; sie zeigt nur, wo ein bestehendes ISMS Anknüpfungspunkte hat. Das BSI hat für C5:2026 noch keine Kreuzreferenz veröffentlicht (Abschnitt 3.3). Die Kurzbezeichnungen sind unsere, keine Titel aus der Norm.