Datenschutz
Wir sehen die Frage. Wir sehen nicht, wer sie gestellt hat.
Diese Seite hat zwei Teile: zuerst, wie das Produkt mit Daten umgeht — der Teil, der für Ihre Auslagerungsprüfung zählt. Danach die Datenschutzerklärung für diese Website.
Teil 1 — Wie das Produkt mit Daten umgeht
Der Ausgangspunkt ist eine unbequeme Feststellung: Schon die Tatsache, dass Sie einen bestimmten Namen prüfen, ist eine vertrauliche Information. Sie kann eine Kundenbeziehung, ein Übernahmeziel oder einen internen Verdachtsfall verraten. Das übliche Gegenmittel ist ein Versprechen im Vertrag. Wir halten das für zu wenig und haben die Verkettung stattdessen aus dem Verfahren entfernt.
Was der Dienst sieht
- Den geprüften Namen und das Land — die Angaben sind für die Recherche erforderlich.
- Die Inhalte der Artikel, die im Rahmen der Recherche abgerufen und ausgewertet werden.
- Betriebsdaten wie Zeitpunkt, Laufzeit und Ergebniszustand eines Vorgangs.
- Die Anzahl der Abfragen, die ein Kunde je Abrechnungszeitraum bezieht.
Was der Dienst nicht sieht
- Welcher Kunde eine bestimmte Abfrage gestellt hat. Ein eingelöstes Token lässt sich nicht der Ausgabe zuordnen.
- Welche konkreten Token an einen bestimmten Kunden ausgegeben wurden — sie werden verblindet signiert.
- Warum Sie einen Namen prüfen. Ein Aktenzeichen, ein Vorgangsbezug oder ein interner Anlass wird nicht übergeben und nicht abgefragt.
- Ihre internen Nutzer. Es gibt keine Benutzerkonten je Sachbearbeiter, weil es sie nicht braucht.
Verfahren
Warum die Zuordnung nicht möglich ist.
Verwendet werden blinde RSA-Signaturen nach RFC 9474 — ein etabliertes, standardisiertes Verfahren, keine Eigenentwicklung. Der Ablauf in vier Schritten:
- 01
Erzeugen
Ihr System erzeugt die Token selbst
Jedes Token beginnt als Zufallswert, der auf Ihrer Seite entsteht und Ihre Umgebung in dieser Form nie verlässt. Er enthält keine Kundennummer, keinen Zähler und keine Struktur — jede Struktur würde die Zuordenbarkeit wieder einführen.
- 02
Verblinden
Der Wert wird vor dem Versand verblindet
Ihr System verschleiert den Wert mathematisch, bevor er zu uns gelangt. Wir erhalten eine Zeichenkette, aus der sich das spätere Token nicht ableiten lässt.
- 03
Signieren
Wir signieren, ohne den Inhalt zu kennen
Der Server unterschreibt den verblindeten Wert. Er sieht dabei nie, was er tatsächlich unterschreibt, und speichert weder den übermittelten Wert noch die erzeugte Signatur — er zählt lediglich, wie viele Token Sie in diesem Zeitraum bezogen haben.
- 04
Einlösen
Beim Einlösen prüft er nur seine eigene Unterschrift
Ihr System entfernt die Verblindung und erhält ein gültiges Token. Bei der Abfrage prüft der Server, dass die Signatur von ihm stammt — mehr kann er nicht feststellen. Um Mehrfachnutzung zu verhindern, wird ein Streuwert des Tokens vermerkt; dieser Vermerk enthält weder das Token selbst noch einen Bezug zu Ihnen oder zum Inhalt der Abfrage.
Was trotzdem sichtbar bleibt
Eine Datenschutzaussage ist nur so viel wert wie das, was sie einräumt. Diese Restinformationen bleiben bestehen — sie sind dem Verfahren inhärent, und keine davon betrifft den Inhalt Ihrer Abfragen.
| Sichtbar | Warum | Was daraus nicht folgt |
|---|---|---|
| Sie sind Kunde | Es besteht ein Vertrag und eine Rechnungsbeziehung. | Welche Namen Sie geprüft haben. |
| Anzahl bezogener Abfragen je Zeitraum | Das Kontingent muss durchgesetzt werden. | Welche Token das waren oder wann sie eingelöst wurden. |
| Inhalt der einzelnen Abfrage | Ohne Name und Land lässt sich nicht recherchieren. | Von wem sie stammt. |
| Netzwerkmetadaten der Verbindung | Jede HTTP-Verbindung hat eine Gegenstelle, und diese ist sichtbar, solange die Verbindung besteht. | Eine gespeicherte Aufzeichnung davon. Das Zugriffsprotokoll der Abfrageschnittstelle ist so formatiert, dass es keine Client-Adresse und keine Forwarded-For-Kette enthält — es bleibt also keine Verbindungshistorie, die sich nachträglich einem eingelösten Token gegenüberstellen ließe. Diagnoseeinträge bei echten Fehlern sind die einzige Ausnahme und kurzlebig. Wer strengere Trennung braucht, kann den Dienst über einen eigenen Ausgangspunkt ansprechen oder im eigenen Rechenzentrum betreiben. |
Kurzfassung: Wir sehen, wonach gesucht wurde, und wir sehen, wie viele Abfragen Sie beziehen. Wir können beides nicht miteinander verbinden.
Eingesetzte Verarbeiter
Die Recherche wird nicht vollständig im eigenen Haus erbracht. Wer das verschweigt, verschweigt die wichtigste Angabe für Ihre Auslagerungsprüfung.
Suchdienstleister
Die erzeugte Suchanfrage — und damit der geprüfte Name in seinen Varianten — wird an einen Suchdienst übermittelt. Dieser sieht die Anfrage, nicht Ihre Identität.
Sprachmodell-Anbieter
Artikeltexte und der geprüfte Name werden zur Analyse an einen Anbieter für Sprachmodelle übermittelt. Auch hier gilt: Der Anbieter sieht den Inhalt, nicht, für wen recherchiert wird.
Abgerufene Webseiten
Zur Volltextanalyse werden die gefundenen Artikel abgerufen. Die betroffenen Webseiten sehen einen Abruf von unserer Infrastruktur, nicht von Ihrer.
Betrieb im eigenen Rechenzentrum
Wenn Ihre Auslagerungsrichtlinie diese Übermittlungen nicht zulässt, ist die Bereitstellung in Ihrer eigenen Umgebung der vorgesehene Weg — dann laufen die Verbindungen zu den genannten Diensten von Ihrer Infrastruktur unter Ihren Verträgen. Sprechen Sie uns darauf an; die vollständige Liste der Verarbeiter mit Rechtsgrundlagen und Standorten stellen wir für die Prüfung zur Verfügung.
Speicherung und Löschung
Ergebnisse
Screening-Ergebnisse werden für eine vereinbarte Dauer zwischengespeichert, damit eine Wiederholung derselben Recherche sofort beantwortet werden kann. Danach werden sie verworfen. Die Dauer ist einstellbar und kann auf null gesetzt werden.
Eingelöste Token
Gespeichert wird ausschließlich ein Streuwert je Token, um Mehrfachnutzung zu verhindern — nicht das Token, nicht der Kunde, nicht der Inhalt der Abfrage. Mit dem Ablauf eines Ausgabezeitraums werden die zugehörigen Einträge vollständig entfernt.
Ablauf durch Schlüsselwechsel
Token sind an den Ausgabezeitraum gebunden, in dem sie signiert wurden. Wird ein Zeitraum nicht mehr honoriert, verlieren alle zugehörigen Token ihre Gültigkeit — ohne Ablaufdatum je Token und ohne Aufräumlauf.
Gescheiterte Vorgänge
Nicht beantwortbare Vorgänge werden zur Fehleranalyse abgelegt und nach der Auswertung entfernt. Diese Ablage enthält die Abfrageparameter, aber keinen Kundenbezug.
Zugriffsprotokolle
Das Zugriffsprotokoll der Abfrageschnittstelle hält fest, was angefragt wurde, wie es endete und wie lange es dauerte — bewusst ohne Client-Adresse und ohne Forwarded-For-Kette, und die Adresse wird auch nicht an die Anwendung weitergegeben. Es entsteht damit keine Verbindungsaufzeichnung, die sich später einem eingelösten Token zuordnen ließe. Diagnoseeinträge, die bei echten Störungen geschrieben werden, können eine Adresse enthalten und werden nur kurz aufbewahrt.
Teil 2 — Datenschutzerklärung für diese Website
Diese Website ist eine Informationsseite ohne Nutzerkonten, ohne Kontaktformular und ohne Reichweitenmessung. Eine einzige Seite bildet die Ausnahme: Unter „Live testen“ können Sie eine echte Abfrage auslösen. Solange Sie das nicht tun, geht von dem, was Sie hier lesen, nichts an uns zurück.
Verantwortlicher
Verantwortlich im Sinne der Datenschutz-Grundverordnung ist DemandFlow GmbH, Friedrichstraße 11, 68723 Plankstadt, Deutschland. Kontakt in Datenschutzangelegenheiten: datenschutz@negative-news-search.com. Datenschutzbeauftragte:r: nicht bestellt.
Server-Logdateien
Beim Aufruf dieser Website verarbeitet der Hostinganbieter (IONOS SE, Elgendorfer Str. 57, 56410 Montabaur, Rechenzentrum Karlsruhe (Deutschland)) technisch notwendige Verbindungsdaten: IP-Adresse, Zeitpunkt, abgerufene Adresse, übertragene Datenmenge, Verweisadresse und Browserkennung. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO; das berechtigte Interesse liegt im sicheren und störungsfreien Betrieb. Die Daten werden nach kurzer Frist gelöscht und nicht mit anderen Quellen zusammengeführt. Ausgenommen sind die Seite „Live testen“ und die Abfragen, die sie auslöst — dort wird keine Adresse protokolliert; siehe unten.
Keine Cookies, keine Reichweitenmessung
Diese Website setzt keine Cookies, verwendet keinen lokalen Speicher des Browsers, bindet keine Analyse- oder Trackingdienste ein und lädt keine externen Schriften, Skripte oder Inhalte von Drittanbietern. Es gibt deshalb auch kein Einwilligungsbanner — es gäbe nichts, worin einzuwilligen wäre. Das gilt auch für die Live-Demo: Sie lädt nichts von Dritten nach und speichert nichts in Ihrem Browser.
Die Ausnahme: „Live testen“
Alle übrigen Seiten sind statisch — sie liefern Text und Bilder aus, und es geht nichts an uns zurück. „Live testen“ ist die einzige Seite, auf der das anders ist, und auch dort erst in dem Moment, in dem Sie das Formular tatsächlich absenden. Das bloße Aufrufen oder Ausfüllen der Seite überträgt noch nichts. Beim Absenden übertragen werden genau die Angaben, die im Formular stehen: geprüfter Name, Land, gewünschte Berichtssprache und das Token, das Sie einfügen. Ihr Browser spricht dabei ausschließlich mit negative-news-search.com; die Anfrage wird serverseitig an den Dienst weitergereicht, es wird keine Verbindung zu einem anderen Host aufgebaut. Die Recherche selbst läuft danach wie jede andere Abfrage — mit den in Teil 1 genannten Verarbeitern.
Auch über die Demo entsteht kein Profil
Für diesen Weg gilt dieselbe Zusage wie für die Schnittstelle: Das Zugriffsprotokoll der Demo-Seite und ihrer Aufrufe ist so formatiert, dass es keine Client-Adresse enthält, und die Adresse wird auch nicht an den Dienst weitergereicht. Vor allem aber ändert die Demo nichts am Verfahren aus Teil 1 — das eingefügte Token ist verblindet signiert, wir wissen also nicht, für wen es ausgegeben wurde. Eine Abfrage über die Demo ist damit ebenso wenig einem Kunden zuzuordnen wie eine Abfrage über die Schnittstelle. Wer wonach gesucht hat, lässt sich auch hier nicht beantworten, und zwar nicht deshalb, weil wir die Antwort nicht herausgeben, sondern weil sie nirgends entsteht. Eine Anordnung, sie herauszugeben, ginge deshalb ins Leere.
Was wir dabei einräumen
Zwei Einschränkungen nennen wir ausdrücklich, weil sie bestehen bleiben. Erstens: Diagnoseeinträge, die bei echten Störungen geschrieben werden, können eine Adresse enthalten; sie werden nur kurz aufbewahrt. Zweitens: Die übrigen Seiten dieser Website werden regulär protokolliert (siehe „Server-Logdateien“). Ein Seitenaufruf kurz vor einer Abfrage schließt eine zeitliche Annäherung deshalb nicht vollständig aus. Wer strikte Trennung braucht, ruft den Dienst über die Schnittstelle aus der eigenen Umgebung auf statt über diese Demo — oder betreibt ihn im eigenen Rechenzentrum.
Kontaktaufnahme
Wenn Sie uns per E-Mail schreiben, verarbeiten wir Ihre Angaben zur Bearbeitung der Anfrage und für Anschlussfragen. Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO bei vertragsbezogenen Anfragen, sonst Art. 6 Abs. 1 lit. f DSGVO. Wir löschen die Korrespondenz, sobald sie nicht mehr benötigt wird und keine gesetzlichen Aufbewahrungspflichten entgegenstehen.
Ihre Rechte
Sie haben das Recht auf Auskunft (Art. 15), Berichtigung (Art. 16), Löschung (Art. 17), Einschränkung der Verarbeitung (Art. 18), Datenübertragbarkeit (Art. 20) sowie ein Widerspruchsrecht gegen Verarbeitungen auf Grundlage berechtigter Interessen (Art. 21 DSGVO). Wenden Sie sich dafür an datenschutz@negative-news-search.com. Unabhängig davon steht Ihnen ein Beschwerderecht bei einer Aufsichtsbehörde zu, etwa bei dem Landesbeauftragten für den Datenschutz und die Informationsfreiheit Baden-Württemberg (LfDI), Lautenschlagerstraße 20, 70173 Stuttgart.
Stand
Diese Datenschutzerklärung hat den Stand 14.08.2026. Wir passen sie an, wenn sich die Verarbeitung ändert.
Sie prüfen eine Auslagerung?
Wir stellen die Unterlagen für die Prüfung bereit: Verarbeitungsübersicht, Verarbeiterliste mit Standorten, Betriebskonzept und die Beschreibung des Token-Verfahrens.