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.

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 → (auf Englisch)
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 jeder Datensatz in einer Hash-Kette liegt 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

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. 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; einen Löschpfad gibt es für niemanden.
Tägliche Verankerung
Jede Nacht halten wir den Kopf jeder Kette fest und senden ihn am folgenden Morgen (07:00 UTC) per E-Mail an die Inhaber und Administratoren der Organisation. Sobald eine Quittung in Ihrem Postfach liegt, liegt sie auf einem Server, den wir nicht betreiben; ein späteres Umschreiben ergäbe einen Kopf, der nicht mehr zu dem passt, den Sie bereits haben. Die Tageswurzeln werden zudem offen veröffentlicht, damit sie jeder archivieren kann. Das macht Manipulation nicht unmöglich. Es macht sie für jemanden erkennbar, der seine Post behalten hat. Die veröffentlichten Tageswurzeln → (auf Englisch)
Überprüfbarkeit
Exporte enthalten die Hashes und die Inhalte, über die sie berechnet wurden, dazu die genaue Hash-Regel. 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-07-28.

AnbieterRolleOrt der Verarbeitung
SupabaseDatabase, authentication, file storageEU (Ireland)
VercelApplication hosting & delivery; cookieless traffic analytics (no cookies, no cross-site identifiers)EU serving; global CDN for static assets
SentryError monitoring, diagnostics only; email addresses, IP addresses and record identifiers are stripped before events leave our serversEU region (Frankfurt)
PaddleMerchant of record: checkout, payment, VAT & invoicing (card data never touches our servers)UK, under the EU adequacy decision
ResendTransactional emailEU region

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.

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 den Leuten, die das Produkt bauen, sodass die Antwort aus dem Code kommt und nicht aus einer Broschüre.