Sicherheit als Praxis,
nicht als Plakat.
Zwei Dinge zählen, wenn ein Auditor Ihrer Kunden auf dieser Seite landet: wie wir XplicitTrust bauen, und wie XplicitTrust Ihnen hilft, die Belege zu liefern, die Ihre Auditoren erwarten. Unten finden Sie die Substanz dahinter.
Ihre Anforderungen, unsere Controls
XplicitTrust ist die technische Grundlage, nach der Auditoren suchen. Bringen Sie es in Ihren NIS-2-, ISO 27001-, CRA- oder DORA-Scope, und es trägt einen Teil der Last.
NIS-2 wesentliche und wichtige Einrichtungen
Identität, MFA, Logging, Segmentierung ab Tag eins.
Artikel 21 NIS-2 verlangt eine Reihe technischer und organisatorischer Maßnahmen. XplicitTrust deckt einen relevanten Teil ab: SSO und MFA über Ihren IdP, Posture-geprüfter Zugriff, exportierbare Audit-Logs und identitätsbasierte Mikrosegmentierung. Direkt in Ihre TOM-Liste übertragbar.
ISO 27001 & BSI IT-Grundschutz
Setzt direkt in den Zugriff-, Logging- und Lieferanten-Kapiteln Ihres ISMS auf.
Für die Annex-A-Controls zu Zugriffskontrolle, Authentifizierung, Monitoring und Lieferantenbeziehungen liefert XplicitTrust die technische Grundlage. Audit-Events laufen in Ihr SIEM. Subprozessoren sind dokumentiert, namentlich, EU-only. Ihr ISMS-Auditor sieht Belege, keine Boilerplate.
Cyber Resilience Act (CRA)
Identitätsbasierten Zugriff einbringen, bevor Sie ausliefern.
Wenn Sie Produkte ausliefern, die unter den CRA fallen, ist nachträgliche Zugriffskontrolle teuer. XplicitTrust liefert die Konnektivitäts- und Policy-Schicht, die die CRA-Anforderungen an Zugriff, Integrität und Update-Handling am Tag eins erfüllbar macht, nicht erst beim Rückruf.
DSGVO & DORA
EU-Residenz und exportierbare Belege, ohne Bolt-ons.
Hosting und Betrieb bleiben in der EU. Audit-Trails, Auftragsverarbeitungen und Incident-Response-Hooks liegen in der Form vor, die Auditoren und DSBs tatsächlich akzeptieren. Die Compliance-Geschichte steckt im Produkt, nicht in einem zweiten Vendor.
Wie wir XplicitTrust bauen
Sicherheit zeigt sich im Tagesgeschäft, nicht auf einer Folie. Das sind die Praktiken zwischen Feature-Idee und Release-Tag.
Secure Development Lifecycle
Threat Modelling, Code-Review, Security-Checks bei jeder Änderung.
Features durchlaufen Threat Modelling im Design und Security-Review beim Commit. Abhängigkeiten und Base-Images werden kontinuierlich gescannt. Erkenntnisse aus dem Betrieb fließen zurück ins Design-Playbook, damit dieselbe Klasse von Problemen nicht wiederkehrt.
Build-Pipeline mit Security-Gates
Kein grüner Build umgeht die Prüfungen.
Statische Analyse, Dependency-Scanning und Policy-Checks laufen bei jedem CI-Run. Ein Gate-Fail ist ein Release-Fail. Reproduzierbarkeit und Signing sind Teil der Pipeline, nicht nachträglich aufgesetzt.
SBOM pro Release
Supply Chain, die Sie auditieren können, nicht erraten müssen.
Jedes Release wird mit einer Software Bill of Materials ausgeliefert. Wenn ein CVE einschlägt, können Kunden direkt gegen die Version prüfen, die sie tatsächlich einsetzen, ohne auf unsere Advisory zu warten. Supply-Chain-Transparenz als Lieferung, nicht als Slogan.
Coordinated Vulnerability Disclosure
Researcher willkommen. Patches mit SLA.
Ein dokumentierter Disclosure-Prozess, ein erreichbarer Security-Kontakt und definierte Fix-Zeitziele nach Severity. Reports kommen rein, Patches gehen raus, Kunden werden informiert. Keine Black Box zwischen Researcher und Patch.
Für Researcher: unsere
security.txt
mit Kontakt und PGP-Key.
Brauchen Sie eine Questionnaire-Antwort, einen AVV oder SBOM?
Sagen Sie uns, welches Artefakt Ihr Procurement- oder Security-Team braucht. Wir routen die Anfrage zum richtigen Partner und zu uns, und melden uns kurzfristig.