Skip to content

Certifications & Security Assessments

To demonstrate our commitment to information security and data integrity, the vHaaS platform aligns with recognized industry security frameworks. This document outlines our compliance status, implemented controls, and strategic security certification roadmap.

1. Minimum Viable Secure Product (MVSP)

The Minimum Viable Secure Product (MVSP) is a lightweight yet rigorous security baseline — a list of essential application security controls that enterprise-ready products and services should implement. It is maintained by the MVSP Working Group and designed to be simple to implement while providing a solid foundation for secure and resilient systems.

Compliance Statement: Pilot Phase

During the vHaaS Pilot Phase (Closed Beta), the platform fully adheres to and implements the MVSP controls. This ensures a robust enterprise security posture for our pilot clients from day one, without impeding rapid iterative software deployment.

About this checklist

This section is the consolidated MVSP compliance deliverable shared between the vHaaS security and legal/compliance functions. It maps each MVSP control to its concrete vHaaS implementation and is intended for procurement, compliance, and legal review by prospective and pilot clients. It follows the MVSP control structure (v3.0, the latest release) across four control families: Business, Application Design, Application Implementation, and Operational. Reference: MVSP Controls · MVSP FAQ.

Business Controls

1.1 External Vulnerability Reports

Publish a vulnerability disclosure policy that defines testing scope, provides a legal safe harbor, and gives a contact for security reports; document triage and remediation procedures; respond within a reasonable time frame.

✅ vHaaS:

  • Disclosure policy covering testing scope, legal safe harbor, and contact details published via Security Advisories and referenced through security.txt (RFC 9116).
  • Security reports are received and handled by the Vector Product Security Incident Response Team (PSIRT) at psirt@vector.com.
  • Reports are acknowledged within a reasonable time frame; vulnerabilities are triaged and patched consistent with the SLAs in control 3.4.

1.2 Customer Testing

On request, enable customers or their delegates to test the security of the application against a production-equivalent environment that contains no production data. Reasonable testing restrictions may apply.

✅ vHaaS:

  • Customer security testing is available on request; a dedicated test environment can be provisioned per customer.
  • Non-production environments do not contain production data.
  • Applicable security measures are documented in the Security Concept & TOMs.

1.3 Self-Assessment

Perform and make available annual security self-assessments using the latest MVSP release.

✅ vHaaS:

  • Security self-assessments are performed at least annually. Following the pilot phase, CSA STAR (see Section 3) becomes the primary assessment framework.

1.4 External Testing

Contract a security vendor to perform comprehensive penetration tests at least annually.

✅ vHaaS:

  • Independent gray-box penetration test conducted in April 2026 (see Section 2).
  • Penetration tests are scheduled to recur annually; regular vulnerability scans are operational.

1.5 Training

Implement role-specific security training relevant to each personnel function.

✅ vHaaS:

  • The team has completed security self-training on OWASP and secure development practices.
  • Information-security awareness training (including TISAX awareness) has been completed.

1.6 Compliance

Comply with relevant industry security standards and with the laws and regulations of applicable jurisdictions (e.g. GDPR, Standard Contractual Clauses), including data-localization requirements.

✅ vHaaS:

  • GDPR compliance is implemented through the Data Processing Agreement (AVV / DPA).
  • Logical multi-tenancy enforces organization-scoped data isolation.
  • EU data localization is described in the Security Concept & TOMs.

1.7 Incident Handling

Notify relevant parties of any security breach affecting sensitive information within 72 hours of discovery, including the nature of the breach, contact information, consequences, and remediation measures.

✅ vHaaS:

  • All customers hold a contract (AVV / DPA) to use vHaaS — there are no users without a contractual relationship.
  • A dedicated customer security-contact channel is maintained, enabling breach notification to all affected customers within 72 hours of discovery.

1.8 Data Handling

Ensure media-sanitization processes based on NIST SP 800-88 (or equivalent) are implemented for storage media holding unencrypted production data.

✅ vHaaS:

  • Media sanitization for cloud storage is performed by AWS in line with NIST SP 800-88 under the shared-responsibility model.
  • Sanitization of on-premises hardware is handled by Vector's device-management processes.

Application Design Controls

2.1 Single Sign-On

Implement single sign-on using modern, maintained, industry-standard protocols for all customers at no additional cost.

✅ vHaaS:

  • SSO is implemented via Vector ID (OIDC / SAML) for all user logins.

2.2 HTTPS-Only

Redirect HTTP traffic to HTTPS, address issues found by modern TLS scanners, send a long-lived Strict-Transport-Security header, and set authentication cookies as Secure.

✅ vHaaS:

  • HTTP requests are redirected to HTTPS with the same URI and a 301 status code.
  • TLS scanning was performed and findings were addressed (see control 2.3).
  • Strict-Transport-Security: max-age=63072000; includeSubDomains; preload is included on all responses.
  • No authentication cookies are used.

2.3 Security Headers

Apply security headers that reduce attack surface: a minimally permissive Content Security Policy, framing controls, and disabled caching for sensitive endpoints.

✅ vHaaS:

  • A Content Security Policy (CSP) is enforced.
  • X-Frame-Options is set to same-origin.
  • Cache-Control: no-store, no-cache is set on all backend endpoints.
  • Security headers were validated during the April 2026 gray-box penetration test.

2.4 Password Policy

Where password authentication supplements SSO, enforce strong storage (memory-/CPU-hard hashing, salting), no restrictive character/length limits below 64, verified password changes, lockout/brute-force protection, and no default passwords.

✅ vHaaS:

  • vHaaS performs no local password authentication; all authentication is delegated to the Vector ID identity provider via SSO (see control 2.1).
  • Vector ID supports both passwords and passkeys as authentication methods.
  • Password authentication requires a minimum length of 15 characters. The policy follows the recommendations of the German Federal Office for Information Security (BSI), which prioritizes password length over complexity.

2.5 Security Libraries

Use modern, maintained frameworks and libraries that systemically escape outputs and sanitize inputs.

✅ vHaaS:

  • All database access uses the SQLModel ORM — no raw SQL.
  • API inputs are validated with strict Pydantic schemas.
  • The React frontend auto-escapes output to prevent XSS, complemented by HTML-sanitization middleware on backend routes.
  • Library security was validated during the April 2026 gray-box penetration test.

2.6 Dependency Patching

Keep third-party dependencies maintained and up to date, applying security updates of medium severity or higher on the application patching schedule and prioritizing Known Exploited Vulnerabilities.

✅ vHaaS:

  • Renovate automates dependency-update pull requests.
  • Trivy regularly scans container images for vulnerabilities.
  • Software Composition Analysis (Black Duck) runs automatically with each release.

2.7 Logging

Log authentication events, CRUD operations on users and objects, security-relevant configuration changes, and owner access to customer data. Logs must include user ID, IP, timestamp, action, and object; be retained at least 30 days; and exclude sensitive payloads.

✅ vHaaS:

  • Request-logging middleware captures all API requests with user ID, IP address, timestamp, HTTP method, and URL path.
  • Authentication failures are logged with structured category and detail; role changes are logged with old and new values to detect privilege escalation.
  • Operator and administrator access to customer data is captured by the same middleware, providing access transparency.
  • Logs are shipped to Loki with OpenTelemetry trace context; sensitive data (tokens, API keys) is redacted.
  • Logging cannot be disabled by application users; logs are retained for at least 30 days.

2.8 Encryption

Use modern, industry-standard encryption to protect sensitive data in transit and at rest, including backups.

✅ vHaaS:

  • Data in transit is encrypted with TLS for all communication outside the cluster.
  • RDS PostgreSQL storage is encrypted with an AWS-managed KMS key.
  • S3 buckets use SSE-KMS with a dedicated KMS key (automatic rotation) and enforce TLS-only access via bucket policies.
  • EBS volumes are encrypted via the gp3 StorageClass; secrets use a dedicated KMS key with automatic rotation.

Application Implementation Controls

3.1 List of Data

Maintain a list of sensitive data types the application is expected to process.

✅ vHaaS:

  • A list of sensitive data types is maintained and shared with customers under the applicable Data Processing Agreement (AVV / DPA) or NDA.

3.2 Data Flow Diagram

Maintain an up-to-date diagram showing how sensitive data reaches and is stored in the system.

✅ vHaaS:

  • Up-to-date data-flow diagrams are maintained and shared with customers under the applicable Data Processing Agreement (AVV / DPA) or NDA.

3.3 Vulnerability Prevention

Train developers and implement guidelines to prevent authorization bypass, insecure session management, injections, cross-site scripting, cross-site request forgery, and unsafe handling of untrusted data.

✅ vHaaS:

  • Security self-training has been completed (see control 1.5).
  • Development guidelines are based on the OWASP Cheat Sheet Series.
  • Threat-modeling sessions build awareness of common vulnerability classes.
  • Vulnerability-prevention measures were validated during the April 2026 gray-box penetration test.

3.4 Time to Fix Vulnerabilities

Deploy patches for materially security-impacting vulnerabilities within 90 days of discovery, prioritizing those under active exploitation, and publish a bulletin where customer action is required.

✅ vHaaS:

  • A documented vulnerability-management process defines remediation SLAs: Critical ≤ 72 h · High ≤ 7 days · Medium ≤ 30 days · Low ≤ 90 days.
  • Vulnerabilities under active exploitation are prioritized; security bulletins are published where customer action is required.

3.5 Build and Release Process

Use version control and a consistent build process that generates build provenance (SLSA Build Level 1), and store credentials separately from source code.

✅ vHaaS:

  • Version control (GitLab) and a consistent CI build process (GitLab CI) are in place, aligned with SLSA Build Level 1.
  • Credentials are stored separately from source code in AWS Secrets Manager (cloud) and HashiCorp Vault (on-premises).

Operational Controls

4.1 Physical Access

Validate physical security of relevant facilities: layered perimeter and interior controls, managed key access, entry/exit logs, and an unauthorized-access response plan.

✅ vHaaS:

  • Application data is hosted in AWS; physical security is provided by AWS and covered under its certifications (including TISAX-aligned assurance).
  • Access to Vector-managed devices and servers follows Vector's corporate physical-security policies.

4.2 Logical Access

Restrict sensitive-data access to users with legitimate need authorized by the data owner, deactivate redundant accounts promptly, review access regularly, and require MFA for remote access to customer data or production systems.

✅ vHaaS:

  • Logical access uses a Relationship-Based Access Control (ReBAC) model implemented with OpenFGA across resource types and granular relations.
  • Multi-tenancy enforces organization-scoped data isolation.
  • Multi-factor authentication is provided through the SSO identity provider (Vector ID); termination of a user's Vector ID identity immediately revokes access to vHaaS.
  • Quarterly access reviews validate need-to-know and remove redundant accounts and expired grants.

4.3 Sub-Processors

Maintain a list of third parties with access to customer data, make it available on request, and assess them annually against the latest MVSP release.

✅ vHaaS:

  • AWS — cloud infrastructure, compute, storage, and database.
  • Vector ID — identity provider (SSO).
  • Cloudflare — CDN, DNS, and tunnel management.
  • Sub-processors are assessed annually by reviewing their compliance certifications (e.g. SOC 2, ISO 27001).

4.4 Backup and Disaster Recovery

Back up all data to a location separate from where the application runs, and maintain and test disaster-recovery plans at least annually or after significant changes.

✅ vHaaS:

  • RDS automated backups (7-day retention) with a Multi-AZ deployment and read replica.
  • AWS Backup plan: daily (35-day retention) plus weekly (90-day retention); EBS snapshots retained 14 days.
  • S3 versioning is enabled on all buckets with 90-day noncurrent-version expiration; deletion protection is enabled on the production database.
  • A documented disaster-recovery plan is tested against a schedule of quarterly, semi-annual, and annual recovery exercises.

2. Initial Penetration Test

Prior to the pilot phase launch, the vHaaS platform underwent an independent penetration test conducted by an accredited external security firm.

Parameter Details
Date Completed April 2026
Type Gray-box penetration test
Scope Web application layer (OWASP Top 10), REST API, authentication flows, network perimeter
Conducting Party Accredited external security firm, independent of the development team
Findings All identified findings have been remediated prior to pilot launch
Attestation Clients may request an executive summary confirming the assessment was performed and all findings were resolved. Full reports are available for reference under NDA.

3. Cloud Security Alliance (CSA STAR)

Following the pilot rollout phase, vHaaS will expand its compliance portfolio by adopting the Cloud Security Alliance (CSA) standards.

                  CSA STAR Maturity Roadmap

   ┌────────────────────────────────────────────────────────┐
   │ Q4 2026: CSA STAR Level 1 (Self-Assessment)             │
   │ - CAIQ (Consensus Assessments Initiative Questionnaire) │
   │ - Public registry listing                              │
   └───────────────────────────┬────────────────────────────┘
                               │
                               ▼
   ┌────────────────────────────────────────────────────────┐
   │ Long-term: CSA STAR Level 2 (Third-Party Audit)        │
   │ - Full independent SOC 2 / ISO 27001 audit alignment   │
   │ - Continuous monitoring of CSA STAR controls           │
   └────────────────────────────────────────────────────────┘

3.1 CSA STAR Level 1 (Self-Assessment)

  • Target Timeline: Q4/2026 (planned).
  • Scope: We will publish our completed Consensus Assessments Initiative Questionnaire (CAIQ) in the official CSA Registry. This questionnaire provides detailed answers on over 250 control points across 16 security domains, providing ultimate transparency to security procurement teams.

3.2 CSA STAR Level 2 (Third-Party Certification)

  • Strategic Goal: Following Level 1, we plan to undergo a formal third-party audit. This audit bridges CSA STAR requirements with an official ISO 27001 and SOC 2 Type II assessment, ensuring continuous external validation of our operational security.