Skip to content
Trausto

Sicherheitsmodell

Sicherheitsmodell

Trausto reduziert geschäftliche Risiken rund um sensible Risikodaten, Lieferantennachweise und industrielle Sicherheitsentscheidungen. Das Sicherheitsmodell minimiert Datenabfluss, unterstützt Compliance-Nachweise, stärkt operative Resilienz und hält privilegiertes Projektwissen unter Kund:innenkontrolle.

Business Impact

Business-Risiken by Design reduziert

Das technische Modell hat einen geschäftlichen Zweck: weniger unkontrollierte Datenkopien, klarere Verantwortlichkeit und höhere Resilienz, wenn kritische Infrastruktur unter Druck steht.

BR1

Compliance-Nachweise ohne Oversharing

Teams können IEC 62443, NIS2, CRA und Datenschutz-Nachweise vorbereiten, ohne Klartext-Assessments über Tools, Exporte und Postfächer zu verteilen.

BR2

Data Leakage Prevention

Projektinhalte werden verschlüsselt, bevor sie den Browser verlassen. Server, Betreiber und Infrastrukturprovider werden nicht zu zusätzlichen Lesern sensibler OT-Risikoinformationen.

BR3

Operative Resilienz

Zugriffsentzug, Geräteverlust und Teamwechsel werden als kontrollierte Sicherheitsereignisse behandelt, nicht als manuelle Aufräumarbeit in kopierten Dateien.

BR4

Governance interner KI

Interne KI-Instanzen können mit expliziten Grenzen und Review-Trails eingebunden werden. Das reduziert das Risiko, dass sensibler Kontext in ungeführte Prompts oder Schatten-Workflows abfliesst.

So funktioniert es

Verschlüsselung in Kund:innenhand

Vier Prinzipien halten sensible Projektdaten unter Ihrer Kontrolle, ohne kollaborative Workflows zu brechen.

01

Zero-Knowledge, Ende zu Ende

Sämtliche Inhaltsverschlüsselung erfolgt clientseitig über die Web Crypto API; Ihre Assessments speichert der Server ausschliesslich als Chiffrat. Selbst auf Anordnung wäre Ihr Risiko-Inhalt für uns mathematisch unlesbar — mit genau einer Ausnahme, die wir benennen statt sie zu verschweigen: dem serverseitigen KI-Pfad, solange eine Anfrage läuft. Welche operativen Metadaten die Plattform zum Betrieb braucht, dokumentieren wir präzise — alles andere ist Chiffrat.

02

Hardware-gebundene Schlüssel

Schlüssel sind im Secure-Hardware-Modul des Geräts verankert (Secure Enclave, TPM oder Hardware-Token). Phishing-resistent, origin-gebunden, entsperrt ausschliesslich über eine hardware-gestützte WebAuthn-Zeremonie. Geht das Gerät verloren, gehen die Schlüssel mit.

03

Pro Projekt verschlüsselt

Jedes Projekt trägt einen eigenen Schlüssel, eingehüllt für jedes Teammitglied und jedes Gerät. Beitritt zu oder Verlassen eines Projekts ist eine kryptografische Operation, kein Flag in einer Datenbank.

04

Crypto-Shredding bei Löschung

Wird eine Person aus einem Projekt entfernt, wird dessen Schlüssel rotiert und neu eingehüllt; wird ein Gerät entfernt, wird die dort hinterlegte Schlüsselkopie stillgelegt — sie wird nicht mehr ausgeliefert, aber aufbewahrt. Beim Löschen eines Projekts fallen die Hüllen weg — genau das macht das Chiffrat unwiederbringlich; eine Projektlöschung ist kein „Soft-Delete" im kryptografischen Sinn. Was eine entfernte Partei bereits entschlüsselt und behalten hat, liegt ausserhalb der Reichweite jedes Anbieters; diese Grenze nennen wir lieber, als ein vollständiges Vergessen zu versprechen, das niemand einlösen kann.

Die verbleibende Vertrauensfläche

Was Sie uns trotzdem glauben müssen

Die Unlesbarkeits-Aussagen oben gelten dem, was bei uns liegt — nicht dem, was wir Ihnen ausliefern. Das Erste ist Mathematik, das Zweite ist Vertrauen. Deshalb steht hier vollständig, was Sie uns weiterhin glauben müssen — im selben Ton, in dem die Offenlegung darunter vollständig ist.

V1

Der Code, den wir ausliefern

Die Anwendung, die Ihre Schlüssel anfasst, liefern wir in Ihren Browser aus — und wer ausliefert, könnte eine veränderte Fassung ausliefern. Eine Anordnung, die in die Zukunft zielt, trifft nicht das gespeicherte Chiffrat, sondern künftige Auslieferungen. Unser Auslieferungsweg ist intern abgesichert: Deployt wird nur ein Stand, der auf der Hauptlinie liegt und den vollen Testlauf bestanden hat, und Abhängigkeiten sind festgepinnt. Aber einen Mechanismus, mit dem SIE unabhängig prüfen könnten, dass der ausgelieferte Code der beschriebene ist, gibt es heute nicht.

V2

Die Wiederherstellungsphrase der Organisation

Die optionale Wiederherstellungsphrase der Organisation hebt gewollt die Endgültigkeit auf, auf der alles Übrige hier beruht: Wer sie hält, erreicht die Projekte ihrer Berechtigungskette. Das ist der Preis dafür, dass eine Organisation den Zugang behält, wenn eine Person geht — und der Grund, warum sie optional ist und in Ihrer Verwahrung liegt, nicht in unserer. Ersetzen lässt sie sich jederzeit; damit die ersetzte Phrase auch kryptografisch wirkungslos wird, gehört eine Rotation der Organisationsschlüssel dazu.

V3

Der serverseitige KI-Pfad

Die eine benannte Ausnahme, in der Inhalt im Klartext durch unseren Worker läuft. Er ist optional, er ist die einzige Klartext-Zeile in der Offenlegung darunter — und die Bauprüfung dieser Website erzwingt, dass es genau eine bleibt.

Expert Deep Dive

Technische Tiefe — veröffentlicht

Für Architekturteams gibt es ein technisches Whitepaper: Schlüsselmodell, zweckgebundene AAD, Bedrohungsmodell, Post-Quantum-Stand und die offenen Punkte — im Dokument selbst benannt. Version 1.1, 12. August 2026. Noch nicht extern begutachtet; die Begutachtung ist einer von drei Nachweisschritten, und das steht auf Seite eins.

  • Clientseitige Verschlüsselung · kein lesbarer Risiko-Inhalt auf Datenträgern
  • Hardware-gebundene Geräteschlüssel · phishing-resistent
  • Offline-Recovery bei Geräteverlust
  • Pro-Projekt-Schlüssel mit kryptografischer Mitgliedschaft
  • Schlüsselrotation bei Entzug — auf Projektebene inklusive bestehendem Chiffrat, auf Organisationsebene durch eine Administratorin angestossen

Einblick

Was wir sehen — und was nicht

Trausto läuft als SaaS, betrieben aus der Schweiz. Das ist das ganze Angebot: Es gibt keine On-Premise-Ausgabe zu prüfen und keine Betriebsmodell-Matrix zu verhandeln. Der Grund ist, dass die Frage, für die es Eigenbetrieb überhaupt gibt — wer Ihre Assessments lesen kann —, vorher und deutlicher beantwortet wird: im Browser, bevor irgendetwas bei uns ankommt.

01

Ein Betriebsmodell

Mandantenfähige SaaS, von einem Schweizer Unternehmen gebaut und aus der Schweiz betrieben, auf gehärteter Cloud-Infrastruktur. Ein Codepfad, ein Satz Kontrollen, eine Sache zum Prüfen — für Sie und für uns. Onboarding dauert Tage, keinen Beschaffungszyklus.

02

Trennung, auf die man zeigen kann

Jedes Projekt trägt einen eigenen Schlüssel, eingehüllt für jedes Teammitglied und jedes Gerät. Die Trennung wird kryptografisch durchgesetzt, nicht bloss über einen Filter in der Abfrage — Zugriff zu verlieren ist eine Schlüsseloperation, kein Flag in einer Tabelle. Die Organisation ist die Einheit, mit der Sie den Vertrag schliessen und die abgerechnet wird und die eine Wiederherstellungsphrase hinterlegen kann; das Projekt ist die kryptografische Einheit.

03

Was bei uns liegt

Chiffrat, dazu die operativen Metadaten, die der Dienst zum Laufen braucht: wer ein Konto hat, zu welchem Projekt ein Datensatz gehört, wann er zuletzt geändert wurde, wie viel Speicher Sie belegen. Diese Fläche schlüsseln wir unten auf, statt sie wegzureden.

Offenlegung

Die Metadaten-Fläche, aufgeschlüsselt

Verschlüsselung ist ein halbes Versprechen, solange nicht dasteht, was unverschlüsselt bleibt. Hier ist die andere Hälfte.

14 Positionen. An genau 1 davon wird Inhalt im Klartext verarbeitet — auf einem Abzweig, den Sie nicht nehmen müssen.

14
Positionen legen wir offen. Alle stehen unten; nichts ist zusammengefasst.
1
Pfad, auf dem Inhalt im Klartext durch unseren Worker geht: der serverseitige KI-Assistent. Er ist optional.
10
Positionen bleiben im Betrieb bei uns lesbar. Sie sagen, wer, wann und wie viel — keine davon trägt einen Satz aus einer Risikoanalyse.

Was passiert mit Ihrer Risikoanalyse?

Alles, was Sie eingeben, alles, was Sie hochladen, und die Schlüssel dazu. Das ist die Antwort auf die Frage, mit der Sie gekommen sind.

Assessment-Inhalte

Nein — nur Chiffrat

Assets, Zonen, Conduits, Szenarien und Nachweise werden auf Ihrem Gerät verschlüsselt, bevor sie hochgeladen werden. Die eine Ausnahme ist der serverseitige KI-Pfad weiter unten.

Hochgeladene Nachweise

Nein — nur Chiffrat

Lieferantendokumente und Anhänge nehmen denselben Weg wie die Assessment-Inhalte.

Die eine Ausnahme

KI-Verarbeitung

Ja, für die Dauer der Anfrage

nur bei Nutzung des serverseitigen KI-Pfads

Wer den serverseitigen KI-Assistenten nutzt, schickt den Inhalt genau dieser Anfrage im Klartext durch unseren Worker zum konfigurierten Provider — Ihrem eigenen Endpoint oder, falls hinterlegt, einem plattformweiten Standard, den Ihre Organisation abschalten kann. Das Modell im Browser laufen zu lassen vermeidet das — genau dafür gibt es die Möglichkeit.

Schlüsselmaterial

Nein — nur eingehüllt

Ihr privater Schlüssel wird je Gerät einzeln vom Sicherheitsmodul des Geräts eingehüllt; Ihre persönliche Wiederherstellungsphrase und die optionale der Organisation entstehen in Ihrem Browser und verlassen ihn nie im Klartext. Bei uns liegen ausschliesslich eingehüllte Formen.

Reichweite

Ein Organisationsschlüssel kann die Projekte seiner Berechtigungskette aufschliessen — so behält eine Organisation den Zugang, wenn eine Person geht, und so weit reicht damit auch die Wiederherstellungsphrase.

Was bleibt bei uns lesbar, damit der Dienst läuft?

10 von 14 Positionen. Sie fallen an, weil die Software gehostet läuft, mehrere Personen darin arbeiten und am Ende ein Nachweis daraus entstehen soll. Namen, Zeitpunkte, Zählerstände.

Was bleibt bei uns lesbar, damit der Dienst läuft?
Position Bei uns lesbar Wie lange Wozu es existiert
Konto-Identität Ja Name und geschäftliche E-Mail. Nötig, um Sie zu authentifizieren und im Support anzusprechen.
Projektzugehörigkeit Ja — Struktur, nicht Inhalt Welcher Datensatz zu welchem Projekt gehört und wer Zugriff hat. Das steuert, wer abrufen kann; lesbar wird der Inhalt erst durch den Projektschlüssel.
Zeitstempel Ja Erstellungs- und Änderungszeit, damit gleichzeitiges Arbeiten und Versionsverlauf funktionieren.
Audit-Log Ja 90 Tage (Standard) · Langzeitarchiv ist der SIEM-Export Wer wann was getan hat. Notwendig für genau die Nachweiskette, für die es das Produkt gibt.
Nutzungsvolumen Ja Belegter Speicher und Anzahl Datensätze, für Abrechnung und Kapazität.
Geräte- und Sitzungsmetadaten Ja Sitzungen 30 Tage gültig, Zeilen nach 90 Tagen gelöscht · Geräteeinträge werden stillgelegt, nicht gelöscht Je Gerät: der von Ihnen vergebene Gerätename im Klartext, sein öffentlicher Schlüssel, das Anlagedatum und der Zeitpunkt des letzten Schlüsselabrufs; entfernte Geräte werden stillgelegt, nicht gelöscht. Je Sitzung: Browser-Kennung, ein IP-Präfix — nie die volle Adresse — und welches Gerät die Sitzung eröffnet hat.
E-Mail-Versand Ja — Versand über Mailgun (EU-Region) Registrierungs- und Wiederherstellungscodes, Einladungen und Kontoänderungs-Hinweise gehen über den Versanddienst Mailgun. In diesen Mails stehen: Bestätigungscodes, Gerätename, Organisationsname (auch im Betreff), Rolle und die Adresse der handelnden Person; bei einer Adressänderung erfährt die alte Adresse die neue. Empfängeradressen und Mail-Metadaten liegen damit auch beim Versanddienst.
Support- und Administrationszugriff Ja — auf Metadaten, nie auf Inhalte Plattform-Administratoren können Mitgliederlisten samt E-Mail-Adressen, Audit-Logs und Nutzungsstatistiken einsehen; Assessment-Inhalte nicht — die liegen auch bei uns nur als Chiffrat. Schreibende Admin-Zugriffe stehen im Audit-Log; lesende werden dort heute nicht einzeln erfasst.
KI-Betriebstelemetrie Ja — Metadaten nur bei Nutzung des serverseitigen KI-Pfads 90 Tage (Standard), als Teil des Audit-Logs Welcher Provider aufgerufen wurde, ob es fehlschlug und wie lange es dauerte. Kein Anfrageinhalt.
SIEM-Export Ja — Audit-Metadaten nur bei eingerichtetem Webhook Richtet Ihre Organisation einen SIEM-Webhook ein, gehen Audit-Ereignisse an den von Ihnen benannten Endpunkt. Assessment-Inhalte sind nicht Teil dieses Stroms.
Dieselbe Offenlegung als eine Tabelle — zum Kopieren in Ihren Lieferantenfragebogen
Dieselbe Offenlegung als eine Tabelle — zum Kopieren in Ihren Lieferantenfragebogen
Position Bei uns lesbar Wie lange Wozu es existiert
Assessment-Inhalte Nein — nur Chiffrat Assets, Zonen, Conduits, Szenarien und Nachweise werden auf Ihrem Gerät verschlüsselt, bevor sie hochgeladen werden. Die eine Ausnahme ist der serverseitige KI-Pfad weiter unten.
Hochgeladene Nachweise Nein — nur Chiffrat Lieferantendokumente und Anhänge nehmen denselben Weg wie die Assessment-Inhalte.
KI-Verarbeitung Ja, für die Dauer der Anfrage nur bei Nutzung des serverseitigen KI-Pfads Wer den serverseitigen KI-Assistenten nutzt, schickt den Inhalt genau dieser Anfrage im Klartext durch unseren Worker zum konfigurierten Provider — Ihrem eigenen Endpoint oder, falls hinterlegt, einem plattformweiten Standard, den Ihre Organisation abschalten kann. Das Modell im Browser laufen zu lassen vermeidet das — genau dafür gibt es die Möglichkeit.
Schlüsselmaterial Nein — nur eingehüllt Ihr privater Schlüssel wird je Gerät einzeln vom Sicherheitsmodul des Geräts eingehüllt; Ihre persönliche Wiederherstellungsphrase und die optionale der Organisation entstehen in Ihrem Browser und verlassen ihn nie im Klartext. Bei uns liegen ausschliesslich eingehüllte Formen. Ein Organisationsschlüssel kann die Projekte seiner Berechtigungskette aufschliessen — so behält eine Organisation den Zugang, wenn eine Person geht, und so weit reicht damit auch die Wiederherstellungsphrase.
Konto-Identität Ja Name und geschäftliche E-Mail. Nötig, um Sie zu authentifizieren und im Support anzusprechen.
Projektzugehörigkeit Ja — Struktur, nicht Inhalt Welcher Datensatz zu welchem Projekt gehört und wer Zugriff hat. Das steuert, wer abrufen kann; lesbar wird der Inhalt erst durch den Projektschlüssel.
Zeitstempel Ja Erstellungs- und Änderungszeit, damit gleichzeitiges Arbeiten und Versionsverlauf funktionieren.
Audit-Log Ja 90 Tage (Standard) · Langzeitarchiv ist der SIEM-Export Wer wann was getan hat. Notwendig für genau die Nachweiskette, für die es das Produkt gibt.
Nutzungsvolumen Ja Belegter Speicher und Anzahl Datensätze, für Abrechnung und Kapazität.
Geräte- und Sitzungsmetadaten Ja Sitzungen 30 Tage gültig, Zeilen nach 90 Tagen gelöscht · Geräteeinträge werden stillgelegt, nicht gelöscht Je Gerät: der von Ihnen vergebene Gerätename im Klartext, sein öffentlicher Schlüssel, das Anlagedatum und der Zeitpunkt des letzten Schlüsselabrufs; entfernte Geräte werden stillgelegt, nicht gelöscht. Je Sitzung: Browser-Kennung, ein IP-Präfix — nie die volle Adresse — und welches Gerät die Sitzung eröffnet hat.
E-Mail-Versand Ja — Versand über Mailgun (EU-Region) Registrierungs- und Wiederherstellungscodes, Einladungen und Kontoänderungs-Hinweise gehen über den Versanddienst Mailgun. In diesen Mails stehen: Bestätigungscodes, Gerätename, Organisationsname (auch im Betreff), Rolle und die Adresse der handelnden Person; bei einer Adressänderung erfährt die alte Adresse die neue. Empfängeradressen und Mail-Metadaten liegen damit auch beim Versanddienst.
Support- und Administrationszugriff Ja — auf Metadaten, nie auf Inhalte Plattform-Administratoren können Mitgliederlisten samt E-Mail-Adressen, Audit-Logs und Nutzungsstatistiken einsehen; Assessment-Inhalte nicht — die liegen auch bei uns nur als Chiffrat. Schreibende Admin-Zugriffe stehen im Audit-Log; lesende werden dort heute nicht einzeln erfasst.
KI-Betriebstelemetrie Ja — Metadaten nur bei Nutzung des serverseitigen KI-Pfads 90 Tage (Standard), als Teil des Audit-Logs Welcher Provider aufgerufen wurde, ob es fehlschlug und wie lange es dauerte. Kein Anfrageinhalt.
SIEM-Export Ja — Audit-Metadaten nur bei eingerichtetem Webhook Richtet Ihre Organisation einen SIEM-Webhook ein, gehen Audit-Ereignisse an den von Ihnen benannten Endpunkt. Assessment-Inhalte sind nicht Teil dieses Stroms.

Offenlegung, Stand 2026-08-12. Jede Position wird vor dem Start gegen die Implementierung bestätigt; was nicht bestätigt ist, fliegt raus statt abgeschwächt zu werden.

Die Kette

Wer sonst verarbeitet — und was er sieht

Eine Aussage über „Hosting-Anbieter und Dritte" ist nur prüfbar, wenn sie benannt sind. Das sind alle externen Dienste, die die Plattform berührt — am Code belegt, nicht behauptet.

Wer sonst verarbeitet — und was er sieht
Dienstleister Zweck Was er sieht In wessen Auftrag
Cloudflare Hosting und Speicher der Plattform (Compute, Datenbank, Objektspeicher, Key-Value-Store). Chiffrat, die oben aufgeschlüsselten Metadaten und Betriebslogs der Worker. unserem — unser Unterauftragsverarbeiter
Mailgun (EU-Region) Transaktionale E-Mails — Registrierungs- und Wiederherstellungscodes, Einladungen, Konto-Hinweise. Empfängeradressen und die in der Offenlegung genannten Mailinhalte. unserem — unser Unterauftragsverarbeiter
KI-Provider Ihrer Wahl Verarbeitet serverseitig geroutete KI-Anfragen gegen den konfigurierten Endpoint — Ihren eigenen oder, falls hinterlegt, einen plattformweiten Standard, den Ihre Organisation abschalten kann. Den Klartext der einen Anfrage — die eine Ausnahme aus der Offenlegung. Ihrem — kommt erst durch Ihre Konfiguration in die Kette
Ihr SIEM-Endpunkt Empfängt Audit-Ereignisse, wenn Ihre Organisation einen Webhook einrichtet. Audit-Metadaten. Assessment-Inhalte sind nicht Teil dieses Stroms. Ihrem — kommt erst durch Ihre Konfiguration in die Kette
Ihr Identity-Provider Föderierte Anmeldung (Enterprise SSO), sofern konfiguriert. Belegt Identität; er entpackt nie einen Schlüssel. Dass eine Anmeldung stattfand. Keine Inhalte, kein Schlüsselmaterial. Ihrem — kommt erst durch Ihre Konfiguration in die Kette

Für die Website selbst (trausto.com) gelten Cloudflare Pages und Resend — sie stehen in der Datenschutzerklärung. Der Verarbeitungsort der Plattformdaten wird hier genannt, sobald er festgelegt ist.

IEC 62443

IEC 62443-3-3 · Grundforderungen

Die sieben Grundforderungen der IEC 62443-3-3. Trausto führt sie als eigene Objekte: Sie ordnen die Kontrollen und Nachweise IHRER Anlage jeder einzelnen zu und exportieren das Ergebnis. Das ist die Struktur, in der Sie arbeiten — keine Aussage über eine Zertifizierung unserer eigenen Plattform.

  1. FR1

    FR1 — Identifikations- und Authentisierungskontrolle

  2. FR2

    FR2 — Nutzungskontrolle

  3. FR3

    FR3 — Systemintegrität

  4. FR4

    FR4 — Datenvertraulichkeit

  5. FR5

    FR5 — Eingeschränkter Datenfluss

  6. FR6

    FR6 — Reaktion auf Ereignisse

  7. FR7

    FR7 — Ressourcenverfügbarkeit

Compliance

Schweizer Compliance-Haltung

Ausgerichtet auf revDSG/nDSG, DSGVO-Datenminimierung, EU CRA, NIS2 und ENISA-Leitlinien zur industriellen Cybersicherheit. Da Assessment-Inhalte verschlüsselt werden, bevor sie den Browser der Kund:innen verlassen, ist der Betriebsort eine Frage von Resilienz und Rechtsordnung, keine der Vertraulichkeit — deshalb genügt ein einziges Betriebsmodell mit einer Schweizer Gegenstelle. Wo die ruhenden Daten liegen, ist damit nicht gesagt; diese Angabe steht in der Dienstleisterkette, sobald sie festgelegt ist. Eine behördliche Anordnung an uns kann keine lesbaren Assessments hervorbringen: Bei uns existieren sie ausschliesslich als Chiffrat — ausserhalb des serverseitigen KI-Pfads, der optional ist und in der Offenlegung als einzige Klartext-Zeile steht. Sie kann die operativen Metadaten erreichen, mit denen wir den Dienst betreiben — genau deshalb dokumentieren wir diese Fläche, statt sie wegzureden.

  • revDSG / nDSG — Schweizer Datenschutz
  • DSGVO — Datenminimierung durch Verschlüsselung
  • EU Cyber Resilience Act (CRA) — ausgerichtet
  • NIS2 / KRITIS / KRITIS-DachG-Vokabular
  • ENISA-Leitlinien zur industriellen Cybersicherheit

Trausto an Ihren eigenen Zonen sehen

Bringen Sie einen realen Standort mit — Ihre Zonen, Conduits und Security-Level-Ziele (SL-T). In einer technischen Session zeigen wir, wie Trausto daraus prüffähige IEC-62443-Nachweise macht — Ihre Assessment-Inhalte werden verschlüsselt, bevor sie den Browser verlassen.