Vertrauen

Wir betreiben StandardOS mit StandardOS

Die stärkste Aussage, die ein Compliance-Produkt treffen kann, ist, dass seine Hersteller ihm ihre eigene Compliance anvertrauen. Unser ISO-27001-Managementsystem, mit Geltungsbereich, Risiken, Maßnahmen, Audits und Bewertungen, liegt in StandardOS selbst. Statt Sie zu bitten, einem Siegel zu vertrauen, steht hier genau, wie der Dienst abgesichert und betrieben wird, und wie Sie den wichtigsten Teil ohne uns überprüfen.

Die Unterauftragsverarbeiter-Liste unten hat sich zuletzt am 2026-09-27 geändert; alles andere auf dieser Seite ist über die Links darin überprüfbar.

Ohne uns nachprüfen

Infrastruktur und Hosting

Verfügbarkeit

Durchgehend von außerhalb unserer eigenen Infrastruktur überwacht, und das Ergebnis ist öffentlich, auch wenn es schlecht ist.

Uns ist lieber, Sie sehen eine Störung hier, als dass Sie hinterher von uns davon hören.

Live-Status des Dienstes

Speicherort der Daten

Alle Kundendaten liegen in der EU (Supabase, Region Irland).

Überall dort, wo der Dienst Kundendaten berührt, wählen wir EU-Regionen.

Auslieferung

Die Anwendungen werden ausschließlich über TLS 1.2+ ausgeliefert, HSTS ist erzwungen.

Statische Dateien über ein CDN; am Edge liegen keine Kundendaten.

Sicherungen

Verwaltete tägliche Sicherungen der Hauptdatenbank in derselben EU-Region, mit automatischer Warnung, wenn eine geplante Sicherung ausbleibt.

Eine wöchentliche verschlüsselte Kopie liegt zusätzlich außerhalb des Datenbankanbieters, damit ein Ausfall von dessen Konto nicht alle Kopien mitnimmt.

Wiederherstellung

Überprüfbar statt behauptet. Weil Ihre Compliance-Datensätze in einer Hash-Kette liegen und die Tageswurzeln veröffentlicht werden, lässt sich eine wiederhergestellte Datenbank gegen eine Kopie prüfen, die wir nicht kontrollieren.

Es ist dieselbe Prüfung, die wir Ihrem Auditor in die Hand geben. Eine veränderte Wiederherstellung würde nicht passen, und wir wüssten es, statt es anzunehmen.

Integrität der Aufzeichnungen, unser Unterschied

1. Manipulationssicherer Audit-Trail
Jede Änderung an Ihren ISMS-Aufzeichnungen (Dokumente, Risiken, die Erklärung zur Anwendbarkeit, Nachweise, Abweichungen, Audits, Bewertungen und erteilte Zugriffe) wird in ein Protokoll geschrieben, das nur angehängt und in einer Hash-Kette geführt wird.
Mehr lesen
Jeder Eintrag versiegelt den vorherigen, zusammen mit der Person, die die Änderung vorgenommen hat, sodass ein Umschreiben oder Umschreiben der Urheberschaft die Kette sichtbar bricht. Angemeldete Nutzerinnen und Nutzer haben auf Datenbankebene nur Lesezugriff auf dieses Protokoll; UPDATE und DELETE sind darauf auch für die Service-Rolle entzogen, mit der wir die Plattform betreiben, einen Löschpfad gibt es also für niemanden. Die Kette wird tabellenweise angehängt und nicht schemaweit: die oben genannten Datensätze liegen in der Kette, die betrieblichen Tabellen der Plattform selbst nicht.
2. Verankerung, mindestens wöchentlich
Jede Nacht halten wir den Kopf jeder Kette fest.
Mehr lesen
Mindestens wöchentlich (montags als Standard; täglich oder monatlich, wenn Ihre Inhaber es wählen) senden wir ihn an die Inhaber und Administratoren der Organisation, mit der Zahl der seit der letzten Quittung hinzugekommenen Einträge; in einer Woche, in der sich die Kette nicht bewegt hat, kommt keine Mail. Sobald eine Quittung in Ihrem Postfach liegt, liegt sie auf einem Server, den wir nicht betreiben, sodass ein späteres Umschreiben einen Kopf ergäbe, der nicht mehr zu dem passt, den Sie bereits halten. Die täglichen Wurzeln werden zudem offen veröffentlicht, damit jeder sie archivieren kann. Das macht Manipulation nicht unmöglich. Es macht sie erkennbar für jemanden, der seine Mail aufbewahrt hat.
Die veröffentlichten Tageswurzeln
3. Überprüfbarkeit
Exporte enthalten die Hashes und die Inhalte, über die sie berechnet wurden, dazu die genaue Hash-Regel.
Mehr lesen
Sie können die gesamte Kette selbst nachrechnen, in jeder Sprache, ohne dass StandardOS läuft. Die Spezifikation und ein abhängigkeitsfreies Skript, das dies in etwa hundert Zeilen erledigt, sind veröffentlicht, und genau dieses Skript lässt unsere eigene CI bei jedem Push gegen eine echte Kette laufen. Wir haben in diesem Markt kein weiteres Werkzeug gefunden, mit dem eine Kundin die Historie prüfen kann, ohne dem Anbieter zu vertrauen. Wenn Sie eines kennen, sagen Sie es uns, und wir korrigieren diese Seite.
Die Spezifikation und das Skript

Zugriffskontrolle

Mandantentrennung

Sicherheit auf Zeilenebene für jede Tabelle, erzwungen in der Datenbank selbst statt im Anwendungscode, und bei jeder Änderung in der CI getestet (pgTAP).

Authentifizierung

Anmeldung mit Passwort und modernem Hashing, Anmeldung über Microsoft und Google oder Single Sign-on per SAML 2.0 über den eigenen Identitätsanbieter der Organisation, den eine Inhaberin auf der Sicherheitsseite einrichtet und für alle Mitglieder verpflichtend machen kann.

Sitzungen sind kurzlebig und werden erneuert. Jede Person kann für ihr Konto einen zweiten Faktor (TOTP) hinterlegen, und eine Inhaberin kann ihn verlangen: für Passwortanmeldungen oder für jede Anmeldung, unabhängig vom Anbieter. Beide Anforderungen werden in der Datenbank erzwungen, nicht in der Oberfläche: Eine Sitzung, die sie nicht erfüllt, sieht überhaupt keine Organisationsdaten.

Unser eigener Zugriff

Mitarbeiterrollen nach dem Prinzip der geringsten Rechte.

Jede Handlung eines Betreibers an einem Mandanten wird in ein Register geschrieben, das nur angehängt werden kann und das wir weder bearbeiten noch löschen können, und das der Mandant auf seiner eigenen Audit-Trail-Seite unter den Handlungen von StandardOS-Personal liest. Welche unserer Mitarbeitenden gehandelt haben, wird zurückgehalten, weil das personenbezogene Daten unserer Beschäftigten sind; der Eintrag sagt also, was geschehen ist, wann, und was sich geändert hat. Es wird nur angehängt und nicht in einer Hash-Kette geführt: Die Kette und ihre Verankerungen schützen Ihre Aufzeichnungen, nicht unser Zugriffsprotokoll, und wir sagen lieber, was wovon gilt.

Entwicklungspraxis

Änderungssteuerung

Jede Änderung läuft durch die CI: Typprüfungen, Tests, Tests der Datenbankrichtlinien und Suche nach Geheimnissen bei jedem Commit.

Außerhalb des Produkts geprüft

Jeder Push baut eine echte Hash-Kette in Postgres, exportiert sie und prüft sie erneut mit demselben abhängigkeitsfreien Skript, das wir veröffentlichen, ausgeführt mit reinem Node und ohne StandardOS.

Eine Änderung der Hash-Regel, die vergaß, die Spezifikation nachzuziehen, lässt unseren Build scheitern statt Ihr Audit.

Trennung in der Datenbank getestet

Die Sicherheit auf Zeilenebene wird bei jedem Push mit pgTAP gegen ein laufendes Postgres geprüft.

Die Richtlinien werden dort getestet, wo sie durchgesetzt werden, statt im Anwendungscode mit dem Auge geprüft zu werden.

Geheimnisse

Werden in der CI geprüft und noch einmal durch einen Git-Hook, bevor Code einen Entwicklungsrechner verlässt; die gesamte Repository-Historie wurde sauber geprüft.

Abhängigkeiten

Fixiert und geprüft; automatische Schwachstellenmeldungen für den gesamten Abhängigkeitsgraphen.

Umgang mit KI

KI-gestützte Ausgaben im Produkt sind immer ein gekennzeichneter Entwurf, bis ein Mensch sie bestätigt.

Dieselbe Regel gilt dafür, wie wir entwickeln.

Datenschutz

DSGVO

Dänischer Verantwortlicher. Unser Auftragsverarbeitungsvertrag nach Artikel 28 ist unter getstandardos.com/legal/dpa vollständig veröffentlicht, für jede Kundin in jedem Tarif, ohne Unterschrift und ohne Verkaufsgespräch.

Was wir verarbeiten und warum, steht im Detail in der Datenschutzerklärung.

Kein Tracking

Keine Analyse- oder Werbetracker auf dieser Website; kein Cookie-Banner, weil es nichts gibt, dem zuzustimmen wäre.

Diagnosedaten

E-Mail-Adressen, IP-Adressen, Datensatzkennungen, Cookies und Autorisierungs-Header werden aus Fehlerberichten entfernt, bevor diese unsere Server verlassen.

Im Code konfiguriert und bei jeder Änderung überprüft, statt in einer Richtlinie versprochen.

Ausstieg

Vollständiger Export mit einem Klick in offenen Formaten, jederzeit: in der Testphase, im Abonnement und 90 Tage nach der Kündigung.

Bindung durch Aufwand ist für uns keine Strategie.

Unterauftragsverarbeiter

Bewusst wenige. Änderungen werden hier mit vorheriger Ankündigung an die Kundinnen und Kunden bekannt gegeben. Diese Liste und die in unserer Datenschutzerklärung(auf Englisch) sind dieselbe Liste, zweimal dargestellt. Zuletzt geändert am 2026-09-27.

Supabase
Database, authentication, file storage
Ort der Verarbeitung: EU (Ireland)
Vercel
Application hosting & delivery; cookieless traffic analytics (no cookies, no cross-site identifiers)
Ort der Verarbeitung: EU serving; global CDN for static assets
Sentry
Error monitoring, diagnostics only; email addresses, IP addresses and record identifiers are stripped before events leave our servers
Ort der Verarbeitung: EU region (Frankfurt)
Paddle
Merchant of record: checkout, payment, VAT & invoicing (card data never touches our servers)
Ort der Verarbeitung: UK, under the EU adequacy decision
Resend
Transactional email
Ort der Verarbeitung: EU region

Angekündigte Änderungen

Diese sind beschlossen und angekündigt, aber noch nicht im Einsatz. Keiner verarbeitet Daten, bevor wir ihn einschalten, und diese Ankündigung kommt vorher.

ZeroBounce
Angekündigt am 2026-09-27, gilt ab der Aktivierung
Email address verification for outreach prospects: a company role address is checked for deliverability before a first letter is sent, so the sending domain is not spent on dead mailboxes and spam traps. Only the address is sent, never a name, and the answer we keep is the service's own status word
Ort der Verarbeitung: EU. ZeroBounce states it hosts its servers in the EU and that data sent for processing is transmitted, stored and processed only on servers in the EU, on its own hardware rather than a public cloud, and it offers an EU data processing addendum incorporating the Commission's standard contractual clauses (zerobounce.net/gdpr and its EU DPA, read 2026-09-27). We call the EU-only endpoint api-eu.zerobounce.net, which its documentation describes as the endpoint where validations occur only within the EU; the global endpoint is not used

Verantwortungsvolle Meldung von Schwachstellen

Eine Schwachstelle gefunden? Schreiben Sie uns an security@getstandardos.com und wir bestätigen den Eingang innerhalb von zwei Werktagen.

Wir gehen nicht rechtlich gegen Forschung in gutem Glauben vor, halten Sie während der Behebung auf dem Laufenden und nennen Meldende, die genannt werden möchten. Bitte greifen Sie nicht auf Daten anderer Organisationen zu. Die Sicherheit auf Zeilenebene sollte das unmöglich machen, und wir würden wirklich gern erfahren, wenn sie es nicht tut.

Für eine Sicherheitsprüfung

Unser Auftragsverarbeitungsvertrag(auf Englisch) ist vollständig veröffentlicht, es gibt also nichts anzufordern. Sie brauchen für eine Sicherheitsprüfung noch etwas anderes, Fragebögen oder Architekturdetails? Schreiben Sie an security@getstandardos.com. Beantwortet innerhalb eines Werktags von StandardOS selbst, sodass die Antwort aus dem Code kommt und nicht aus einer Broschüre.

Siehe auch:Über uns Kontakt Änderungsprotokoll Ihre Aufzeichnungen prüfen

Diese Seite auf:English Français Nederlands Español Dansk