Trust & Compliance

Last updated: March 27, 2026

We know that tax and accounting workflows require a high level of operational trust. This page summarizes how we currently handle hosting, data processing, and contractual safeguards.

Operational Overview

The following points summarize the hosting, legal, contractual, and audit framework that applies across our services.

Data Location & Hosting

Persistent data storage remains in Germany. Depending on the agreed setup, data processing, including LLM-supported workloads, can take place within the EU, including Germany, Sweden, or France.

Regulatory Alignment

For professional secrecy contexts, our services are designed to support customer confidentiality requirements under §203 StGB. Relevant employees are bound in writing to confidentiality and documented instructions; contractual safeguards for personal data processing are provided through a DPA where applicable.

Contractual Data Protection

We conclude a DPA with customers to define responsibilities and safeguards for personal data processing.

API Data Handling

For our API services, customer payload content is generally not retained within Klardaten systems as persistent application data. Technical processing, short-lived intermediate storage in queues, and temporary debugging or error artifacts may occur where operationally necessary. Such artifacts are access-restricted and deleted once the relevant purpose no longer applies.

External Security Audit

The last external security audit was conducted in March 2026 and covered infrastructure, backend code, and connector code.

Evidence & Contact

The following documents and assurance points are available for procurement, legal, and security review.

A DPA is available on request for customer engagements involving personal data processing.
This page includes the current subprocessor overview.
This page includes a TOM summary.

For procurement, legal, or IT security questions, contact us at info@klardaten.com.

Product Scope by Service

This overview covers the main service-specific processing characteristics for commissioned processing.

Klarvos

Role: Klardaten acts as processor for customer content and personal data processed on behalf of the customer.
Stored: In managed-service setups, Klarvos stores workspace content and workflow-related application data in Germany. In self-hosted or partner-led setups, storage depends on the agreed deployment model.
Transient processing: User prompts, workflow steps, connected-system responses, and optional model inputs are processed for workflow execution. Short-lived technical buffering in queues and error-handling paths may occur where operationally necessary.
In logs: Routine logs contain primarily operational metadata and technical error information. Workflow and model execution events may be logged for support, troubleshooting, and traceability.
Not in logs: It is not intended to store customer content in routine operational logs.

Subprocessors

Amazon Web Services

Purpose: Primary managed hosting and service infrastructure

Location: Frankfurt region, Germany

Hetzner

Purpose: Internal development and fallback/backup infrastructure

Location: Nuremberg, Germany

Microsoft Azure

Purpose: AI model infrastructure for Klarvos

Location: Frankfurt region, Germany by default; Sweden on request; backup in France

Enterprise API

Role: Klardaten acts as processor for personal data processed through the service on behalf of the customer.
Stored: Customer payload content is generally not retained within Klardaten systems as persistent application data. Technical processing and short-lived intermediate storage in queues or debugging artifacts may occur where operationally necessary.
Transient processing: API requests are processed for the request flow, including DATEV-connected system access and, where configured, direct database access. Short-lived technical buffering in queues and error-handling paths may occur where operationally necessary.
In logs: Routine logs contain primarily operational metadata and technical error information required for operation and troubleshooting and are retained for 14 days. Temporary debugging or error artifacts may contain limited request context where operationally necessary; access is restricted and deletion occurs once the relevant purpose no longer applies.
Not in logs: It is not intended to store customer payload content in routine operational logs.

Subprocessors

Amazon Web Services

Purpose: Primary managed hosting and service infrastructure

Location: Frankfurt region, Germany

Hetzner

Purpose: Internal development and fallback/backup infrastructure

Location: Nuremberg, Germany

DATEVconnect Gateway

Role: Klardaten acts as processor for personal data processed through the service on behalf of the customer.
Stored: Customer payload content is generally not retained within Klardaten systems as persistent application data. Technical processing and short-lived intermediate storage in queues or debugging artifacts may occur where operationally necessary. DATEV and Windows credentials are stored only locally and in encrypted form on the customer's Windows systems, not at Klardaten.
Transient processing: Requests are processed for the integration flow between connected systems and DATEVconnect. Short-lived technical buffering in queues and error-handling paths may occur where operationally necessary.
In logs: Routine access logs contain primarily operational metadata and technical error information required to run and support the service and are retained for 90 days. Temporary debugging or error artifacts may contain limited request context where operationally necessary; access is restricted and deletion occurs once the relevant purpose no longer applies. We can provide retained access logs to customers on request.
Not in logs: It is not intended to store customer content or payload data in routine access logs.

Subprocessors

Amazon Web Services

Purpose: Primary managed hosting and service infrastructure

Location: Frankfurt region, Germany

Hetzner

Purpose: Internal development and fallback/backup infrastructure

Location: Nuremberg, Germany

Data Flows

The following simplified flows show the typical points of data origin, processing, and transfer across the relevant components.

DATEVconnect Gateway

Customer application <-> Klardaten API layer <-> Klardaten DATEVconnect Gateway service on the target system <-> DATEVconnect

DATEV and Windows credentials remain on the customer's Windows systems. Klardaten processes requests for the integration flow and may use short-lived technical buffering where operationally necessary.

Enterprise API

Customer application <-> Klardaten API layer <-> Klardaten Enterprise service on the target system <-> DATEV

Depending on the integration, processing can include direct access to configured DATEV-related systems or databases. Short-lived technical buffering in queues or error-handling paths may occur where operationally necessary.

Klarvos

User input or workflow trigger -> Klarvos application -> Klardaten API and connected systems -> optional LLM execution -> response or workflow action

LLM execution is optional and depends on the configured use case. Persistent workspace data remains in Germany; model execution can, depending on the agreed setup, run in Germany, Sweden, or France.

Processing Scope

For commissioned processing, the following scope is relevant for due diligence and contract review.

Processing Location

Data processing activities for commissioned processing are carried out exclusively within the EU or the EEA.

Access by Klardaten

Klardaten does not require routine access to customer content in normal operation. Access to customer data can occur only where operationally necessary, for example in a support or incident case, and then only under controlled conditions, for a defined purpose, and on the basis of customer authorization or documented instruction where applicable. Such access is role-based, logged, and designed to be traceable.

Role and Legal Basis

Where Klardaten processes personal data on behalf of customers, Klardaten acts as a processor under Art. 28 GDPR. The legal basis under Art. 6 GDPR for the respective processing activity is determined by the customer as controller.

Data Categories

Master data and contact details, such as name, address, email address, and telephone number.
Client, advisor, and user identifiers.
Metadata relating to mandates, permissions, and enabled DATEV modules.
Billing- and accounting-related data, such as posting records, accounts, and document or invoice metadata.
Technical communication and protocol data, such as timestamps, request IDs, and error codes.

Affected Data Subjects

The controller's clients, including companies and their contact persons.
Employees of the controller or its clients.
Where applicable, customers and suppliers of the controller's clients.
Users of the DATEV system, such as firm and client users.

Subprocessors Overview

This overview lists the currently used subprocessors, their purpose, their location, and the affected services.

Amazon Web Services

Purpose:: Primary managed hosting and service infrastructure
Location:: Frankfurt region, Germany
Affected services:: Klarvos, Enterprise API, DATEVconnect Gateway, Website

Hetzner

Purpose:: Internal development and fallback/backup infrastructure
Location:: Nuremberg, Germany
Affected services:: Klarvos, Enterprise API, DATEVconnect Gateway, Website

Microsoft Azure

Purpose:: AI model infrastructure for Klarvos
Location:: Frankfurt region, Germany by default; Sweden on request; backup in France
Affected services:: Klarvos

Customers are informed in writing in advance about intended changes to subprocessors. Required agreements under Art. 28(4) GDPR are concluded before a new subprocessor starts processing personal data.

Incident Handling

We maintain a documented process for handling security incidents, including defined escalation paths and internal documentation requirements. Customers are informed without undue delay where an incident affects their data or services, and we support them in meeting notification obligations under Articles 33 and 34 GDPR.

Technical and Organizational Measures

This TOM summary describes the main technical and organizational control areas relevant for customer due diligence. It does not replace the contractual TOM annex where applicable.

Confidentiality

Physical access to processing facilities is controlled by the relevant infrastructure providers at their data center locations. Primary managed infrastructure runs on Amazon Web Services in the Frankfurt region; Hetzner is maintained as internal development and fallback/backup infrastructure. Access to production systems requires personalized accounts and mandatory MFA. Access rights are role-based, logged, and reviewed under documented access management processes. Administrative access is restricted to secured VPN and SSH connections with key-based authentication. Data is encrypted in transit with TLS 1.2+ and at rest with AES-256. Key management is handled through the respective cloud KMS systems with access restrictions and rotation controls. Pseudonymization or anonymization is applied where technically feasible and contractually agreed.

Integrity and Availability

Encrypted backups are created as part of a documented backup process and stored redundantly across separate availability zones. Recovery procedures are tested on a regular basis. Systems are hardened according to documented baseline configurations. Security patches are prioritized and applied through a documented patch-management process based on severity and operational risk. Monitoring covers infrastructure, application errors, and security events. Security incidents are handled through documented response processes with escalation, documentation, and customer notification in line with GDPR requirements.

Endpoint Protection and Access Security

Device encryption is mandatory on company-managed endpoints. Connections to production systems are permitted only via encrypted channels, and public or unsecured networks are not permitted for production access. Removable media are disabled by default unless explicitly approved and encrypted. Password requirements, automatic screen locking, and endpoint security controls are enforced through internal security policies.

Organizational Measures

Access rights follow a strict need-to-know model and role changes are documented. Employees are bound in writing to confidentiality and documented instructions before accessing relevant systems or data. Internal security reviews and corrective actions are documented and tracked. Where customers operate under professional secrecy obligations, additional commitments under Section 203 StGB can be applied. Systems are configured according to privacy-by-default principles.

Deletion and Retention

Personal data is deleted after contract termination or upon customer instruction unless statutory retention obligations apply. Audit and access logs are retained for 90 days. Full logs are retained for 14 days. Temporary debugging or error artifacts are access-restricted, retained only for as long as operationally necessary, and deleted once the relevant purpose no longer applies. Deletion procedures, retention handling, and corresponding evidence are documented and can be demonstrated upon request.