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.
| Anbieter | Rolle | Ort der Verarbeitung |
|---|---|---|
| Supabase | Database, authentication, file storage | EU (Ireland) |
| Vercel | Application hosting & delivery; cookieless traffic analytics (no cookies, no cross-site identifiers) | 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 | EU region (Frankfurt) |
| Paddle | Merchant of record: checkout, payment, VAT & invoicing (card data never touches our servers) | UK, under the EU adequacy decision |
| Resend | Transactional email | EU 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.