Sicherheit bei Reqlio

Zuletzt aktualisiert am 24. September 2026 · gilt für die Anwendung unter <kunde>.reqlio.eu

In Reqlio liegen die Anforderungen, Verifikationsnachweise und die Review-Historie von Engineering-Teams. Diese Seite sagt in klaren Worten, wo diese Daten liegen, wer darauf zugreifen kann, was die EU verlässt und warum, was passiert, wenn etwas ausfällt, und was wir noch nicht umgesetzt haben. Der Fragebogen am Ende ist vorausgefüllt, damit Ihre Sicherheitsprüfung mit Antworten beginnen kann statt mit einem leeren Formular.

Auf dieser Seite

1. Architektur und Mandantentrennung
2. Hosting und physische Sicherheit
3. Verschlüsselung
4. Datenstandort und Unterauftragsverarbeiter
5. KI: was gesendet wird, wohin, und wie Sie sie abschalten
6. Authentifizierung und Zugriffskontrolle
7. Sichere Entwicklung und Änderungsmanagement
8. Schwachstellenmanagement und Meldung von Schwachstellen
9. Protokollierung und Monitoring
10. Datensicherung, Wiederherstellung und Kontinuität
11. Reaktion auf Sicherheitsvorfälle
12. DSGVO und Auftragsverarbeitungsvertrag
13. Personal und Organisation
14. Fragebogen (vorausgefüllt)

1. Architektur und Mandantentrennung

Reqlio ist eine Single-Page-Webanwendung, die mit einer einzigen API kommuniziert; dahinter steht PostgreSQL. Jeder Kunde erhält eine eigene Subdomain (ihrefirma.reqlio.eu) und eine eigene PostgreSQL-Datenbank. Es gibt keine gemeinsam genutzten Inhaltstabellen und keine Mandanten-ID-Spalte, über die eine vergessene WHERE-Klausel Daten an einen anderen Kunden durchsickern lassen könnte; eine Abfrage kann die Daten eines anderen Kunden physisch nicht erreichen, weil sie mit einer anderen Datenbank verbunden ist.

• Der Mandant wird bei jeder Anfrage aus dem Hostnamen ermittelt. Ein unbekannter Hostname erhält einen 404, niemals einen Standardmandanten.
• Jedes Sitzungstoken enthält den Mandanten, für den es ausgestellt wurde, und der Benutzerdatensatz wird in der Datenbank dieses Mandanten nachgeschlagen. Ein Token eines Mandanten ist bei einem anderen wertlos.
• Jeder Mandant hat einen eigenen Connection-Pool. Nichts wird mandantenübergreifend zwischengespeichert.
• Das Lieferantenportal (Business-Tarif) gibt externen Parteien Zugriff auf genau die Spezifikationen, für die ein Kunde Zugriff gewährt, getrennt pro Partei; die Isolation zwischen den Parteien war Teil der Prüfung aus Angreiferperspektive im September 2026.

Web, API und Datenbank laufen als getrennte Container auf einem virtuellen Server hinter einem Reverse Proxy, der TLS terminiert. Es gibt kein Content Delivery Network und keinen Edge-Cache: Eine Anfrage aus Ihrem Browser geht nach Frankfurt und zurück.

2. Hosting und physische Sicherheit

Die Produktion läuft auf virtuellen Servern der creoline GmbH, Bergstraße 9a, 48341 Altenberge, Deutschland, die von TÜV SÜD nach ISO/IEC 27001:2022 zertifiziert ist (Registriernummer 12 310 69090 TMS, gültig bis März 2028), und zwar für den Betrieb und die Wartung virtueller Server und Infrastruktur. Die Hardware steht im Rechenzentrum FRA4 der firstcolo GmbH, Kruppstraße 105, Frankfurt am Main. Es ist nach ISO/IEC 27001:2022 zertifiziert, mit dem Rechenzentrumsbetrieb im Geltungsbereich (TÜV Rheinland, Registriernummer 01 153 1700043, gültig bis Februar 2028), und ist ein TÜV-zertifiziertes Rechenzentrum Level 3 nach DIN EN 50600 (TÜV Saarland, gültig bis Februar 2027).

firstcolo stellt Gebäude, Stromversorgung, Kühlung und physische Zutrittskontrolle bereit. Das Unternehmen hat keinen logischen Zugriff auf die Server oder die Daten darauf und ist daher kein Unterauftragsverarbeiter. Das Zertifikat und der Auftragsverarbeitungsvertrag von creoline sind auf Anfrage erhältlich oder auf der Zertifizierungsseite von creoline selbst abrufbar.

Staging und der Analytics-Server laufen beim selben Anbieter. Build-Server, Quellcode-Repository und Code-Qualitäts-Scanner betreiben wir selbst, ebenfalls bei diesem Anbieter, in einem separaten Betriebsnetz, das nur über VPN erreichbar ist.

3. Verschlüsselung

4. Datenstandort und Unterauftragsverarbeiter

Alle Kundendaten werden in Deutschland gespeichert. Eines verlässt die EU, und das ist optional: KI-Anfragen. Diese Tabelle ist die maßgebliche Liste der Unterauftragsverarbeiter, auf die unser Auftragsverarbeitungsvertrag verweist; neue Einträge kündigen wir 30 Tage im Voraus an.

Zur Klarstellung, keine Unterauftragsverarbeiter: firstcolo GmbH (nur physische Einrichtung, kein Zugriff auf Daten); Plausible (selbst gehostet auf unserem eigenen Server, ohne Cookies, aggregierte Seitenaufrufe unter einer einzigen Kennung für die gesamte Anwendung, niemals pro Kunde); Slack (nur wenn Sie einen Workspace verbinden; dann gehen Benachrichtigungen auf Ihre Weisung an Ihren Workspace); E-Mail, die von unserem eigenen Mailserver über das Relay von creoline versendet wird.

5. KI: was gesendet wird, wohin, und wie Sie sie abschalten

KI ist Teil des Produkts: Qualitätsbewertung anhand eines Bewertungsschemas nach dem Vorbild von INCOSE, Vorschläge zur Umformulierung, Zerlegung in Teilanforderungen, Konflikt- und Glossarprüfungen, Vorschläge für Verifikation und Risiken, Erläuterungen von Trace-Ketten in Textform und ein Projekt-Chat. All diese Funktionen laufen über einen einzigen Codepfad mit den folgenden Eigenschaften.

• Was gesendet wird. Der Anforderungstext und der Kontext, den die Funktion braucht (benachbarte Anforderungen, Glossarbegriffe, das Regelprofil). Niemals Anhänge, niemals Kontodaten, niemals Daten anderer Kunden.
• Wohin es geht. Standardmäßig an die API von Anthropic in den USA, oder an die Gemini-API von Google, wenn der Admin des Projekts diese auswählt. Einen Modell-Endpunkt ausschließlich in der EU gibt es derzeit nicht; eine Option für einen eigenen Endpunkt (Ihr Schlüssel, Ihre Region) ist für den Business-Tarif geplant.
• Was der Anbieter speichert. Keiner der beiden Anbieter trainiert mit API-Daten. Anthropic bewahrt Prompts bis zu 30 Tage zur Missbrauchserkennung auf und bietet auf Anfrage Zero Data Retention an; die kostenpflichtige Stufe von Google bewahrt sie bis zu 55 Tage auf. Beides sind Bedingungen der kommerziellen APIs, nicht der Verbraucherprodukte.
• Wie Sie sie abschalten. Jedes Projekt hat einen KI-Schalter. Ist er ausgeschaltet, lehnt die API jede KI-Route ab, bevor irgendein Modell kontaktiert wird. Eine Organisation kann außerdem das Modul mit den KI-Werkzeugen für alle ihre Benutzer ausblenden, und die tägliche Qualitätsprüfung im Hintergrund läuft nur für Projekte, die sie ausdrücklich aktivieren.
• Was wir protokollieren. Anbieter, Modell, Funktion, Token-Anzahl, Projekt- und Benutzer-ID pro Aufruf, für die Verbrauchsanzeige und das monatliche Kontingent. Nicht den Prompt, nicht die Antwort.
• Was das Modell ändern kann. Nichts von sich aus. Eine vorgeschlagene Umformulierung wird erst dann zur Anforderung, wenn ein Benutzer sie übernimmt, und das geschieht über den normalen Bearbeitungsweg mit Historie; sie ist also prüfbar und umkehrbar wie jede andere Änderung.

Mit dem MCP-Server (Early Access) kann ein Agent wie Claude in Ihrem Projekt arbeiten, und zwar über dasselbe Berechtigungsmodell wie ein Benutzer: Er authentifiziert sich mit OAuth 2.1 und PKCE, hält an einem ausdrücklichen Zustimmungsbildschirm an und verwendet ein persönliches Zugriffstoken, das Sie jederzeit widerrufen können.

6. Authentifizierung und Zugriffskontrolle

7. Sichere Entwicklung und Änderungsmanagement

• Jede Änderung erreicht die Produktion über eine einzige Pipeline und auf keinem anderen Weg: Build, Lint, die vollständige Backend-Testsuite gegen eine echte Datenbank, Typprüfung und Unit-Tests des Frontends, ein Audit der Abhängigkeiten, statische Analyse mit einem Security Quality Gate und eine End-to-End-Suite, die den Kernablauf (Projekt anlegen, ReqIF importieren, bewerten, verknüpfen, Baseline erstellen, Review durchführen, freigeben, exportieren) im Browser durchläuft. Ein rotes Gate blockiert das Deployment.
• Änderungen werden zuerst aus dem Entwicklungszweig in eine nur über VPN erreichbare Staging-Umgebung ausgerollt und aus dem Hauptzweig in die Produktion.
• Datenbankmigrationen sind handgeschriebenes SQL, im Repository versioniert und vom Deploy-Job angewendet, bevor die neue API startet; eine fehlgeschlagene Migration stoppt das Release.
• Die Anwendung setzt die üblichen Sicherheits-Header für Browser, verwendet durchgehend parametrisierte Abfragen, validiert Eingaben an der API-Grenze mit Schemas und bereinigt Rich Text an jeder Stelle, an der er gerendert wird. Tabellenexporte neutralisieren Formel-Injection.
• Vom Browser geladener Code von Drittanbietern: keiner. Schriften, Skripte und Stylesheets werden von unserem eigenen Origin ausgeliefert, auf der Website durchgesetzt durch eine Content Security Policy.

8. Schwachstellenmanagement und Meldung von Schwachstellen

• Abhängigkeiten. Die Pipeline schlägt bei jedem Lauf fehl, sobald eine Sicherheitsmeldung (Advisory) mit Schweregrad hoch oder kritisch für eine Produktionsabhängigkeit vorliegt. Ein wöchentlicher geplanter Job meldet alle Advisories und veralteten Pakete, einschließlich der Entwicklungswerkzeuge, sodass Abweichungen innerhalb von sieben Tagen sichtbar werden.
• Statische Analyse. SonarQube mit einem Security Quality Gate, auf das Deployments in die Produktion warten.
• Reviews. Im September 2026 wurde die Authentifizierungsoberfläche (Sitzungen, MFA, Mandantentrennung, SSO, der OAuth-Provider, das Lieferantenportal) einer strukturierten Prüfung aus Angreiferperspektive unterzogen; jeder Befund mit Schweregrad kritisch, hoch oder mittel wurde innerhalb von zwei Tagen behoben und ausgerollt. Eine Zusammenfassung ist auf Anfrage erhältlich.
• Externer Test. Noch nicht. Ein manueller Penetrationstest durch ein namentlich ausgewiesenes Unternehmen aus der EU, mit Bestätigungsschreiben (Attestation Letter) und Nachtest, ist für das erste Quartal 2027 angesetzt, bevor die Preisseite für die Selbstregistrierung geöffnet wird. Das Schreiben wird hier verlinkt.
• Eine Schwachstelle melden. Schreiben Sie an security@reqlio.eu. Wir bestätigen den Eingang innerhalb von zwei Werktagen, halten Sie auf dem Laufenden und gehen nicht gegen Sicherheitsforschung in gutem Glauben vor, die sich auf Ihre eigenen Testdaten beschränkt und Störungen des Dienstes vermeidet. Einzelheiten stehen in unserer security.txt.

9. Protokollierung und Monitoring

10. Datensicherung, Wiederherstellung und Kontinuität

Was gesichert wird. Jede Mandantendatenbank, jede Nacht um 02:00 Uhr UTC, als komprimierter PostgreSQL-Dump. Neue Mandanten werden automatisch erfasst. Die Aufbewahrung auf dem Host ist gestaffelt: 7 tägliche, 4 wöchentliche (sonntags) und 6 monatliche Kopien. Um 02:30 Uhr werden die Dumps, alle Dateianhänge, die Datenbankrollen und die Konfiguration, die zum Wiederaufbau des Dienstes nötig ist, zu einem Export zusammengestellt.

Externe Kopie. Jede Nacht um 03:30 Uhr holt ein Rechner außerhalb der Infrastruktur des Hosting-Anbieters diesen Export über VPN und SSH ab. Die Übertragung läuft nur in eine Richtung: Der Sicherungsrechner verwendet einen Schlüssel mit reinem Lesezugriff, der an seine eigene VPN-Adresse gebunden ist, und der Produktionsserver kann den Sicherungsrechner überhaupt nicht erreichen. Ein kompromittierter Server kann die Kopien daher weder verändern noch löschen. Der Hosting-Anbieter hält zusätzlich tägliche Images des gesamten Servers für sieben Tage vor.

Die Wiederherstellung wird getestet, nicht vorausgesetzt. Eine skriptgesteuerte Übung stellt einen Produktions-Dump in eine Wegwerf-Datenbank auf dem Staging-Host wieder her und prüft Zeilenzahlen, die neueste Baseline und das neueste Review. Letzter Lauf am 9. September 2026: Dump von 3,6 MB, 94 Tabellen, 583 Anforderungen, Wiederherstellung in 14 Sekunden von Anfang bis Ende. Die Übung wird vierteljährlich wiederholt sowie nach jeder Änderung am Sicherungsskript oder an der Datenbankversion; das Protokoll wird im Repository geführt.

Wiederherstellungsmodell. Die Produktion ist ein virtueller Server in einem Rechenzentrum; es gibt kein Live-Replikat. Nach einem Ausfall des Hosts wird der letzte nächtliche Dump auf einem neuen Server wiederhergestellt. Das realistische Datenverlustfenster beträgt daher bis zu 24 Stunden, die Wiederherstellungszeit einige Stunden. Wir sagen das offen, weil ein Fragebogen danach fragen wird und weil die Tarife in dieser Preisklasse keine standortübergreifende Datenbank enthalten.

Kontinuität, schriftlich zugesichert. Reqlio wird von einem kleinen Unternehmen entwickelt und betrieben. Die folgenden Punkte sind Zusagen und stehen im Auftragsverarbeitungsvertrag:

• Exporte in ReqIF, XLSX und CSV sind in jedem Tarif jederzeit verfügbar, auch während der Testphase und nach der Kündigung. Kein Export liegt hinter einer Bezahlschranke.
• Nach der Kündigung behalten Sie zwölf Monate lang Lesezugriff auf Ihren Workspace, einschließlich Export. Endet eine Testphase ohne Vertragsabschluss, wird der Workspace für 60 Tage auf Lesezugriff gesetzt, nicht gelöscht.
• Im Enterprise-Tarif ist eine Hinterlegung des Quellcodes (Source-Code-Escrow) möglich.
• Am Ende des Nur-Lese-Zeitraums, oder auf Anfrage früher, wird Ihre Datenbank gelöscht; aus den Aufbewahrungsstufen der Datensicherung fällt sie innerhalb von sechs Monaten heraus.

11. Reaktion auf Sicherheitsvorfälle

• Fehler und Ausfälle werden über das Monitoring und die Verfügbarkeitsprüfung erkannt, nicht über Kundenmeldungen, und vom Betreiber direkt bearbeitet; zwischen Ihnen und der Person, die das Problem beheben kann, gibt es keine Warteschlange.
• Bestätigen wir eine Verletzung des Schutzes personenbezogener Daten, die Ihre Daten betrifft, benachrichtigen wir Ihre benannte Kontaktperson innerhalb von 24 Stunden nach der Bestätigung: was wir wissen, was betroffen ist, was wir unternommen haben und was wir empfehlen. Ändert sich die Lage, informieren wir Sie fortlaufend. Das ist die Pflicht des Auftragsverarbeiters nach Art. 33 Abs. 2 DSGVO; 24 Stunden sind unsere zugesagte Höchstfrist, statt eines undefinierten „unverzüglich“.
• Verdächtige Authentifizierungsaktivitäten sehen Ihre eigenen Admins im Sicherheitsprotokoll, ohne auf uns warten zu müssen: Fehlgeschlagene Anmeldungen, MFA-Fehlschläge, die Wiederverwendung von Tokens und Rollenänderungen werden in dem Moment erfasst, in dem sie geschehen.
• Betroffene Kunden erhalten nach dem Sicherheitsvorfall eine Zusammenfassung mit Ursache, zeitlichem Ablauf und Korrekturmaßnahmen.

12. DSGVO und Auftragsverarbeitungsvertrag

Für die Daten, die Sie in Reqlio ablegen, sind Sie der Verantwortliche und wir der Auftragsverarbeiter. Wir schließen mit jedem Kunden einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO. Der Vertrag ist in englischer Sprache abgefasst und heißt dort „data processing agreement“ (DPA); gemeint ist dasselbe. Er beruht auf den Standardvertragsklauseln nach Art. 28 der Europäischen Kommission selbst, unverändert übernommen und um unsere zusätzlichen Zusagen ergänzt. Er enthält:

• Gegenstand, Dauer, Art und Zweck der Verarbeitung sowie die Kategorien von Daten und betroffenen Personen (Anhang II);
• die technischen und organisatorischen Maßnahmen nach Art. 32, also die auf dieser Seite beschriebenen konkreten Kontrollen (Anhang III);
• die Liste der Unterauftragsverarbeiter in §4, mit 30 Tagen Vorankündigung bei Änderungen und einem Widerspruchsrecht (Anhang IV);
• den Übermittlungsmechanismus für die KI-Anbieter: EU-Standardvertragsklauseln und, sofern der Anbieter zertifiziert ist, das EU–US Data Privacy Framework, dazu die Tatsache, dass KI pro Projekt optional ist und vollständig deaktiviert werden kann;
• Meldung von Datenschutzverletzungen innerhalb von 24 Stunden, Unterstützung bei Anfragen betroffener Personen und bei Datenschutz-Folgenabschätzungen, Auditrechte sowie Löschung oder Rückgabe am Vertragsende.

Die aktuelle Fassung, die TOM sowie den eigenen AVV und das Zertifikat von creoline erhalten Sie auf Anfrage unter info@reqlio.eu. Die Datenschutzerklärung für diese Website, für die wir der Verantwortliche sind, ist ein eigenes Dokument: privacy.html.

13. Personal und Organisation

Reqlio wird von Holtstiege Consulting, Amsterdam, entwickelt und betrieben. Eine Person hat Zugriff auf die Produktion. Ein einzelner Betreiber wirft in einem Fragebogen eine berechtigte Frage auf, deshalb hier die ehrliche Antwort und was dies ausgleicht:

• Keine Änderung erreicht die Produktion, ohne die automatisierten Gates aus §7 zu durchlaufen; der Betreiber deployt nicht von Hand, sondern nur über die Pipeline, und jedes Deployment ist einem Commit zugeordnet.
• Der Zugriff auf die Produktion erfolgt über VPN mit einem persönlichen Schlüssel; SSH-Sitzungen und privilegierte Befehle werden auf dem Host protokolliert.
• Laufzeit-Secrets werden verschlüsselt gespiegelt, damit ein Nachfolger den Dienst aus dem Repository, der Secrets-Spiegelkopie und einer Datensicherung neu aufbauen kann; genau diesen Wiederaufbau probt die Wiederherstellungsübung.
• Die Kontinuitätszusagen in §10 gibt es genau für den Fall, dass es das Unternehmen nicht mehr gibt.

Ein Datenschutzbeauftragter ist nicht benannt, und es ist auch keiner vorgeschrieben (Art. 37 DSGVO). Unsere Aufsichtsbehörde ist die niederländische Autoriteit Persoonsgegevens.

14. Fragebogen

Vorausgefüllte Antworten auf die Fragen, die Sicherheitsprüfungen üblicherweise stellen, gruppiert wie im CAIQ-Lite der Cloud Security Alliance. Fragt Ihre Vorlage etwas, das hier nicht steht, schicken Sie es uns; wir beantworten Fragebögen im Rahmen des Vertriebsprozesses, nicht als kostenpflichtige Zusatzleistung.

Anwendungs- und Schnittstellensicherheit

Geschäftskontinuität und Resilienz

Änderungsmanagement

Datensicherheit und Datenschutz

Verschlüsselung und Schlüsselverwaltung

Governance und Compliance

Personal

Identitäts- und Zugriffsmanagement

Infrastruktur und Virtualisierung

Protokollierung und Monitoring

Management von Sicherheitsvorfällen

Lieferkette und Unterauftragsverarbeiter

Bedrohungs- und Schwachstellenmanagement

Fragen zu allem auf dieser Seite: info@reqlio.eu. Meldungen von Schwachstellen: security@reqlio.eu.