®01
Platform engineering en interne ontwikkelaarsplatformen
Platformarchitectuur met referentiesjablonen voor nieuwe diensten
Meer hieroverSectoren / IT- en softwaresector
Digitale diensten. Betrouwbare infrastructuur.
Software veilig ontwikkelen en platformen betrouwbaar leveren en beheren.
Advies. Integratie. Beheer.
Voor de mensen in uw sector.
- Softwareproducenten
- SaaS- en platformaanbieders
- IT-dienstverleners en managed service providers
- Engineeringteams met capaciteitstekorten
Uw speerpunten
Opgaven begrijpen. Oplossingen vormgeven.
Wij bouwen interne ontwikkelplatformen op Kubernetes en public cloud, verankeren beveiliging in elke fase van uw ontwikkelcyclus en versterken uw teams met ervaren specialisten.
02
Code signing en releasesleutels in de HSM
HSM-architectuur met sleutelinventaris en ceremonieverslag
Meer hierover03
Versterking voor engineeringteams
Rolprofielen en inzetplan per team
Meer hieroverVan strategie tot in het systeem
Zes servicebouwstenen
Zes aandachtsgebieden. Kies waar u dieper op wilt ingaan.
01Platform engineering en interne ontwikkelaarsplatformenKubernetes · Backstage · Terraform
Onze aanpak
Een intern ontwikkelaarsplatform stelt infrastructuur, pipelines, monitoring en beveiligingsregels als selfservice beschikbaar, zodat productteams zonder tickets opleveren. Wij bouwen het op Kubernetes met Backstage als ontwikkelaarsportaal, Terraform voor de infrastructuur en Argo CD voor de uitlevering via GitOps. Vangrails als policy as code controleren elke resource voordat die in productie gaat. Het platform wordt als een product gevoerd, met backlog, gebruikersfeedback en gemeten doorlooptijd.
Omvang van de dienstverlening in detail
- Inventarisatie van toolchain, clusters en ontwikkelaarsprocessen met meting van doorlooptijd en change failure rate
- Ontwikkelaarsportaal op Backstage met softwarecatalogus, sjablonen voor nieuwe diensten en documentatie als code
- Kubernetes-platform met Terraform voor de infrastructuur en GitOps-uitlevering via Argo CD
- Vangrails als policy as code met Kyverno of Open Policy Agent voor resources, images en netwerkregels
- Observability met OpenTelemetry, Prometheus en Grafana als vast onderdeel van elk sjabloon
Een SaaS-aanbieder met meerdere productteams maakt nieuwe diensten aan via sjablonen in het ontwikkelaarsportaal; namespace, pipeline en monitoring ontstaan zonder ticket aan het platformteam.
Dit ontvangt u
- Platformarchitectuur met referentiesjablonen voor nieuwe diensten
- Ontwikkelaarsportaal met softwarecatalogus en documentatie
- Beleidspakket als code met beheerhandboek
02Veilige softwareontwikkeling en toeleveringsketenSonarQube · Dependency-Track · CycloneDX
Onze aanpak
Klanten, auditors en de Cyber Resilience Act willen weten welke componenten in uw software zitten en of de build onveranderd is. Wij verankeren dreigingsmodellering, statische codeanalyse, secret scanning en dependency scanning als verplichte stappen in de pipeline. Elke release krijgt een SBOM in CycloneDX of SPDX, ondertekende artefacten en een herkomstbewijs volgens SLSA. Nieuwe kwetsbaarheden in afhankelijkheden worden automatisch aan de getroffen versies gekoppeld en binnen termijnen naar ernst verholpen.
Omvang van de dienstverlening in detail
- Dreigingsmodellering volgens STRIDE voor nieuwe functies en architectuurwijzigingen, verankerd in de definition of done
- Statische codeanalyse, secret scanning en dependency scanning als verplichte controle in GitHub Actions of GitLab CI
- SBOM in CycloneDX of SPDX voor elke release, geanalyseerd in Dependency-Track
- Ondertekende container-images en herkomstbewijzen volgens SLSA met Sigstore Cosign, gecontroleerd vóór de deployment
- Kwetsbaarhedenbeheer met beoordeling volgens CVSS en EPSS, termijnen per ernst en VEX-verklaringen voor klanten
Een producent van branchesoftware levert bij elke release een SBOM en ondertekende images; klantvragen over een nieuwe kwetsbaarheid beantwoordt het team met een VEX-verklaring in plaats van handmatig zoekwerk.
Dit ontvangt u
- Secure SDLC-richtlijn met controlestappen per pipelinefase
- SBOM, handtekening en herkomstbewijs per release
- Kwetsbaarhedenregister met termijnen en VEX-sjablonen
03Code signing en releasesleutels in de HSMThales Luna Network HSM · Entrust nShield 5c · Utimaco u.trust GP HSM Se-Series
Onze aanpak
Wie een code-signing-sleutel steelt, kan malware onder uw naam verspreiden; daarom hoort die sleutel niet op buildservers of ontwikkelaarscomputers. Voor publiek vertrouwde code-signing-certificaten eisen de Baseline Requirements van het CA/Browser Forum sowieso dat de privésleutel in hardware wordt gegenereerd en opgeslagen. Wij kiezen leveranciersonafhankelijk netwerk-HSM's van Thales, Entrust of Utimaco, koppelen build-pipelines via PKCS#11 en richten een ondertekeningsdienst met goedkeuringen in. Elke handtekening voor Windows-binaries, container-images, pakketten of firmware wordt gelogd en aan een release gekoppeld.
Omvang van de dienstverlening in detail
- Inventaris van alle ondertekeningssleutels en certificaten voor Windows-binaries, containers, pakketten, mobiele apps en firmware
- HSM-keuze en -opbouw met redundantie over meerdere locaties, sleutelgeneratie in een vastgelegde ceremonie
- Ondertekeningsdienst met koppeling van de build-pipelines via PKCS#11 en goedkeuring volgens het vierogenprincipe voor releasehandtekeningen
- Certificaatlevenscyclus met EverTrust PKI of een publieke CA, vernieuwing volgens de Baseline Requirements van het CA/Browser Forum
- Tijdstempels volgens RFC 3161, logging van elke handtekening en noodplan voor de intrekking van gecompromitteerde certificaten
Een producent van desktopsoftware verhuist zijn code-signing-sleutel van de buildserver naar een netwerk-HSM; releasehandtekeningen vereisen een tweede goedkeuring en zijn aan elke build gekoppeld.
Dit ontvangt u
- HSM-architectuur met sleutelinventaris en ceremonieverslag
- Ondertekeningsdienst met pipelinekoppeling en goedkeuringsregels
- Beheerhandboek met rotatie, intrekking en noodplan
04Managed cloud en SaaS-beheer onder NIS2Kubernetes · Microsoft Azure · AWS
Onze aanpak
Afhankelijk van hun omvang rekent NIS2 aanbieders van clouddiensten, datacenters en managed services tot de belangrijke of essentiële entiteiten, en in Duitsland regelt de NIS2-implementatiewet de verplichtingen. Vereist zijn risicobeheersmaatregelen volgens artikel 21, gefaseerde meldingen van significante incidenten, beveiliging van de toeleveringsketen en een bestuur dat daarvoor verantwoordelijk is. Wij beheren uw Kubernetes-platform en cloudaccounts met monitoring, piketdienst, incident response en geteste herstelprocedures. Meldroutes, leveranciersregister en beheerbewijs maken deel uit van het beheer en beantwoorden ook de beveiligingsvragenlijsten van uw klanten.
Omvang van de dienstverlening in detail
- Toets volgens NIS2 en de Duitse implementatiewet, registratie bij het BSI en toewijzing van de verplichtingen aan rollen
- Beheer van Kubernetes-clusters en cloudaccounts met landing zone en hardening volgens CIS Benchmarks
- Monitoring met service level objectives, piketdienst en incident response met sjablonen voor vroegtijdige waarschuwing, melding en eindverslag
- Back-up met Veeam, hersteltests en noodplannen per dienst en tenant
- Leveranciersregister voor cloud- en softwaredienstverleners met beveiligingseisen en bewijs voor klantaudits
Een aanbieder van hr-software draagt het beheer van zijn Kubernetes-platform over; incidenten lopen via een gedocumenteerd meldproces, en beveiligingsvragenlijsten beantwoordt het team op basis van het beheerbewijs.
Dit ontvangt u
- NIS2-toepasselijkheidsanalyse met maatregelenplan volgens artikel 21
- Beheerhandboek met meldproces en escalatiepaden
- Rapportages over hersteltests en operationele kengetallen
05Versterking voor engineeringteamsJava · TypeScript · Go
Onze aanpak
Wanneer roadmap en regelgeving tegelijk capaciteit vragen, werken specialisten van OTOKO® voor een afgesproken periode in uw teams mee. Backend- en frontendontwikkelaars, platformengineers, testautomatiseerders en security engineers nemen taken over in uw sprints, repositories en code reviews volgens uw definition of done. Toegang krijgen zij volgens het principe van minimale rechten, en beslissingen worden vastgelegd in architecture decision records en runbooks, zodat de kennis na de inzet bij uw team blijft.
Omvang van de dienstverlening in detail
- Afstemming van eisen, technologiestack en teamstructuur op passende profielen, met gezamenlijke selectie
- Meewerken in backend, frontend, platform, testautomatisering en security engineering in uw sprints
- Onboarding met toegangsconcept volgens het principe van minimale rechten, geheimhoudingsovereenkomst en instructie over uw richtlijnen
- Werken in uw repositories, tickets en code reviews volgens uw definition of done
- Kennisoverdracht via architecture decision records, runbooks en pair programming met uw team
Een softwarehuis versterkt zijn platformteam vóór een klantuitrol met DevOps- en testengineers; na de uitrol neemt het eigen team de gedocumenteerde pipelines over.
Dit ontvangt u
- Rolprofielen en inzetplan per team
- Toegangsconcept en onboarding-checklist
- Architecture decision records, runbooks en overdrachtsdocumentatie
06Cyber Resilience Act en PQC-roadmap voor productenML-KEM (FIPS 203) · ML-DSA (FIPS 204) · SLH-DSA (FIPS 205)
Onze aanpak
De Cyber Resilience Act verplicht fabrikanten van producten met digitale elementen, ook van software, tot beveiliging door ontwerp, een SBOM en de afhandeling van kwetsbaarheden gedurende de volledige ondersteuningsperiode. Sinds 11 september 2026 gelden de meldplichten voor actief uitgebuite kwetsbaarheden en ernstige incidenten, vanaf 11 december 2027 alle overige verplichtingen. Wij classificeren uw producten, dichten lacunes ten opzichte van bijlage I en richten het meldproces in. Omdat producten en hun updatehandtekeningen vaak langer in gebruik blijven dan RSA en elliptische krommen veilig zijn tegen quantumcomputers, maken wij tegelijk een crypto-inventaris en een roadmap naar ML-KEM en ML-DSA.
Omvang van de dienstverlening in detail
- Classificatie van de producten volgens de Cyber Resilience Act als standaardproduct, belangrijk of kritiek product met passende conformiteitsprocedure
- Gap-analyse ten opzichte van de essentiële eisen uit bijlage I en opbouw van de technische documentatie
- Proces voor de afhandeling van kwetsbaarheden en meldingen via het meldplatform van ENISA met termijnen voor vroegtijdige waarschuwing, melding en eindverslag
- Crypto-inventaris per product als CBOM met algoritmen, sleutellengtes, bibliotheken en updatehandtekeningen
- PQC-roadmap met ML-KEM, ML-DSA en hybride methoden volgens BSI TR-02102, updatehandtekeningen met LMS voor apparaten met een lange levensduur
Een producent van VPN-software classificeert zijn product als belangrijk product, richt het meldproces voor actief uitgebuite kwetsbaarheden in en zet de updatehandtekening stapsgewijs om naar een hybride methode.
Dit ontvangt u
- Productclassificatie en gap-analyse voor de Cyber Resilience Act
- Meldproces met sjablonen en verantwoordelijken
- Crypto-inventaris en PQC-roadmap per product
Typische projectsituaties
Waar verandering concreet wordt.
Vaak begint een project met een concrete uitdaging. Deze voorbeelden combineren een typische uitgangssituatie met een mogelijke aanpak en het beoogde resultaat.
Voorbeelden van uitgangssituaties, geen klantreferenties.
01 / IT- en softwaresector
Ondertekende releases bij een softwareproducent
Code-signing-sleutel als bestand op de buildserver, meerdere personen kennen het wachtwoord, een certificaatvernieuwing volgens nieuwe hardware-eisen staat voor de deur.
Oplossing
Netwerk-HSM met vastgelegde sleutelgeneratie, ondertekeningsdienst met goedkeuring, koppeling van de pipelines via PKCS#11.
Sleutel in een gecertificeerde HSM, elke handtekening aan een build gekoppeld, vernieuwd certificaat volgens de Baseline Requirements.
02 / IT- en softwaresector
Ontwikkelaarsplatform bij een SaaS-aanbieder
Elk productteam beheert eigen clusters en pipelines, nieuwe diensten wachten op tickets, beveiligingscontroles zijn niet uniform.
Oplossing
Intern ontwikkelaarsplatform met Backstage, GitOps via Argo CD, vangrails als policy as code en observability in elk sjabloon.
Nieuwe diensten via sjablonen, uniforme controles in alle pipelines, platformteam werkt aan het product in plaats van aan tickets.
03 / IT- en softwaresector
NIS2 en klantaudits bij een managed service provider
De aanbieder valt onder NIS2, grote klanten eisen een SOC 2-rapport en er is geen gedocumenteerd meldproces.
Oplossing
Toepasselijkheidsanalyse, ISMS volgens ISO 27001 met mapping naar SOC 2, meldproces met sjablonen, hersteltests.
Registratie bij het BSI, meldroutes in het reguliere beheer, bewijs voor de certificeringsaudit en het SOC 2-onderzoek.
Samenwerking
Een duidelijk traject. Met uw team.
Van het eerste overzicht tot het lopende beheer: wij stemmen prioriteiten, verantwoordelijkheden en de resultaten van de afzonderlijke stappen samen af.
Zo werken wij
- 01
Assessment
Platform, pipelines, sleutels en lacunes in de regelgeving
Geprioriteerde lijst met maatregelen, sleutelinventaris, gap-analyse voor NIS2, CRA en ISO 27001 - 02
Concept
Doelplatform, beveiligingsmaatregelen, beheer- en teammodel
Platformarchitectuur, Secure SDLC-richtlijn, HSM-concept voor code signing, beheermodel - 03
Realisatie
Platform, pipelines en ondertekeningsdienst in fasen
Productief platform, ondertekende releases met SBOM, documentatie en acceptatie per fase - 04
Beheer
Monitoring, audits, kennisoverdracht
Monitoring, sleutelrotatie, begeleiding bij audits en meldingen, stapsgewijze overdracht
Vóór het kennismakingsgesprek
U hoeft nog niet alle antwoorden te hebben.
Een concrete uitdaging is voldoende. Deze vier vragen helpen ons om samen de juiste richting te bepalen.
Kennismakingsgesprek plannen- 01
Wat moet er veranderen?
De huidige uitdaging en uw gewenste resultaat.
- 02
Welke systemen zijn betrokken?
Een overzicht van locaties, applicaties en interfaces.
- 03
Wat bepaalt het kader?
Projectdata, onderhoudsvensters en bekende afhankelijkheden.
- 04
Wie moet aan tafel zitten?
De juiste contactpersonen uit IT, beveiliging en beheer.
Achtergrond & beslishulpen
Wat zijn IT-oplossingen voor IT- en softwarebedrijven?
Zes aandachtsgebieden, van het interne ontwikkelaarsplatform tot de PQC-roadmap voor uw producten, uitgevoerd en beheerd door OTOKO®. Ondertekeningssleutels liggen in de HSM, elke release draagt een SBOM en een handtekening, en bewijs voor NIS2, Cyber Resilience Act, ISO 27001 en SOC 2 ontstaat in het lopende beheer.
IT-oplossingen voor IT- en softwarebedrijven combineren snelle oplevering met een beveiliging die klanten, auditors en wetgevers aangetoond willen zien. OTOKO® bestrijkt daarvoor zes aandachtsgebieden: platform engineering en interne ontwikkelaarsplatformen, veilige softwareontwikkeling en toeleveringsketen, code signing en releasesleutels in de HSM, managed cloud en SaaS-beheer onder NIS2, versterking voor engineeringteams en gereedheid voor de Cyber Resilience Act met PQC-roadmap.
Het verschil is dat beveiligingsbewijs in de pipeline ontstaat in plaats van kort voor de audit. SBOM, handtekening, kwetsbaarheidsstatus en beheerlogs ontstaan bij elke release en beantwoorden klantvragenlijsten zonder apart project. Cryptografie en hardware security modules zijn onze kerncompetentie; ondertekeningssleutels voor software, containers en firmware liggen daarom in gecertificeerde hardware in plaats van op buildservers.
Waarom OTOKO® voor IT- en softwarebedrijven
- Cryptografie en HSM
Cryptografie en hardware security modules zijn onze kerncompetentie. Code-signing-sleutels, releasesleutels en de PKI achter uw producten liggen daarom in gecertificeerde hardware in plaats van op buildservers.
- Duitse datacenters
De volledige oplossing draait in Duitse datacenters, van het ontwikkelaarsplatform tot de ondertekeningsdienst. Dat helpt bij klanten die gegevensopslag in Duitsland contractueel eisen.
- KRITIS en gereguleerde sectoren
Wij werken met exploitanten van kritieke infrastructuur en gereguleerde sectoren. Wij weten daarom welk bewijs uw klanten uit de financiële sector, de energiesector en de overheid in aanbestedingen eisen.
- Eén team tot en met het beheer
Eén team begeleidt u van advies tot beheer. Platformengineers, beveiligingsarchitecten en cryptografiespecialisten blijven aan boord, zonder overdracht aan derden.
Randvoorwaarden en details
Typische uitgangssituatie vóór een project bij IT- en softwarebedrijven
De meeste softwarebedrijven ontbreekt het niet aan technisch kunnen, maar aan het bewijs dat klanten, auditors en wetgevers inmiddels eisen.
01
Wildgroei aan platformen
Elk productteam beheert eigen clusters, pipelines en monitoring, beveiligingscontroles verschillen per team en het platformteam werkt vooral tickets af.
02
Toeleveringsketen zonder bewijs
Afhankelijkheden zijn niet geïnventariseerd, build-artefacten dragen geen handtekening en bij een nieuwe kwetsbaarheid zoekt het team dagenlang naar de getroffen versies.
03
Ondertekeningssleutels als bestand
Code-signing-sleutels staan in CI-variabelen of op ontwikkelaarscomputers, meerdere personen kennen het wachtwoord en niemand kan aantonen wanneer welke handtekening is gemaakt.
04
Regelgeving ontmoet roadmap
NIS2, Cyber Resilience Act en klantaudits komen tegelijk, terwijl de engineeringcapaciteit van dit jaar al voor nieuwe functies is ingepland.
Drie beheermodellen
| On-premises | Duitse cloud | Hyperscaler | |
|---|---|---|---|
| Dataopslag | Uw datacenter, uw buildservers en HSM | Datacenters in Duitsland, beheerd volgens ISO 27001 | Azure, AWS of Google Cloud, regio naar keuze |
| Beheer | Uw team of OTOKO® als managed service | OTOKO®, met auditrechten voor de audits van uw klanten | Gedeeld, platformdiensten door de aanbieder |
| Tools | Kubernetes, GitLab, netwerk-HSM voor code signing | Gehost Kubernetes-platform, HSM as a Service, back-up met Veeam | Beheerde Kubernetes-diensten, cloud-HSM, pipelinediensten van de aanbieder |
| Geschikt voor | Ondertekeningssleutels, buildomgevingen met strenge klanteisen | SaaS voor klanten uit gereguleerde sectoren met soevereiniteitseisen | SaaS met internationale klanten, piekbelasting, testomgevingen |
| Compliance | Volledige controle, bewijsstukken uit uw ISMS | Verwerking door een verwerker volgens de AVG, locatie Duitsland, bewijs voor klantaudits | Verwerking door een verwerker, modelcontractbepalingen, gedeelde verantwoordelijkheid per dienst |
Samenwerking
Project
Een duidelijk afgebakend project zoals een ondertekeningsdienst in de HSM of een ontwikkelaarsplatform, met een vast resultaat, mijlpalen en acceptatie.
- Assessment, concept, implementatie, overdracht
- Vaste prijs of nacalculatie per mijlpaal
- Geschikt voor code signing, platformopbouw en CRA-gereedheid
Teamversterking
Platformengineers, security engineers of ontwikkelaars werken in uw teams, met uw tools en volgens uw definition of done.
- Inwerken in uw repositories, processen en richtlijnen
- Schaalbaar naar projectverloop
- Geschikt voor teams met capaciteitstekorten vóór releases of audits
Managed service
OTOKO® beheert platform, cloudaccounts of ondertekeningsdienst met afgesproken serviceniveaus, rapportages en de meldroutes die NIS2 vereist.
- Monitoring, updates, sleutelrotatie en support
- Meldproces, hersteltests en auditrechten in het contract
- Geschikt voor aanbieders zonder eigen beheerteam voor platform of HSM
Standaarden en bewijsvoering
Wat elk voorschrift van IT- en softwarebedrijven vereist en wat OTOKO® daarvoor levert.
| Voorschrift | Vereist | OTOKO® levert |
|---|---|---|
| ISO 27001 | ISMS met risicobeoordeling, verklaring van toepasselijkheid, maatregelen uit bijlage A en jaarlijkse surveillance-audits | Opbouw van het ISMS, verklaring van toepasselijkheid, technische maatregelen in platform en pipeline, voorbereiding op de certificeringsaudit |
| SOC 2 | Toetsing van controls volgens de Trust Services Criteria van het AICPA, als Type I op een peildatum of Type II over een periode | Controlraamwerk met mapping naar ISO 27001, geautomatiseerd bewijs uit cloud en pipeline, voorbereiding op het onderzoek door de accountant |
| NIS2 | Risicobeheersmaatregelen volgens artikel 21, gefaseerde melding van significante incidenten, beveiliging van de toeleveringsketen en verantwoordelijkheid van het bestuur | Toepasselijkheidsanalyse, maatregelenplan, meldproces met sjablonen, leveranciersregister, trainingsmateriaal voor het bestuur |
| Cyber Resilience Act | Beveiliging door ontwerp, SBOM, afhandeling van kwetsbaarheden gedurende de ondersteuningsperiode, melding van actief uitgebuite kwetsbaarheden en CE-markering | Productclassificatie, gap-analyse, SBOM-proces, meldproces, technische documentatie voor de conformiteitsbeoordeling |
| AVG | Gegevensbescherming door ontwerp, verwerking door een verwerker, register van verwerkingsactiviteiten en waarborgen bij doorgifte naar derde landen | Privacyconcept voor SaaS-producten, verwerkersovereenkomst, versleuteling met sleutels in de HSM, beheer in Duitsland |
Veelgestelde vragen
Goede vragen. Heldere antwoorden.
15 antwoorden over uw sector, het project en het beheer daarna.
Sector & aandachtsgebieden6 vragen
Welke IT-oplossingen voor IT- en softwarebedrijven biedt OTOKO® aan?
Het aanbod omvat interne ontwikkelaarsplatformen op Kubernetes, veilige softwareontwikkeling met SBOM en ondertekende builds, code signing met sleutels in de HSM en het beheer van cloud- en SaaS-platformen onder NIS2. Daarnaast specialisten die uw engineeringteams versterken, en gereedheid voor de Cyber Resilience Act met een PQC-roadmap. Elk aandachtsgebied kunt u afzonderlijk of als pakket afnemen.
Waarom zouden code-signing-sleutels in een HSM moeten liggen?
Met een gestolen ondertekeningssleutel kunnen aanvallers malware als uw officiële update verspreiden. In de HSM wordt de sleutel gegenereerd en verlaat hij het apparaat niet in klare tekst, en elke handtekening vereist een autorisatie en wordt gelogd. Voor publiek vertrouwde code-signing-certificaten eisen de Baseline Requirements van het CA/Browser Forum sowieso een sleutel in hardware.
Valt ook ons softwarebedrijf onder NIS2?
Dat hangt af van activiteit en omvang. Aanbieders van clouddiensten, datacenters en managed services vallen vanaf middelgrote omvang direct onder NIS2, pure softwareproducenten meestal niet. Veel bedrijven krijgen de eisen echter via hun klanten, die de beveiliging van hun toeleveringsketen moeten aantonen. Wij werken met exploitanten van kritieke infrastructuur en gereguleerde sectoren en kennen daarom de clausules die zulke klanten in contracten opnemen.
Wat vereist de Cyber Resilience Act van softwareproducenten?
Wie software of apparaten met software in de EU in de handel brengt, moet beveiliging door ontwerp aantonen, een SBOM opstellen, kwetsbaarheden gedurende de ondersteuningsperiode verhelpen en beveiligingsupdates leveren. Actief uitgebuite kwetsbaarheden moeten sinds september 2026 worden gemeld, de volledige verplichtingen met CE-markering gelden vanaf december 2027. Pure SaaS-aanbiedingen vallen er doorgaans niet onder, de bijbehorende apps en clients wel.
Hoe werken specialisten van OTOKO® mee in ons team?
Na een afstemming van eisen en profielen stellen wij specialisten voor, die u samen met ons selecteert. Zij werken in uw sprints, repositories en code reviews, met toegang volgens het principe van minimale rechten. Eén team begeleidt u van advies tot beheer, zodat platform, beveiliging en capaciteit van één aanbieder komen en de omvang met het project meegroeit of krimpt.
Ondersteunt OTOKO® bij ISO 27001 en SOC 2?
Ja. Wij bouwen het ISMS volgens ISO 27001 op, koppelen de controls tegelijk aan de Trust Services Criteria van SOC 2 en voeren de technische maatregelen in platform en pipeline uit. Bewijs zoals toegangslogs, wijzigingsregistraties en hersteltests ontstaat geautomatiseerd. Het certificaat wordt verleend door een geaccrediteerde certificatie-instelling, het SOC 2-rapport wordt opgesteld door een onafhankelijke accountant.
Start & uitvoering5 vragen
Kunnen wij met één aandachtsgebied beginnen?
Ja. Wij kunnen eerst een concrete taak afbakenen. Daarbij kijken wij naar de interfaces met de overige infrastructuur en stemmen wij vóór de uitvoering af welke diensten tot de opdracht behoren.
Wat kunnen wij het best voorbereiden voor het kennismakingsgesprek?
Een korte beschrijving van de uitdaging, de betrokken systemen en uw gewenste resultaat is voldoende om te beginnen. Bekende data en de juiste contactpersonen helpen daarnaast. Toegangsgegevens of vertrouwelijke systeemdocumentatie horen niet thuis in een eerste contactaanvraag.
Wie zou bij het project betrokken moeten zijn?
Platformarchitect: Ontwikkelaarsplatform, Kubernetes, GitOps. Security engineer: Secure SDLC, SBOM, kwetsbaarhedenbeheer. Cryptografiespecialist: HSM, code signing, PQC-roadmap. Site Reliability Engineer: Beheer, monitoring, incident response. Complianceadviseur: NIS2, Cyber Resilience Act, ISO 27001, SOC 2. Projectleiding: Mijlpalen, acceptaties, rapportages.
Hoe worden planning en inspanning bepaald?
Wij kijken naar systemen, interfaces, de stand van de documentatie en operationele randvoorwaarden. Een afgestemde omvang en mijlpalen vormen de basis voor de inschatting van de inspanning. Een vaste doorlooptijd zonder deze gegevens zou niet betrouwbaar zijn.
Wat levert de eerste projectfase op?
Platform, pipelines, sleutels en lacunes in de regelgeving Geprioriteerde lijst met maatregelen, sleutelinventaris, gap-analyse voor NIS2, CRA en ISO 27001
Beheer & doorontwikkeling4 vragen
Welke vormen van samenwerking zijn mogelijk?
Project: Een duidelijk afgebakend project zoals een ondertekeningsdienst in de HSM of een ontwikkelaarsplatform, met een vast resultaat, mijlpalen en acceptatie. Teamversterking: Platformengineers, security engineers of ontwikkelaars werken in uw teams, met uw tools en volgens uw definition of done. Managed service: OTOKO® beheert platform, cloudaccounts of ondertekeningsdienst met afgesproken serviceniveaus, rapportages en de meldroutes die NIS2 vereist.
Hoe verloopt de overdracht naar het beheer?
Monitoring, audits, kennisoverdracht Monitoring, sleutelrotatie, begeleiding bij audits en meldingen, stapsgewijze overdracht
Kunnen wij later nog vestigingen of systemen toevoegen?
Dat kan al in het eerste concept worden meegenomen. Gedocumenteerde interfaces en herbruikbare regels vormen een basis voor de uitbreiding. Elke extra vestiging en elk nieuw systeem wordt echter op de eigen specifieke eisen getoetst.
Hoe blijft de oplossing op lange termijn beheerbaar?
Verantwoordelijkheden, terugkerende taken en wijzigingsprocessen worden samen met de technische uitvoering vastgelegd. Documentatie en kennisoverdracht helpen uw team in de dagelijkse praktijk. Welke werkzaamheden en doorlopende ondersteuning daarbij horen, wordt afgesproken in de omvang van de dienstverlening.
IT- en softwaresector
Laten we de volgende stap bespreken.
Laten we bespreken hoe uw platform veiliger wordt en uw team de capaciteit krijgt die het nodig heeft.
Kennismakingsgesprek plannen
