Security as a practice,
not a poster.
Two things matter when a customer's auditor lands on this page: how we build XplicitTrust, and how XplicitTrust helps you build the evidence your auditors want. Below is the substance behind both.
Your obligations, our controls
XplicitTrust is the technical substrate auditors look for. Drop it into your NIS-2, ISO 27001, CRA, or DORA scope and it carries part of the load.
NIS-2 essential and important entities
Identity, MFA, logging, segmentation, on day one.
NIS-2 Article 21 mandates a baseline of technical and organisational measures. XplicitTrust covers a meaningful slice: SSO and MFA via your IdP, posture-checked access, audit logs you can export, and identity-based microsegmentation. Map it directly to your TOM list.
ISO 27001 & BSI IT-Grundschutz
Drops into the access, logging, and supplier chapters of your ISMS.
For Annex A controls around access control, authentication, monitoring, and supplier relationships, XplicitTrust supplies the technical substrate. Audit events export to your SIEM. Sub-processors are documented, named, and EU-only. Your ISMS auditor sees evidence, not boilerplate.
Cyber Resilience Act (CRA)
Bring identity-aware access in before you ship.
If you ship products that fall under the CRA, retrofitting access control after release is expensive. XplicitTrust gives the connectivity and policy layer that makes the CRA's access, integrity, and update-handling requirements easier to satisfy on day one rather than at recall time.
GDPR & DORA
EU residency and exportable evidence, without bolt-ons.
Hosting and operations stay in the EU. Audit trails, processor relationships, and incident-response hooks are documented in shapes auditors and DPOs actually accept. The compliance story is in the product, not patched in by a second vendor.
How we build XplicitTrust
Security shows up in the day-to-day, not on a slide. These are the practices that sit between a feature idea and a release tag.
Secure development lifecycle
Threat modelling, code review, security checks on every change.
Features pass through threat modelling at design time and security review at commit time. Dependencies and base images are continuously scanned. Lessons from production go back into the design playbook so the same class of issue doesn't recur.
Build pipeline with security gates
No green build skips the checks.
Static analysis, dependency vulnerability scanning, and policy checks run on every CI run. A failing gate fails the release. Reproducibility and signing sit inside the pipeline, not bolted on afterwards.
SBOM per release
Supply chain you can audit, not infer.
Every release ships with a Software Bill of Materials. When a CVE lands, customers can match it against the version they actually run, without waiting for our advisory. Supply-chain transparency is the deliverable, not the slogan.
Coordinated vulnerability disclosure
Researchers welcome. Patches by SLA.
A documented disclosure process, a reachable security contact, and stated fix-time targets by severity. Reports come in, fixes go out, customers get notice. No black box between a researcher and a patch.
Researchers: see our
security.txt
for the disclosure contact and PGP key.
Need a questionnaire response, DPA, or SBOM?
Tell us which artifact your procurement or security team is after. We'll route the request to the right partner and to us, and get back to you quickly.