OSOS/Omega← Back

Zertifikats- und Sicherheits-Hinweise

Produkt: OSOS / Omega

Anbieter: Osos AI GmbH, Cosimastraße 121, 81925 München, Germany

Stand: 12.06.2026

Version: 1.1

Verhältnis zu anderen Dokumenten: Diese Hinweise sind Anlage zum EULA und konkretisieren – gemeinsam mit der TOM-Anlage des AVV und der AI Data Policy – die vom Anbieter implementierten Sicherheits- und Compliance-Maßnahmen.

> Hinweis: Dieses Dokument informiert transparent über Status, Geltungsbereich und Nachweisbarkeit der genannten Standards. Die Aufnahme einer Norm bedeutet keine eigenständige vertragliche Garantie über den im Hauptvertrag vereinbarten Leistungsumfang hinaus, soweit nicht ausdrücklich anders gekennzeichnet ("Stand"-Angaben).

> Status-Legende:implementiert (aktiv, auf Anfrage belegbar) · 🗓 geplant (Roadmap, ohne Zeitzusicherung). Zertifizierungen werden ausschließlich als Roadmap-Status ausgewiesen. Die aktiv implementierten Maßnahmen sind in Abschnitt 4 aufgeführt.


1. Compliance-Status & Roadmap

Standard / Norm Status Anmerkung
ISO/IEC 27001 (ISMS) 🗓 geplant Unsere Sicherheitskontrollen sind an ISO 27001 ausgerichtet. Der formale ISMS-Aufbau und die Zertifizierung sind geplant, sobald entsprechender Kundenbedarf besteht – ohne Zeitzusicherung.
ISO/IEC 42001 (AI Management System) 🗓 geplant Die Entwicklung unserer KI-Komponenten ist an den Prinzipien der Norm ausgerichtet (Human Oversight, Transparenz der Modell-Provider). Ein zertifiziertes AI-Management-System betreiben wir noch nicht.
SOC 2 Type II 🗓 geplant (nach ISO 27001) Es liegt kein SOC-2-Bericht vor. Eine SOC-2-Prüfung ist nach Aufbau des ISMS vorgesehen.
TISAX® (Automotive Information Security) 🗓 geplant (bei Kundenbedarf) Für Automotive-Kunden vorgesehen; baut auf demselben ISMS auf (VDA-ISA ≈ ISO 27001 + Automotive-Zusätze).
ISO/IEC 27017 / 27018 / 27701 über Hosting-Provider adressiert Cloud-, PII- und Privacy-Kontrollen werden auf Infrastrukturebene durch die Zertifizierungen unserer Hosting-Provider abgedeckt (siehe Subprocessor-Liste); eine eigene Zertifizierung besteht nicht.
EU AI Act (VO (EU) 2024/1689) adressiert Konformitätsdokumentation entsprechend Risikoklassifikation, siehe AI Data Policy.
DSGVO / BDSG adressiert AVV inkl. TOM-Anlage und Subprocessor-Liste.

> Den jeweils aktuellen Stand veröffentlichen wir im Trust Center. Die Zertifikate unserer Hosting- und Modell-Provider stellen wir interessierten Kunden im Rahmen eines Security-Pakets auf Anfrage bereit.


2. Erläuterungen zu den einzelnen Standards

2.1 ISO/IEC 27001 – Information Security Management System (ISMS)

ISO/IEC 27001 spezifiziert Anforderungen an ein etabliertes Information Security Management System (Risikoanalyse und -behandlung, Sicherheitsleitlinien, Asset-Management, Zugriffskontrollen, Kryptografie, Betriebs- und Lieferantensicherheit, Incident-Management, Business Continuity, interne und externe Audits).

Wir richten unsere technischen und organisatorischen Kontrollen an dieser Norm aus. Ein formal dokumentiertes ISMS und eine Zertifizierung durch eine akkreditierte Stelle bestehen noch nicht; ihr Aufbau ist geplant (siehe Abschnitt 1). Bis dahin verweisen wir auf die in Abschnitt 4 aufgeführten, belegbaren Maßnahmen.

2.2 ISO/IEC 27017 und ISO/IEC 27018

ISO/IEC 27017 erweitert ISO 27001 um cloud-spezifische Sicherheitskontrollen; ISO/IEC 27018 ergänzt Maßnahmen zum Schutz personenbezogener Daten (PII) in Public-Cloud-Umgebungen. Diese Kontrollen werden auf Infrastrukturebene durch unsere Hosting-Provider abgedeckt, deren Zertifizierungen wir auf Anfrage nachweisen. Eine eigene Zertifizierung nach diesen Normen führen wir nicht.

2.3 ISO/IEC 27701 – Privacy Information Management System (PIMS)

ISO/IEC 27701 erweitert ISO 27001/27002 um ein Datenschutz-Managementsystem. Eine eigene PIMS-Zertifizierung besteht nicht; die Datenschutzanforderungen adressieren wir über den AVV, die TOM-Anlage und die in Abschnitt 4 genannten Maßnahmen.

2.4 ISO/IEC 42001 – AI Management System

ISO/IEC 42001 ist die erste internationale Norm für KI-Management-Systeme (verantwortungsvolle Entwicklung, Risiko-Management, Transparenz, Human Oversight, Bias-Management). Wir richten die Entwicklung unserer KI-Komponenten an diesen Prinzipien aus – insbesondere an der Human-in-the-Loop-Freigabe und der transparenten Benennung der Modell-Provider (siehe AI Data Policy). Ein zertifiziertes AI-Management-System betreiben wir noch nicht.

2.5 SOC 2 Type II

SOC 2 (Service Organization Control 2) Type II ist ein US-Auditstandard nach AICPA, der die operative Wirksamkeit von Kontrollen über einen Beobachtungszeitraum bescheinigt. Uns liegt derzeit kein SOC-2-Bericht vor. Eine SOC-2-Prüfung ist nach dem Aufbau des ISMS (ISO 27001) vorgesehen.

2.6 TISAX® – Trusted Information Security Assessment Exchange

TISAX® ist der von der Automobilindustrie (ENX Association / VDA-ISA) etablierte Branchenstandard für Informationssicherheit. Wir besitzen kein TISAX-Label. Da unsere Zielkunden OEMs und Supplier umfassen, ist ein TISAX-Assessment bei entsprechendem Kundenbedarf vorgesehen; es baut auf demselben ISMS-Fundament auf.

2.7 EU AI Act

Verordnung (EU) 2024/1689 (EU AI Act) regelt das Inverkehrbringen und den Einsatz von KI-Systemen in der EU. Der Anbieter dokumentiert die Konformität von OSOS / Omega entsprechend der jeweiligen Risikoklassifikation. Sofern der Lizenznehmer die Software in einem regulierten Hochrisiko-Kontext einsetzt, stellt der Anbieter auf Anfrage die hierfür erforderliche und ihm zugängliche Provider-Dokumentation (z.B. nach Art. 11, 13 AI Act, etwa zu den zugrundeliegenden Modellen) bereit. Details: AI Data Policy.

2.8 DSGVO / BDSG

Für die Verarbeitung personenbezogener Daten im Auftrag des Lizenznehmers gilt der Auftragsverarbeitungsvertrag (AVV) inklusive der TOM-Anlage und der Subprocessor-Liste. Im Übrigen werden die Anforderungen aus DSGVO und BDSG durch die in Abschnitt 4 genannten technischen und organisatorischen Maßnahmen adressiert.


3. Hosting, Verarbeitungsregionen und Subprocessor

3.1 Hosting

Anwendung und Datenbank werden innerhalb der Europäischen Union betrieben: Anwendung und Container bei Hetzner (Deutschland), Datenbank und Datei-Speicher bei Supabase (EU-Region). Eine Verarbeitung außerhalb der EU findet nur für die KI-Inferenz bei benannten Modell-Providern statt; die zugehörigen Transfer-Mechanismen sind in der Subprocessor-Liste ausgewiesen.

3.2 Verarbeitungsregion

Standard-Verarbeitungsregion für Kunden mit Sitz im EWR ist die Europäische Union. Die Option eines vollständig drittlandsfreien KI-Inferenz-Betriebs (EU-only) ist produktabhängig und bedarf einer gesonderten Vereinbarung im Order Form.

3.3 Subprocessor

Die jeweils aktuelle Liste aller Sub-Auftragsverarbeiter (inkl. KI-Subdienstleister, Hosting, Zahlungsabwicklung, E-Mail-Versand) mit Sitz, Zweck, Datenkategorien, Verarbeitungsregion und Transfer-Mechanismus ist abrufbar unter /legal/trust/subprocessors. Notifikations- und Widerspruchsrechte ergeben sich aus dem AVV.


4. Zentrale Sicherheitsmechanismen

Die folgenden Maßnahmen sind aktiv implementiert und ergänzen die in der TOM-Anlage zum AVV aufgeführten Maßnahmen. Alle Angaben sind auf Anfrage belegbar.

4.1 ✅ Implementiert

  • EU-Hosting: Anwendung und Datenbank in der EU (Hetzner DE, Supabase EU-Region); keine Verarbeitung außerhalb der EU außer der KI-Inferenz bei benannten Modell-Providern.
  • Verschlüsselung: in transit über TLS (Traefik / Let's Encrypt); at rest provider-seitig (AES-256).
  • Passwortlose Authentifizierung: Supabase OTP / Magic-Link (PKCE); kein Passwort-Handling im eigenen Code. Einheitliches Session-Gating in der Edge-Middleware.
  • Default-Deny am Edge: Pfad-Allowlist, HTTP-Methoden-Filter, musterbasierte Blockierung bekannter Scanner-/Angriffsmuster, IP-Rate-Limit.
  • Mandantentrennung je Company auf Anwendungs- und Datenbankebene; Row Level Security (RLS) auf allen Tabellen als zusätzliche Verteidigungslinie; verriegelte Storage-Buckets.
  • Kein KI-Training auf Kundendaten – vertraglich ausgeschlossen (AI Data Policy, Ziffer 3.1); Zugriff auf Modell-Provider ausschließlich über APIs.
  • Human-in-the-Loop: KI-generierte Inhalte sind grundsätzlich pending und werden einzeln, ausschließlich über die Benutzeroberfläche, von einem Menschen freigegeben – keine Sammelfreigabe, keine Freigabe über den Chat.
  • Append-only Audit-Trail für administrative Eingriffe und Subscription-Lifecycle.
  • Kontrollierte Bereitstellung (Deployment): verpflichtendes Staging vor Produktion, automatisches Datenbank-Backup vor jeder Schema-Aktualisierung in einen verriegelten Bucket, blockierende Qualitäts-Gates (Tests, Typprüfung, Lint), Ausführung ohne Root-Rechte im Container.
  • Webhook-Sicherheit: Signaturprüfung (Stripe) über den Raw-Body, Idempotenz über Unique-Constraint.
  • Responsible Disclosure: security.txt nach RFC 9116 mit dediziertem Security-Kontakt (siehe Abschnitt 7).

4.2 🗓 Auf der Roadmap (häufige Anforderungen aus Security- und Beschaffungs-Fragebögen)

  • HTTP-Security-Header (HSTS, CSP, X-Frame-Options, Referrer-Policy).
  • Automatisiertes Dependency- und Code-Scanning (Dependabot, CodeQL).
  • Definierte RPO/RTO und dokumentierter, regelmäßiger Restore-Test.
  • Zentrales Auth-Event-Logging (fehlgeschlagene Logins) und Alerting.
  • Öffentliche, live aktualisierte Status-Page.
  • Externer Penetrationstest (vor General Availability).
  • Single Sign-On (SAML 2.0 / OIDC) und erzwungene MFA.
  • Dokumentiertes Incident-Response-Runbook mit Eskalations- und Meldewegen.

Nicht implementiert sind derzeit: ein dediziertes Key-Management-System, kundenseitig verwaltete Schlüssel ("Customer-Managed Keys"), geo-redundante Backups sowie ein Bug-Bounty-Programm.


5. Branchenspezifische Hinweise (informativ)

OSOS / Omega unterstützt Engineering-Prozesse nach gängigen branchenspezifischen Normen. Die nachfolgende Aufstellung dient der Orientierung; eine eigenständige Tool-Qualifikation ("Tool Confidence Level") wird vom Anbieter nicht vorgenommen, soweit nicht separat vereinbart (vgl. EULA Ziffer 17).

  • Automotive: Automotive SPICE, ISO 26262 (Functional Safety), ISO/SAE 21434 (Cybersecurity Engineering), IATF 16949;
  • Aerospace: DO-178C, DO-254, ARP4754A;
  • Medical Devices: IEC 62304, ISO 13485, ISO 14971;
  • Railway: EN 50128, EN 50657;
  • Industrial: IEC 61508.

Zur Unterstützung von Tool-Qualifikationsprozessen stellt der Anbieter auf Anfrage und gegen Vergütung relevante Dokumentation (z.B. Tool Operational Requirements, Use Cases, Prüfprotokolle) bereit.


6. Aktualität und Änderungen

Status und Geltungsbereich der hier genannten Standards und Maßnahmen werden regelmäßig aktualisiert. Die jeweils aktuelle Fassung ist über das Trust Center abrufbar. Statusübergänge (🗓 → ✅) und wesentliche Änderungen am Compliance-Stand teilen wir Lizenznehmern mit aktivem Hauptvertrag auf geeignetem Wege mit (z.B. Trust-Center-Update, E-Mail an benannte Ansprechpartner).


7. Kontakt und Trust Center