Technical measures

This page focuses on the "how" of security: the specific tools, configurations, and architectural decisions that protect data within the VTS ecosystem.

VTS is available in two variants: the cloud-based VTS online and the on-premise VTS offline. While both share the same core system architecture, they differ in certain implementation details. Where applicable, these differences are highlighted in the sections below.

Infrastructure

Hosting environment

The hosting environment refers to the infrastructure and platform on which the VTS software runs and serves its users.

Data storage

VTS relies on a relational SQL database for data storage. The database server in use is Microsoft SQL Server which provides a high-performance, managed relational database with built-in encryption at rest and in transit.

Availability

VTS aims to provide high availability by taking technical precautions against system failures, hardware defects, or other disruptions. Automatic recovery mechanisms ensure process restarts in the event of an interruption, ensuring maximum uptime and operational stability without manual intervention. Important processes are designed to run to completion even in the event of system disruptions.

Resilience

Resilience is understood as the ability of IT systems to remain stable and functional even under adverse conditions or extreme load situations. The intention is to guarantee permanent operational readiness against internal errors or external influences (e.g., load peaks).

• Architecture: The distributed design and service-oriented architecture allows for independent scaling and hardens against possible faults.

• Load handling: VTS decouples time-intensive operations, such as generation of test results, bulk data export and import, and mass data deletion, from the primary request path using a durable message queue. Dedicated background workers consume queue messages and process jobs asynchronously, ensuring that the application remains responsive even under heavy load. Because messages are retained in the queue, no tasks are lost if individual system components are stopped or restarted.

• Scalability: VTS is designed so that key components may be scaled vertically or horizontally in case of high load and peaks.

• Retry mechanisms: All outbound service calls and database operations in VTS use an exponential back-off retry policy with jitter. Transient failures, such as brief network interruptions or momentary database unavailability, are retried up to a configurable limit before reporting an error to the caller. Non-retryable errors (e.g., authentication failures) are reported immediately without retry. Retry state is logged for observability, enabling early detection of systemic issues.

Recoverability

This protection goal requires the ability to quickly restore access to personal data and its availability following a physical or technical incident. The GDPR requires proactive concepts for this, such as backup strategies and disaster recovery plans.

Backups

Internal access control

Internal services of VTS follow a zero-trust model: no service inherently trusts another by virtue of network location alone. Secrets and credentials are never hard-coded in configuration files or application source code, but rather kept in secured vaults.

Data management

Data model

VTS utilizes a purpose-driven data model that strictly enforces the principle of data minimization. Every data entity and its associated processing activity is formally documented to ensure that only the minimum information necessary for system functionality is collected. Central to this architecture is a strict multi-tenant separation, which ensures that data from different clients is isolated at the database level through rigorous access control mechanisms, effectively preventing any unauthorized cross-access or data leakage. This structured modelling approach guarantees that all processing activities are transparently mapped to specific operational goals while maintaining the highest level of data integrity and client confidentiality.

Tenant separation

VTS implements a comprehensive logical tenant separation designed to protect the confidentiality, integrity, and availability of client data. This systematic isolation ensures that all sensitive data, including system logs and audit trails, are strictly partitioned at the database and application levels. Our identity management framework enforces this separation by ensuring that credentials, roles, and access rights are scoped exclusively to the respective tenant, preventing any unauthorized cross-access.

Logging

To address the requirements for automated monitoring and event tracing, VTS implements a standardized logging architecture across all services and client applications. This system captures critical technical and security-relevant events, including user logins, failed authentication attempts, service startups/shutdowns, and system errors, ensuring that every entry is mapped to a unique source or user identity for clear auditability.

SCHUHFRIED ensures that the processing of all technical and functional logging data is subject to a strict purpose-limitation and does not contain personal data. Our logging procedures are exclusively designed to maintain operational stability (troubleshooting and capacity management) and ensure information security (incident detection and defense). Furthermore, any use of data for business metrics is restricted to the generation of anonymous usage statistics. Logged information is not shared with third parties.

Data integrity

The protection goal of integrity refers to the correctness and intactness of data and system functions. The intention of the GDPR is to ensure that information cannot be modified, deleted, or manipulated by unauthorized persons or unintentionally throughout the entire processing chain.

• Data consistency: SQL Server transactional integrity ensures that data is not partially written or corrupted during operations.

• Referential integrity: Foreign key constraints and database-level check constraints are enforced at the storage layer, independently of application logic. This provides a second line of defense against inconsistent data states that could arise from application bugs or direct database access.

• Input validation: All data entering the system, whether from UI forms, file imports, or API calls, is validated against strict type, range, and format constraints before being persisted. Malformed or out-of-range input is rejected, preventing data corruption at ingestion time.

• Test result signing: Internal logic prevents unauthorized modification of test results once finalized, preventing that test results can be corrupted in any way.

Encryption and pseudonymization

Encrypted communication (data in transit)

All data transmission within the VTS ecosystem is secured using HTTPS (TLS 1.3). This covers all interactions between user interfaces (browsers, desktop clients) and VTS services, as well as internal service-to-service communication.

Encrypted storage (data at rest)

VTS utilizes Microsoft SQL Server technology for persistent data storage, which supports Transparent Data Encryption (TDE) to protect database files at the physical storage level.

Encrypted file storage

Temporary files generated during result reporting process operations are secured to prevent unauthorized access. These files are stored in encrypted ZIP archives (AES-256) utilizing password protection to ensuring that even temporary artifacts remain secure before they are securely deleted or delivered.

Pseudonymization

While VTS is designed to handle personal data, it minimizes the requirement for identifiable information.

• Minimal data: Only a last name is technically mandatory for creating a test person.

• Pseudonyms: Users can utilize pseudonyms or codes instead of real names.

• Date of birth: If a date of birth is required, the system can be configured to store only the year of birth, significantly reducing the identifiability of the test person.

Identity and access management

Authentication and authorization

To ensure the security of our services, VTS implements a multi-layered identity and access management framework based on industry-standard protocols. We utilize OpenID Connect for secure user authentication and OAuth2 for robust authorization, ensuring that identities are verified and permissions are delegated according to modern security best practices. For programmatic access and service-to-service communication, we employ secure API keys to maintain strict control over our interfaces. Access within the system is managed through a role-based authorization system, which enforces the principle of least privilege by ensuring that users and services can only access the specific data and functions required for their defined roles.

VTS supports Multi-Factor Authentication (MFA) through integration with external identity providers.

Access control

VTS implements a role-based access control (RBAC) system that is applied in combination with security levels, allowing administrators to assign access rights for users.

User sessions

The login state of users is only preserved for the current user session. As soon as the client application is closed (VTS Admin Client or Browser), sessions are terminated and upon the next usage, users are asked to re-authenticate.

Cookie usage

VTS uses a minimal set of technically necessary cookies required for the application to function. No tracking, analytics, or advertising cookies are used.

All cookies are set as HttpOnly and Secure. They expire when the browser session ends.

Password security

VTS applies rules for password security for its built-in accounts.

Both VTS online and VTS offline support the use of external accounts for authentication. With such accounts, customers are able to choose custom password requirements.