Menü

Kontakt aufnehmen
Logo
Presse

Industrien / IT- und Softwarebranche

Digitale Dienste. Verlässliche Infrastruktur.

Software sicher entwickeln und Plattformen zuverlässig bereitstellen und betreiben.

Beratung. Integration. Betrieb.

Entwicklungsarbeitsplatz aus erhöhter Perspektive – Symbolmotiv

Für die Menschen in Ihrer Branche.

  • Softwarehersteller
  • SaaS- und Plattformanbieter
  • IT-Dienstleister und Managed Service Provider
  • Engineering-Teams mit Kapazitätslücken

Ihre Schwerpunkte

Aufgaben verstehen. Lösungen gestalten.

Wir bauen interne Entwicklerplattformen auf Kubernetes und Public Cloud, verankern Sicherheit in jeder Phase Ihres Entwicklungszyklus und verstärken Ihre Teams mit erfahrenen Fachkräften.

01

Platform Engineering und interne Entwicklerplattformen

Plattformarchitektur mit Referenzvorlagen für neue Dienste

Mehr dazu
02

Code Signing und Release-Schlüssel im HSM

HSM-Architektur mit Schlüsselinventar und Zeremonieprotokoll

Mehr dazu
03

Verstärkung für Engineering-Teams

Rollenprofile und Einsatzplan je Team

Mehr dazu

Von der Strategie bis ins System

Sechs Leistungsbausteine

Sechs Handlungsfelder. Wählen Sie, wo Sie genauer hinschauen möchten.

01Platform Engineering und interne EntwicklerplattformenKubernetes · Backstage · Terraform

Unser Ansatz

Eine interne Entwicklerplattform stellt Infrastruktur, Pipelines, Monitoring und Sicherheitsvorgaben als Selbstbedienung bereit, damit Produktteams ohne Tickets ausliefern. Wir bauen sie auf Kubernetes mit Backstage als Entwicklerportal, Terraform für die Infrastruktur und Argo CD für die Auslieferung per GitOps. Leitplanken als Policy as Code prüfen jede Ressource, bevor sie in Betrieb geht. Die Plattform wird wie ein Produkt geführt, mit Backlog, Nutzerfeedback und gemessener Durchlaufzeit.

Leistungsumfang im Detail
  • Bestandsaufnahme von Toolchain, Clustern und Entwicklerwegen mit Messung von Durchlaufzeit und Änderungsfehlerrate
  • Entwicklerportal auf Backstage mit Softwarekatalog, Vorlagen für neue Dienste und Dokumentation als Code
  • Kubernetes-Plattform mit Terraform für die Infrastruktur und GitOps-Auslieferung über Argo CD
  • Leitplanken als Policy as Code mit Kyverno oder Open Policy Agent für Ressourcen, Images und Netzwerkregeln
  • Observability mit OpenTelemetry, Prometheus und Grafana als fester Bestandteil jeder Vorlage

Ein SaaS-Anbieter mit mehreren Produktteams legt neue Dienste über Vorlagen im Entwicklerportal an; Namespace, Pipeline und Monitoring entstehen ohne Ticket an das Plattformteam.

Das erhalten Sie

  • Plattformarchitektur mit Referenzvorlagen für neue Dienste
  • Entwicklerportal mit Softwarekatalog und Dokumentation
  • Richtlinienpaket als Code mit Betriebshandbuch
Dieses Thema besprechen
02Sichere Softwareentwicklung und LieferketteSonarQube · Dependency-Track · CycloneDX

Unser Ansatz

Kunden, Prüfer und der Cyber Resilience Act wollen wissen, welche Komponenten in Ihrer Software stecken und ob der Build unverändert ist. Wir verankern Bedrohungsmodellierung, statische Codeanalyse, Secret Scanning und Dependency Scanning als Pflichtschritte in der Pipeline. Jedes Release erhält eine SBOM in CycloneDX oder SPDX, signierte Artefakte und einen Herkunftsnachweis nach SLSA. Neue Schwachstellen in Abhängigkeiten werden automatisch den betroffenen Versionen zugeordnet und mit Fristen nach Schweregrad behoben.

Leistungsumfang im Detail
  • Bedrohungsmodellierung nach STRIDE für neue Funktionen und Architekturänderungen, verankert in der Definition of Done
  • Statische Codeanalyse, Secret Scanning und Dependency Scanning als Pflichtprüfung in GitHub Actions oder GitLab CI
  • SBOM in CycloneDX oder SPDX für jedes Release, ausgewertet in Dependency-Track
  • Signierte Container-Images und Herkunftsnachweise nach SLSA mit Sigstore Cosign, geprüft vor dem Deployment
  • Schwachstellenmanagement mit Bewertung nach CVSS und EPSS, Fristen je Schweregrad und VEX-Aussagen für Kunden

Ein Hersteller von Branchensoftware liefert zu jedem Release SBOM und signierte Images aus; Kundenanfragen zu einer neuen Schwachstelle beantwortet das Team mit einer VEX-Aussage statt mit manueller Suche.

Das erhalten Sie

  • Secure-SDLC-Richtlinie mit Prüfschritten je Pipeline-Stufe
  • SBOM, Signatur und Herkunftsnachweis je Release
  • Schwachstellenregister mit Fristen und VEX-Vorlagen
Dieses Thema besprechen
03Code Signing und Release-Schlüssel im HSMThales Luna Network HSM · Entrust nShield 5c · Utimaco u.trust GP HSM Se-Series

Unser Ansatz

Wer einen Code-Signing-Schlüssel stiehlt, kann Schadsoftware unter Ihrem Namen verteilen, deshalb gehört er nicht auf Build-Server oder Entwicklerrechner. Für öffentlich vertrauenswürdige Code-Signing-Zertifikate verlangen die Baseline Requirements des CA/Browser Forum ohnehin, dass der private Schlüssel in Hardware erzeugt und gespeichert wird. Wir wählen Netzwerk-HSM von Thales, Entrust oder Utimaco herstellerneutral aus, binden Build-Pipelines über PKCS#11 an und richten einen Signaturdienst mit Freigaben ein. Jede Signatur für Windows-Binärdateien, Container-Images, Pakete oder Firmware wird protokolliert und einem Release zugeordnet.

Leistungsumfang im Detail
  • Inventar aller Signaturschlüssel und Zertifikate für Windows-Binärdateien, Container, Pakete, Mobile Apps und Firmware
  • HSM-Auswahl und Aufbau mit Redundanz über mehrere Standorte, Schlüsselerzeugung in einer protokollierten Zeremonie
  • Signaturdienst mit Anbindung der Build-Pipelines über PKCS#11 und Freigabe nach Vier-Augen-Prinzip für Release-Signaturen
  • Zertifikatslebenszyklus mit EverTrust PKI oder öffentlicher CA, Erneuerung nach den Baseline Requirements des CA/Browser Forum
  • Zeitstempel nach RFC 3161, Protokollierung jeder Signatur und Notfallplan für die Sperrung kompromittierter Zertifikate

Ein Hersteller von Desktop-Software zieht seinen Code-Signing-Schlüssel vom Build-Server in ein Netzwerk-HSM um; Release-Signaturen brauchen eine zweite Freigabe und sind jedem Build zugeordnet.

Das erhalten Sie

  • HSM-Architektur mit Schlüsselinventar und Zeremonieprotokoll
  • Signaturdienst mit Pipeline-Anbindung und Freigaberegeln
  • Betriebshandbuch mit Rotation, Sperrung und Notfallplan
Dieses Thema besprechen
04Managed Cloud und SaaS-Betrieb unter NIS2Kubernetes · Microsoft Azure · AWS

Unser Ansatz

Je nach Größe zählt NIS2 Anbieter von Cloud-Diensten, Rechenzentren und Managed Services zu den wichtigen oder besonders wichtigen Einrichtungen, und in Deutschland regelt das NIS2-Umsetzungsgesetz die Pflichten. Verlangt werden Risikomanagementmaßnahmen nach Artikel 21, gestufte Meldungen erheblicher Vorfälle, Sicherheit in der Lieferkette und eine Geschäftsleitung, die dafür verantwortlich ist. Wir betreiben Ihre Kubernetes-Plattform und Cloud-Konten mit Monitoring, Bereitschaft, Incident Response und getesteter Wiederherstellung. Meldewege, Lieferantenregister und Betriebsnachweise sind Teil des Betriebs und beantworten auch die Sicherheitsfragebögen Ihrer Kunden.

Leistungsumfang im Detail
  • Betroffenheitsprüfung nach NIS2 und deutschem Umsetzungsgesetz, Registrierung beim BSI und Zuordnung der Pflichten zu Rollen
  • Betrieb von Kubernetes-Clustern und Cloud-Konten mit Landing Zone und Härtung nach CIS Benchmarks
  • Monitoring mit Service Level Objectives, Bereitschaft und Incident Response mit Vorlagen für Frühwarnung, Meldung und Abschlussbericht
  • Backup mit Veeam, Wiederherstellungstests und Notfallpläne je Dienst und Mandant
  • Lieferantenregister für Cloud- und Softwaredienstleister mit Sicherheitsanforderungen und Nachweisen für Kundenaudits

Ein Anbieter von Personalsoftware übergibt den Betrieb seiner Kubernetes-Plattform; Vorfälle laufen über einen dokumentierten Meldeprozess, und Sicherheitsfragebögen beantwortet das Team aus den Betriebsnachweisen.

Das erhalten Sie

  • NIS2-Betroffenheitsanalyse mit Maßnahmenplan nach Artikel 21
  • Betriebshandbuch mit Meldeprozess und Eskalationswegen
  • Berichte zu Wiederherstellungstests und Betriebskennzahlen
Dieses Thema besprechen
05Verstärkung für Engineering-TeamsJava · TypeScript · Go

Unser Ansatz

Wenn Roadmap und Regulierung gleichzeitig Kapazität binden, arbeiten Fachkräfte von OTOKO® für eine vereinbarte Zeit in Ihren Teams mit. Backend- und Frontend-Entwickler, Plattformingenieure, Testautomatisierer und Security Engineers übernehmen Aufgaben in Ihren Sprints, Repositories und Code-Reviews nach Ihrer Definition of Done. Zugriffe erhalten sie nach dem Prinzip der minimalen Rechte, und Entscheidungen werden in Architecture Decision Records und Runbooks dokumentiert, damit das Wissen nach dem Einsatz bei Ihrem Team bleibt.

Leistungsumfang im Detail
  • Abgleich von Anforderungen, Technologiestack und Teamstruktur mit passenden Profilen und gemeinsamer Auswahl
  • Mitarbeit in Backend, Frontend, Plattform, Testautomatisierung und Security Engineering in Ihren Sprints
  • Onboarding mit Zugriffskonzept nach dem Prinzip der minimalen Rechte, Vertraulichkeitsvereinbarung und Einweisung in Ihre Richtlinien
  • Arbeit in Ihren Repositories, Tickets und Code-Reviews nach Ihrer Definition of Done
  • Wissenstransfer über Architecture Decision Records, Runbooks und Pair Programming mit Ihrem Team

Ein Softwarehaus verstärkt sein Plattformteam vor einem Kundenrollout mit DevOps- und Testingenieuren; nach dem Rollout übernimmt das eigene Team die dokumentierten Pipelines.

Das erhalten Sie

  • Rollenprofile und Einsatzplan je Team
  • Zugriffskonzept und Onboarding-Checkliste
  • Architecture Decision Records, Runbooks und Übergabedokumentation
Dieses Thema besprechen
06Cyber Resilience Act und PQC-Fahrplan für ProdukteML-KEM (FIPS 203) · ML-DSA (FIPS 204) · SLH-DSA (FIPS 205)

Unser Ansatz

Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen, auch von Software, zu Sicherheit durch Design, einer SBOM und Schwachstellenbehandlung über den gesamten Supportzeitraum. Seit dem 11. September 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, ab dem 11. Dezember 2027 alle übrigen Pflichten. Wir stufen Ihre Produkte ein, schließen Lücken gegenüber Anhang I und richten den Meldeprozess ein. Weil Produkte und ihre Update-Signaturen oft länger im Einsatz bleiben, als RSA und elliptische Kurven gegen Quantencomputer sicher sind, erstellen wir zugleich ein Kryptografie-Inventar und einen Fahrplan zu ML-KEM und ML-DSA.

Leistungsumfang im Detail
  • Einstufung der Produkte nach Cyber Resilience Act als Standardprodukt, wichtiges oder kritisches Produkt mit passendem Konformitätsverfahren
  • Lückenanalyse gegen die grundlegenden Anforderungen aus Anhang I und Aufbau der technischen Dokumentation
  • Prozess für Schwachstellenbehandlung und Meldungen über die Meldeplattform der ENISA mit Fristen für Frühwarnung, Meldung und Abschlussbericht
  • Kryptografie-Inventar je Produkt als CBOM mit Algorithmen, Schlüssellängen, Bibliotheken und Update-Signaturen
  • PQC-Fahrplan mit ML-KEM, ML-DSA und hybriden Verfahren nach BSI TR-02102, Update-Signaturen mit LMS für langlebige Geräte

Ein Hersteller von VPN-Software stuft sein Produkt als wichtiges Produkt ein, richtet den Meldeprozess für aktiv ausgenutzte Schwachstellen ein und stellt die Update-Signatur schrittweise auf ein hybrides Verfahren um.

Das erhalten Sie

  • Produkteinstufung und Lückenanalyse zum Cyber Resilience Act
  • Meldeprozess mit Vorlagen und Verantwortlichen
  • Kryptografie-Inventar und PQC-Fahrplan je Produkt
Dieses Thema besprechen
Laptop mit Entwicklungsumgebung – Symbolmotiv
IT- und Softwarebranche

Typische Projektsituationen

Wo Veränderung konkret wird.

Oft beginnt ein Projekt mit einer konkreten Herausforderung. Diese Beispiele verbinden eine typische Ausgangslage mit einem möglichen Ansatz und dem angestrebten Ergebnis.

Beispielhafte Ausgangssituationen – keine Kundenreferenzen.

01 / IT- und Softwarebranche

Signierte Releases bei einem Softwarehersteller

Code-Signing-Schlüssel als Datei auf dem Build-Server, mehrere Personen kennen das Passwort, eine Zertifikatserneuerung nach neuen Hardwarevorgaben steht an.

Lösung

Netzwerk-HSM mit protokollierter Schlüsselerzeugung, Signaturdienst mit Freigabe, Anbindung der Pipelines über PKCS#11.

Schlüssel im zertifizierten HSM, jede Signatur einem Build zugeordnet, erneuertes Zertifikat nach den Baseline Requirements.

Dieses Thema besprechen

02 / IT- und Softwarebranche

Entwicklerplattform bei einem SaaS-Anbieter

Jedes Produktteam betreibt eigene Cluster und Pipelines, neue Dienste warten auf Tickets, Sicherheitsprüfungen sind uneinheitlich.

Lösung

Interne Entwicklerplattform mit Backstage, GitOps über Argo CD, Leitplanken als Policy as Code und Observability in jeder Vorlage.

Neue Dienste über Vorlagen, einheitliche Prüfungen in allen Pipelines, Plattformteam arbeitet am Produkt statt an Tickets.

Dieses Thema besprechen

03 / IT- und Softwarebranche

NIS2 und Kundenaudits bei einem Managed Service Provider

Der Anbieter fällt unter NIS2, Großkunden verlangen einen SOC-2-Bericht und es gibt keinen dokumentierten Meldeprozess.

Lösung

Betroffenheitsanalyse, ISMS nach ISO 27001 mit Zuordnung zu SOC 2, Meldeprozess mit Vorlagen, Wiederherstellungstests.

Registrierung beim BSI, Meldewege im Regelbetrieb, Evidenz für das Zertifizierungsaudit und die SOC-2-Prüfung.

Dieses Thema besprechen

Zusammenarbeit

Ein klarer Weg. Mit Ihrem Team.

Vom ersten Überblick bis zum laufenden Betrieb: Wir stimmen Prioritäten, Verantwortlichkeiten und die Ergebnisse der einzelnen Schritte gemeinsam ab.

So arbeiten wir

  1. 01

    Assessment

    Plattform, Pipelines, Schlüssel und regulatorische Lücken

    Priorisierte Maßnahmenliste, Schlüsselinventar, Lückenanalyse zu NIS2, CRA und ISO 27001
  2. 02

    Konzept

    Zielplattform, Sicherheitskontrollen, Betriebs- und Teammodell

    Plattformarchitektur, Secure-SDLC-Richtlinie, HSM-Konzept für Code Signing, Betriebsmodell
  3. 03

    Umsetzung

    Plattform, Pipelines und Signaturdienst in Etappen

    Produktive Plattform, signierte Releases mit SBOM, Dokumentation und Abnahme je Etappe
  4. 04

    Betrieb

    Monitoring, Audits, Wissenstransfer

    Monitoring, Schlüsselrotation, Audit- und Meldebegleitung, schrittweise Übergabe

Vor dem ersten Gespräch

Sie müssen noch nicht alle Antworten haben.

Eine konkrete Herausforderung genügt. Diese vier Fragen helfen uns, gemeinsam die richtige Richtung zu finden.

Erstgespräch vereinbaren
  1. 01

    Was soll sich verändern?

    Die aktuelle Herausforderung und Ihr gewünschtes Ergebnis.

  2. 02

    Welche Systeme sind betroffen?

    Ein Überblick über Standorte, Anwendungen und Schnittstellen.

  3. 03

    Was gibt den Rahmen vor?

    Projekttermine, Wartungsfenster und bekannte Abhängigkeiten.

  4. 04

    Wer gehört an den Tisch?

    Die passenden Ansprechpartner aus IT, Sicherheit und Betrieb.

Hintergrund & Entscheidungshilfen

Was sind IT-Lösungen für IT- und Softwareunternehmen?

Sechs Handlungsfelder von der internen Entwicklerplattform bis zum PQC-Fahrplan für Ihre Produkte, umgesetzt und betrieben von OTOKO®. Signaturschlüssel liegen im HSM, jedes Release trägt SBOM und Signatur, und Nachweise für NIS2, Cyber Resilience Act, ISO 27001 und SOC 2 entstehen im laufenden Betrieb.

IT-Lösungen für IT- und Softwareunternehmen verbinden schnelle Auslieferung mit einer Sicherheit, die Kunden, Prüfer und Gesetzgeber belegt sehen wollen. OTOKO® deckt dafür sechs Handlungsfelder ab: Platform Engineering und interne Entwicklerplattformen, sichere Softwareentwicklung und Lieferkette, Code Signing und Release-Schlüssel im HSM, Managed Cloud und SaaS-Betrieb unter NIS2, Verstärkung für Engineering-Teams sowie Readiness für den Cyber Resilience Act mit PQC-Fahrplan.

Der Unterschied liegt darin, dass Sicherheitsnachweise in der Pipeline entstehen statt kurz vor dem Audit. SBOM, Signatur, Schwachstellenstatus und Betriebsprotokolle fallen bei jedem Release an und beantworten Kundenfragebögen ohne Sonderprojekt. Kryptografie und Hardware-Sicherheitsmodule sind unsere Kernkompetenz; Signaturschlüssel für Software, Container und Firmware liegen deshalb in zertifizierter Hardware statt auf Build-Servern.

Warum OTOKO® für IT- und Softwareunternehmen

  • Kryptografie und HSM

    Kryptografie und Hardware-Sicherheitsmodule sind unsere Kernkompetenz. Code-Signing-Schlüssel, Release-Schlüssel und die PKI hinter Ihren Produkten liegen deshalb in zertifizierter Hardware statt auf Build-Servern.

  • Deutsche Rechenzentren

    Die gesamte Lösung läuft in deutschen Rechenzentren, von der Entwicklerplattform bis zum Signaturdienst. Das hilft bei Kunden, die Datenhaltung in Deutschland vertraglich verlangen.

  • KRITIS und regulierte Branchen

    Wir arbeiten mit Betreibern kritischer Infrastrukturen und regulierten Branchen. Wir wissen daher, welche Nachweise Ihre Kunden aus Finanzsektor, Energie und Verwaltung in Ausschreibungen verlangen.

  • Ein Team bis zum Betrieb

    Ein Team begleitet Sie von der Beratung bis zum Betrieb. Plattformingenieure, Sicherheitsarchitekten und Kryptografie-Spezialisten bleiben an Bord, ohne Übergabe an Dritte.

Rahmenbedingungen und Details

Den meisten Softwareunternehmen fehlt nicht das technische Können, sondern der Nachweis, den Kunden, Prüfer und Gesetzgeber inzwischen verlangen.

Plattformen im Wildwuchs

Jedes Produktteam betreibt eigene Cluster, Pipelines und Monitoring, Sicherheitsprüfungen unterscheiden sich von Team zu Team und das Plattformteam arbeitet vor allem Tickets ab.

Lieferkette ohne Nachweis

Abhängigkeiten sind nicht inventarisiert, Build-Artefakte tragen keine Signatur und bei einer neuen Schwachstelle sucht das Team tagelang nach den betroffenen Versionen.

Signaturschlüssel als Datei

Code-Signing-Schlüssel liegen in CI-Variablen oder auf Entwicklerrechnern, mehrere Personen kennen das Passwort und niemand kann belegen, wann welche Signatur entstanden ist.

Regulierung trifft Roadmap

NIS2, Cyber Resilience Act und Kundenaudits kommen gleichzeitig, während die Engineering-Kapazität des Jahres bereits für neue Funktionen verplant ist.

Drei Betriebsmodelle
On-PremisesDeutsche CloudHyperscaler
DatenhaltungIhr Rechenzentrum, Ihre Build-Server und HSMRechenzentren in Deutschland, betrieben nach ISO 27001Azure, AWS oder Google Cloud, Region wählbar
BetriebIhr Team oder OTOKO® als Managed ServiceOTOKO®, mit Auditrechten für Ihre KundenprüfungenGemeinsam, Plattformdienste durch den Anbieter
WerkzeugeKubernetes, GitLab, Netzwerk-HSM für Code SigningGehostete Kubernetes-Plattform, HSM as a Service, Backup mit VeeamVerwaltete Kubernetes-Dienste, Cloud-HSM, Pipeline-Dienste des Anbieters
Geeignet fürSignaturschlüssel, Build-Umgebungen mit strengen KundenauflagenSaaS für Kunden aus regulierten Branchen mit SouveränitätsanforderungenSaaS mit internationalen Kunden, Lastspitzen, Testumgebungen
ComplianceVolle Kontrolle, Nachweise aus Ihrem ISMSAuftragsverarbeitung nach DSGVO, Standort Deutschland, Belege für KundenauditsAuftragsverarbeitung, Standardvertragsklauseln, geteilte Verantwortung je Dienst

Zusammenarbeit

Projekt

Klar abgegrenztes Vorhaben wie ein Signaturdienst im HSM oder eine Entwicklerplattform, mit festem Ergebnis, Meilensteinen und Abnahme.

  • Assessment, Konzept, Umsetzung, Übergabe
  • Festpreis oder Aufwand nach Meilensteinen
  • Geeignet für Code Signing, Plattformaufbau und CRA-Readiness

Team-Verstärkung

Plattformingenieure, Security Engineers oder Entwickler arbeiten in Ihren Teams, mit Ihren Werkzeugen und nach Ihrer Definition of Done.

  • Einarbeitung in Ihre Repositories, Prozesse und Richtlinien
  • Skalierbar nach Projektverlauf
  • Geeignet für Teams mit Kapazitätslücken vor Releases oder Audits

Managed Service

OTOKO® betreibt Plattform, Cloud-Konten oder Signaturdienst mit vereinbarten Leistungswerten, Berichten und den Meldewegen, die NIS2 verlangt.

  • Monitoring, Updates, Schlüsselrotation und Support
  • Meldeprozess, Wiederherstellungstests und Auditrechte im Vertrag
  • Geeignet für Anbieter ohne eigenes Betriebsteam für Plattform oder HSM

Was jede Vorgabe von IT- und Softwareunternehmen verlangt und was OTOKO® dafür liefert.

Standards und Nachweise
VorgabeVerlangtOTOKO® liefert
ISO 27001ISMS mit Risikobeurteilung, Erklärung zur Anwendbarkeit, Maßnahmen aus Anhang A und jährlichen ÜberwachungsauditsAufbau des ISMS, Erklärung zur Anwendbarkeit, technische Maßnahmen in Plattform und Pipeline, Vorbereitung auf das Zertifizierungsaudit
SOC 2Prüfung von Kontrollen nach den Trust Services Criteria des AICPA, als Type I zu einem Stichtag oder Type II über einen ZeitraumKontrollrahmen mit Zuordnung zu ISO 27001, automatisierte Evidenz aus Cloud und Pipeline, Vorbereitung auf die Prüfung durch den Wirtschaftsprüfer
NIS2Risikomanagementmaßnahmen nach Artikel 21, gestufte Meldung erheblicher Vorfälle, Sicherheit in der Lieferkette und Verantwortung der GeschäftsleitungBetroffenheitsanalyse, Maßnahmenplan, Meldeprozess mit Vorlagen, Lieferantenregister, Schulungsunterlagen für die Geschäftsleitung
Cyber Resilience ActSicherheit durch Design, SBOM, Schwachstellenbehandlung über den Supportzeitraum, Meldung aktiv ausgenutzter Schwachstellen und CE-KennzeichnungProdukteinstufung, Lückenanalyse, SBOM-Prozess, Meldeprozess, technische Dokumentation für die Konformitätsbewertung
DSGVODatenschutz durch Technikgestaltung, Auftragsverarbeitung, Verzeichnis der Verarbeitungstätigkeiten und Garantien bei Übermittlung in DrittländerDatenschutzkonzept für SaaS-Produkte, Auftragsverarbeitungsvertrag, Verschlüsselung mit Schlüsseln im HSM, Betrieb in Deutschland

Häufige Fragen

Gute Fragen. Klare Antworten.

15 Antworten zu Ihrer Branche, zum Projekt und zum Betrieb danach.

Branche & Handlungsfelder6 Fragen

Welche IT-Lösungen für IT- und Softwareunternehmen bietet OTOKO® an?

Das Angebot umfasst interne Entwicklerplattformen auf Kubernetes, sichere Softwareentwicklung mit SBOM und signierten Builds, Code Signing mit Schlüsseln im HSM und den Betrieb von Cloud- und SaaS-Plattformen unter NIS2. Dazu kommen Fachkräfte, die Ihre Engineering-Teams verstärken, sowie Readiness für den Cyber Resilience Act mit einem PQC-Fahrplan. Jedes Handlungsfeld lässt sich einzeln oder als Paket beauftragen.

Warum sollten Code-Signing-Schlüssel in einem HSM liegen?

Ein gestohlener Signaturschlüssel erlaubt es Angreifern, Schadsoftware als Ihr offizielles Update auszuliefern. Im HSM wird der Schlüssel erzeugt und verlässt das Gerät nicht im Klartext, und jede Signatur braucht eine Berechtigung und wird protokolliert. Für öffentlich vertrauenswürdige Code-Signing-Zertifikate verlangen die Baseline Requirements des CA/Browser Forum ohnehin einen Schlüssel in Hardware.

Betrifft NIS2 auch unser Softwareunternehmen?

Das hängt von Tätigkeit und Größe ab. Anbieter von Cloud-Diensten, Rechenzentren und Managed Services fallen ab mittlerer Unternehmensgröße direkt unter NIS2, reine Softwarehersteller meist nicht. Viele erhalten die Anforderungen aber über ihre Kunden, die Sicherheit in der Lieferkette nachweisen müssen. Wir arbeiten mit Betreibern kritischer Infrastrukturen und regulierten Branchen und kennen daher die Klauseln, die solche Kunden in Verträge schreiben.

Was verlangt der Cyber Resilience Act von Softwareherstellern?

Wer Software oder Geräte mit Software in der EU in Verkehr bringt, muss Sicherheit durch Design nachweisen, eine SBOM erstellen, Schwachstellen über den Supportzeitraum beheben und Sicherheitsupdates bereitstellen. Aktiv ausgenutzte Schwachstellen sind seit September 2026 zu melden, die vollständigen Pflichten mit CE-Kennzeichnung gelten ab Dezember 2027. Reine SaaS-Angebote fallen in der Regel nicht darunter, die zugehörigen Apps und Clients dagegen schon.

Wie arbeiten Fachkräfte von OTOKO® in unserem Team mit?

Nach einem Abgleich von Anforderungen und Profilen stellen wir Fachkräfte vor, die Sie gemeinsam mit uns auswählen. Sie arbeiten in Ihren Sprints, Repositories und Code-Reviews, mit Zugriffen nach dem Prinzip der minimalen Rechte. Ein Team begleitet Sie von der Beratung bis zum Betrieb, sodass Plattform, Sicherheit und Kapazität von einem Anbieter kommen und der Umfang mit dem Projekt wächst oder schrumpft.

Unterstützt OTOKO® bei ISO 27001 und SOC 2?

Ja. Wir bauen das ISMS nach ISO 27001 auf, ordnen seine Kontrollen zugleich den Trust Services Criteria von SOC 2 zu und setzen die technischen Maßnahmen in Plattform und Pipeline um. Evidenz wie Zugriffsprotokolle, Änderungsnachweise und Wiederherstellungstests entsteht automatisiert. Das Zertifikat erteilt eine akkreditierte Zertifizierungsstelle, den SOC-2-Bericht erstellt ein unabhängiger Wirtschaftsprüfer.

Einstieg & Umsetzung5 Fragen

Können wir mit einem einzelnen Handlungsfeld starten?

Ja. Wir können zunächst eine konkrete Aufgabe abgrenzen. Dabei betrachten wir ihre Schnittstellen zur übrigen Infrastruktur und stimmen vor der Umsetzung ab, welche Leistungen zum Auftrag gehören.

Was sollten wir für das Erstgespräch vorbereiten?

Eine kurze Beschreibung der Herausforderung, der betroffenen Systeme und Ihres gewünschten Ergebnisses genügt für den Einstieg. Bekannte Termine und die passenden Ansprechpartner helfen zusätzlich. Zugangsdaten oder vertrauliche Systemdokumentation gehören nicht in eine erste Kontaktanfrage.

Wer sollte am Projekt beteiligt sein?

Plattformarchitekt: Entwicklerplattform, Kubernetes, GitOps. Security Engineer: Secure SDLC, SBOM, Schwachstellenmanagement. Kryptografie-Spezialist: HSM, Code Signing, PQC-Fahrplan. Site Reliability Engineer: Betrieb, Monitoring, Incident Response. Compliance-Berater: NIS2, Cyber Resilience Act, ISO 27001, SOC 2. Projektleitung: Meilensteine, Abnahmen, Berichte.

Wie werden Zeitplan und Aufwand bestimmt?

Wir betrachten Systeme, Schnittstellen, Dokumentationslage und betriebliche Rahmenbedingungen. Ein abgestimmter Umfang und Meilensteine bilden die Grundlage für die Aufwandsschätzung. Eine feste Dauer ohne diese Angaben wäre nicht belastbar.

Was liefert die erste Projektphase?

Plattform, Pipelines, Schlüssel und regulatorische Lücken Priorisierte Maßnahmenliste, Schlüsselinventar, Lückenanalyse zu NIS2, CRA und ISO 27001

Betrieb & Weiterentwicklung4 Fragen

Welche Formen der Zusammenarbeit sind möglich?

Projekt: Klar abgegrenztes Vorhaben wie ein Signaturdienst im HSM oder eine Entwicklerplattform, mit festem Ergebnis, Meilensteinen und Abnahme. Team-Verstärkung: Plattformingenieure, Security Engineers oder Entwickler arbeiten in Ihren Teams, mit Ihren Werkzeugen und nach Ihrer Definition of Done. Managed Service: OTOKO® betreibt Plattform, Cloud-Konten oder Signaturdienst mit vereinbarten Leistungswerten, Berichten und den Meldewegen, die NIS2 verlangt.

Wie erfolgt die Übergabe in den Betrieb?

Monitoring, Audits, Wissenstransfer Monitoring, Schlüsselrotation, Audit- und Meldebegleitung, schrittweise Übergabe

Können wir später weitere Standorte oder Systeme ergänzen?

Das lässt sich im ersten Konzept berücksichtigen. Dokumentierte Schnittstellen und wiederverwendbare Regeln schaffen eine Grundlage für den Ausbau. Jeder zusätzliche Standort und jedes neue System werden dennoch auf ihre besonderen Anforderungen geprüft.

Wie bleibt die Lösung langfristig betreibbar?

Zuständigkeiten, wiederkehrende Aufgaben und Änderungsabläufe werden zusammen mit der technischen Umsetzung festgelegt. Dokumentation und Wissenstransfer helfen Ihrem Team im Alltag. Welche Tätigkeiten und laufende Unterstützung dazugehören, wird im Leistungsumfang vereinbart.

IT- und Softwarebranche

Lassen Sie uns den nächsten Schritt besprechen.

Lassen Sie uns besprechen, wie Ihre Plattform sicherer wird und Ihr Team die Kapazität gewinnt, die es braucht.

Erstgespräch vereinbaren

Unsere Partner

  • Microsoft
  • Microsoft Azure
  • Amazon AWS
  • Google Cloud
  • Thales Group
  • Arrow ECS
  • Vodafone
  • IBM
  • Veeam
  • Atlassian
  • JetBrains
  • NinjaOne
  • OPSWAT
  • Utimaco
  • Eviden

Barrierefreiheit

Passe die Darstellung an deine Bedürfnisse an.

Für diese Seite ist noch keine einfache Fassung verfügbar.

Einstellungen gelten aktuell für diesen Besuch. Dauerhaftes Speichern kannst du in den Cookie-Einstellungen erlauben.