Security, compliance and sovereignty — made transparent.

In SaaS operation, we store the platform data of VAMIDAST exclusively in data centres in Germany; data at rest is encrypted, and data in transit is protected by TLS. The contracting party is based in Germany, German law applies and the place of jurisdiction is Germany. Where a function involves external service providers — such as Anthropic or OpenAI for the AI steps — we disclose the provider, purpose and processing region in the sub-processor table. In on-premises operation, VAMIDAST runs on your own Kubernetes cluster.

VAMIDAST is operated by VamiSec GmbH, whose ISMS is certified to ISO/IEC 27001:2022 by the DAkkS-accredited Proks Certification GmbH (certificate DE-IS-20250191, valid until 18 September 2028). According to the certificate, the scope is the “provision of consulting services in the field of information security, associated digital products and supporting information-processing facilities …” (our translation of the German certificate). VAMIDAST is not named individually; there is no separate product certificate.

Sign-in to VAMIDAST uses multi-factor authentication (MFA). For single sign-on, VAMIDAST supports your own Microsoft Entra ID directory (OIDC authorization code flow with PKCE). A directory is only admitted once a platform administrator has onboarded it and your Global Administrator has consented; MFA and identity verification are then handled by Entra. VAMIDAST requests only the sign-in permissions openid, profile and email — no Microsoft Graph permissions — and stores no Microsoft tokens. Permissions are granted solely within VAMIDAST: role or group claims in tokens grant no rights. With SSO, password sign-in is disabled by default; break-glass access exists only for platform administrators, with its own MFA and an audit entry on every use. VAMIDAST also supports local accounts with e-mail and password. You can revoke access in Entra at any time.

A deterministic engine drives every scan; the model only advises and never decides what is tested or what runs next. Within the scan flow, VAMIDAST uses AI at exactly three points: classifying the vulnerability class as a last resort, fallback payloads (detection strings only) when no tool fits or one fails, and triage of the grey zone. Every model output is schema-validated before use. The model receives response snippets limited to 2,000 characters by default, parameter names, payloads and finding evidence — never full bodies and never the test credentials for the target application. Response snippets and finding evidence may, however, contain personal data or secrets of the target application. VAMIDAST is LLM-agnostic. For the AI steps you choose the local Qwen3.8 in VamiSec's data centre in Sankt Augustin (on your own GPUs when on-premises), Anthropic Claude, OpenAI or your own LLM (BYOLLM). With Qwen3.8 the target data stays in Germany or on your own infrastructure; with Anthropic Claude or OpenAI the snippets are processed by the provider in the USA; with your own LLM the contractual relationship exists directly between you and the provider. Credentials for your own LLM are never stored in plain text, never logged and never returned. Optionally — triggered by the user after the scan and able to be disabled by the operator — the model can also draft accompanying remediation text. It cannot create findings or change ratings; cookies, bearer tokens and JWTs, key material and URL query values are removed beforehand, and AI-generated text is labelled in the PDF report. Without an LLM the scan keeps running; only fallback payloads and triage assistance are dropped.

We follow a defined incident response process as part of our ISO/IEC 27001-certified ISMS and notify affected customers; the details are governed by the DPA. Please report security vulnerabilities confidentially to security@vamisec.com — machine-readable per RFC 9116 at /.well-known/security.txt.

No. We do not use customer data as training data: we do not train or fine-tune any AI models with it, and we only connect external AI models under contractual terms that exclude training use. Whether and which external AI providers VAMIDAST uses is disclosed in the sub-processor table. If you use your own LLM (BYOLLM), the terms of your contract with that provider apply to that model.

Public documents are available directly. For the Statement of Applicability, the security whitepaper or completed questionnaires, a short request to security@vamisec.com is sufficient; evidence subject to an NDA is released after signing.

VAMIDAST is designed for safe scanning. A safety lock classifies every active request — baselines included — as read-only or state-changing and blocks it when in doubt (fail closed). There are three modes: Passive (crawling and reading only), Safe (default; state-changing endpoints only via precondition violation, no DELETE, PUT or PATCH) and Aggressive — only after explicit confirmation of a non-production environment; an environment value of “prod”, a mistyped value or an empty one falls back to Safe. Production systems are only scanned in Passive or Safe mode and only with authorisation. The deny list (such as logout, setup, DB reset) applies in every mode, destructive parameters such as password, role or deletion fields are never fuzzed directly, and rate limiting, timeouts and a request budget per endpoint are configurable. Approval of full testing for a scan is recorded in the audit log with the name of the requester.

Within VamiAppSec, in three ways: as a fixed stage of your CI/CD pipeline (GitLab, GitHub, Azure DevOps) — every build rolled out to staging is scanned, and confirmed findings above a severity threshold can stop the gate; on demand via CLI against any authorised target, with the same modes and safeguards; and continuously or on a schedule against production systems — there only in Passive or Safe mode and only with authorisation. VAMIDAST can be used standalone with its own dashboard, REST API and reports (PDF, SARIF 2.1.0, CSV) or fully integrated into VamiAppSec, where findings land in the same backlog as SAST, SCA, SBOM and secrets.

Yes. There is a product-specific data processing agreement (DPA) for VAMIDAST pursuant to Art. 28 GDPR, available on request via privacy@vamisec.com. The deletion and retention periods for your data are defined and governed by the DPA. Data at rest is encrypted, and data in transit is protected by TLS.