OSOS/Omega← Back

Certificates and Security Notes

Product: OSOS / Omega

Provider: Osos AI GmbH, Cosimastraße 121, 81925 Munich, Germany

Effective Date: 12.06.2026

Version: 1.1

Relationship to other documents: These notes are an annex to the EULA and concretize — together with the TOM annex of the DPA and the AI Data Policy — the security and compliance measures implemented by the Provider.

> Note: This document transparently informs about the status, scope, and verifiability of the standards listed. The inclusion of a standard does not constitute an independent contractual guarantee beyond the scope of services agreed in the Main Agreement, unless expressly indicated otherwise ("Status" entries).

> Status legend:implemented (active, verifiable on request) · 🗓 planned (roadmap, no time commitment). Certifications are shown as roadmap status only. The controls currently in place are listed in Section 4.


1. Compliance Status & Roadmap

Standard / Norm Status Note
ISO/IEC 27001 (ISMS) 🗓 planned Our security controls are aligned with ISO 27001. The formal build-out of the ISMS and certification are planned once customer demand warrants it — without a time commitment.
ISO/IEC 42001 (AI Management System) 🗓 planned The development of our AI components is aligned with the standard's principles (human oversight, transparency about model providers). We do not yet operate a certified AI management system.
SOC 2 Type II 🗓 planned (after ISO 27001) No SOC 2 report exists. A SOC 2 audit is envisaged after the ISMS is in place.
TISAX® (Automotive Information Security) 🗓 planned (on customer demand) Envisaged for automotive customers; builds on the same ISMS (VDA-ISA ≈ ISO 27001 + automotive add-ons).
ISO/IEC 27017 / 27018 / 27701 addressed via hosting providers Cloud, PII, and privacy controls are covered at the infrastructure level by our hosting providers' certifications (see subprocessor list); we hold no own certification under these standards.
EU AI Act (Reg. (EU) 2024/1689) addressed Conformity documentation per risk classification, see AI Data Policy.
GDPR / BDSG addressed DPA incl. TOM annex and subprocessor list.

> We publish the current status in the Trust Center. The certificates of our hosting and model providers are made available to interested customers on request as part of a security package.


2. Notes on Individual Standards

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

ISO/IEC 27001 specifies requirements for an established Information Security Management System (risk analysis and treatment, security policies, asset management, access controls, cryptography, operations and supplier security, incident management, business continuity, internal and external audits).

We align our technical and organizational controls with this standard. A formally documented ISMS and certification by an accredited body do not yet exist; their build-out is planned (see Section 1). Until then, we point to the verifiable measures listed in Section 4.

2.2 ISO/IEC 27017 and ISO/IEC 27018

ISO/IEC 27017 extends ISO 27001 with cloud-specific security controls; ISO/IEC 27018 adds measures for the protection of personal data (PII) in public cloud environments. These controls are covered at the infrastructure level by our hosting providers, whose certifications we evidence on request. We do not hold our own certification under these standards.

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

ISO/IEC 27701 extends ISO 27001/27002 with a privacy management system. We hold no own PIMS certification; we address the privacy requirements via the DPA, the TOM annex, and the measures in Section 4.

2.4 ISO/IEC 42001 – AI Management System

ISO/IEC 42001 is the first international standard for AI management systems (responsible development, risk management, transparency, human oversight, bias management). We align the development of our AI components with these principles — in particular the human-in-the-loop approval and the transparent naming of model providers (see AI Data Policy). We do not yet operate a certified AI management system.

2.5 SOC 2 Type II

SOC 2 (Service Organization Control 2) Type II is a US audit standard per AICPA that attests the operating effectiveness of controls over an observation period. We currently hold no SOC 2 report. A SOC 2 audit is envisaged after the ISMS (ISO 27001) is in place.

2.6 TISAX® – Trusted Information Security Assessment Exchange

TISAX® is the information-security industry standard established by the automotive industry (ENX Association / VDA-ISA). We hold no TISAX label. As our target customers include OEMs and suppliers, a TISAX assessment is envisaged where customer demand warrants it; it builds on the same ISMS foundation.

2.7 EU AI Act

Regulation (EU) 2024/1689 (EU AI Act) governs the placing on the market and use of AI systems in the EU. The Provider documents the conformity of OSOS / Omega per the respective risk classification. Where the Licensee uses the software in a regulated high-risk context, the Provider provides, on request, the necessary provider documentation available to it (e.g. per Art. 11, 13 AI Act, such as regarding the underlying models). Details: AI Data Policy.

2.8 GDPR / BDSG

For the processing of personal data on behalf of the Licensee, the Data Processing Agreement (DPA) including the TOM annex and the subprocessor list applies. In all other respects, the requirements of GDPR and BDSG are addressed by the technical and organizational measures in Section 4.


3. Hosting, Processing Regions, and Subprocessors

3.1 Hosting

Application and database are operated within the European Union: application and container at Hetzner (Germany), database and file storage at Supabase (EU region). Processing outside the EU occurs only for AI inference at named model providers; the corresponding transfer mechanisms are set out in the subprocessor list.

3.2 Processing Region

The default processing region for customers headquartered in the EEA is the European Union. The option of fully third-country-free AI inference (EU-only) is product-dependent and requires a separate agreement in the Order Form.

3.3 Subprocessors

The current list of all subprocessors (incl. AI subprocessors, hosting, payment processing, email delivery) with registered office, purpose, data categories, processing region, and transfer mechanism is available at /legal/trust-en/subprocessors. Notification and objection rights arise from the DPA.


4. Core Security Mechanisms

The following measures are actively implemented and supplement those described in the TOM annex to the DPA. All entries are verifiable on request.

4.1 ✅ Implemented

  • EU hosting: application and database in the EU (Hetzner DE, Supabase EU region); no processing outside the EU except AI inference at named model providers.
  • Encryption: in transit via TLS (Traefik / Let's Encrypt); at rest provider-side (AES-256).
  • Passwordless authentication: Supabase OTP / magic link (PKCE); no password handling in our own code. Uniform session gating in the edge middleware.
  • Default-deny at the edge: path allowlist, HTTP method filter, pattern-based blocking of known scanner/probe requests, IP rate limit.
  • Tenant separation per company at the application and database level; Row Level Security (RLS) on all tables as an additional line of defense; locked-down storage buckets.
  • No AI training on customer data — contractually excluded (AI Data Policy, Section 3.1); access to model providers exclusively via APIs.
  • Human-in-the-loop: AI-generated content is pending by default and approved individually, exclusively via the user interface, by a human — no bulk approval and no approval via chat.
  • Append-only audit trail for administrative interventions and the subscription lifecycle.
  • Controlled deployment: mandatory staging before production, automatic database backup before every schema update into a locked-down bucket, blocking quality gates (tests, type check, lint), non-root execution in the container.
  • Webhook security: signature verification (Stripe) over the raw body, idempotency via unique constraint.
  • Responsible disclosure: security.txt per RFC 9116 with a dedicated security contact (see Section 7).

4.2 🗓 On the roadmap (common requirements in security and procurement questionnaires)

  • HTTP security headers (HSTS, CSP, X-Frame-Options, Referrer-Policy).
  • Automated dependency and code scanning (Dependabot, CodeQL).
  • Defined RPO/RTO and a documented, regular restore test.
  • Central auth-event logging (failed logins) and alerting.
  • A public, live-updated status page.
  • External penetration test (before general availability).
  • Single Sign-On (SAML 2.0 / OIDC) and enforced MFA.
  • A documented incident-response runbook with escalation and notification paths.

Not currently implemented: a dedicated key management system, customer-managed keys, geo-redundant backups, and a bug bounty program.


5. Industry-Specific Notes (informative)

OSOS / Omega supports engineering processes according to common industry-specific standards. The following list serves as orientation; an independent tool qualification ("Tool Confidence Level") is not performed by the Provider unless separately agreed (cf. EULA Section 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.

To support tool qualification processes, the Provider provides relevant documentation (e.g. Tool Operational Requirements, Use Cases, test protocols) on request and against remuneration.


6. Currentness and Changes

The status and scope of the standards and measures listed here are regularly updated. The current version is available via the Trust Center. Status transitions (🗓 → ✅) and material changes to the compliance status are communicated to Licensees with an active Main Agreement by suitable means (e.g. Trust Center update, email to designated contacts).


7. Contact and Trust Center