Trust & Compliance
Stand: 2. Juli 2026
Gerade bei Steuer- und Buchhaltungsprozessen sind Vertrauen und Nachvollziehbarkeit entscheidend. Diese Seite fasst zusammen, wie wir Hosting, Datenverarbeitung und vertragliche Absicherung aktuell umsetzen.
Überblick
Die folgenden Punkte fassen den Hosting-, Rechts-, Vertrags- und Audit-Rahmen zusammen, der serviceübergreifend gilt.
Datenstandort & Hosting
Die persistente Datenspeicherung erfolgt in Deutschland. Je nach vereinbartem Setup kann die Verarbeitung, einschließlich LLM-gestützter Workloads, innerhalb der EU erfolgen, insbesondere in Deutschland, Schweden oder Frankreich.
Regulatorische Einordnung
Für Berufsgeheimniskontexte sind unsere Leistungen darauf ausgelegt, die Vertraulichkeitsanforderungen nach § 203 StGB zu unterstützen. Relevante Mitarbeitende werden schriftlich auf Vertraulichkeit und dokumentierte Weisungen verpflichtet; für die Verarbeitung personenbezogener Daten erfolgt die vertragliche Absicherung über einen AVV, soweit einschlägig.
Vertragliche Datenschutzabsicherung
Wir schließen mit Kunden einen AVV, der Rollen, Pflichten und Schutzmaßnahmen für die Verarbeitung personenbezogener Daten regelt.
Datenverarbeitung in der API
Für unsere API-Leistungen werden Kunden-Payload-Inhalte innerhalb der Systeme von Klardaten grundsätzlich nicht als persistente Anwendungsdaten vorgehalten. Technisch notwendige Verarbeitung, kurzzeitige Zwischenspeicherung in Queues sowie vorübergehende Debugging- oder Fehlerartefakte können betriebsbedingt vorkommen. Solche Artefakte sind zugriffsbeschränkt und werden nach Zweckfortfall gelöscht.
Externes Sicherheitsaudit
Das letzte externe Sicherheitsaudit wurde im März 2026 durchgeführt und umfasste Infrastruktur, Backend-Code und Connector-Code.
Nachweise & Kontakt
Die folgenden Unterlagen und Nachweise stehen für Einkauf, Legal und IT-Security zur Verfügung.
- Ein AVV ist für Kundenbeziehungen mit Verarbeitung personenbezogener Daten auf Anfrage verfügbar.
- Diese Seite enthält die aktuelle Übersicht der Unterauftragnehmer.
- Diese Seite enthält eine TOM-Kurzfassung.
Für Fragen aus Einkauf, Legal oder IT-Security erreicht ihr uns unter info@klardaten.com.
Produktübersicht nach Service
Diese Übersicht beschreibt die wesentlichen servicebezogenen Verarbeitungsmerkmale im Rahmen der Auftragsverarbeitung.
Klarvos
- Rolle
- Klardaten agiert als Auftragsverarbeiter für Kundeninhalte und personenbezogene Daten, die im Auftrag des Kunden verarbeitet werden.
- Gespeichert
- In gemanagten Betriebsmodellen speichert Klarvos Arbeitsinhalte und workflowbezogene Anwendungsdaten in Deutschland. In selbst betriebenen oder partnergeführten Bereitstellungen hängt die Speicherung vom vereinbarten Betriebsmodell ab.
- Temporär verarbeitet
- Eingaben, Workflow-Schritte, Antworten aus angebundenen Systemen und optionale Modelleingaben werden für die Workflow-Ausführung verarbeitet. Kurzzeitige technische Zwischenverarbeitung in Queues und Error-Handling-Pfaden kann betriebsbedingt vorkommen.
- In Protokollen
- Routine-Protokolle enthalten primär Betriebsmetadaten und technische Fehlerinformationen. Workflow- und Modellereignisse können für Support, Fehleranalyse und Nachvollziehbarkeit protokolliert werden.
- Nicht in Protokollen
- Es ist nicht vorgesehen, Kundeninhalte in Routine-Betriebsprotokollen zu speichern.
Unterauftragnehmer
Amazon Web Services
Zweck: Primäre Hosting- und Service-Infrastruktur
Standort: Region Frankfurt, Deutschland
Hetzner
Zweck: Interne Entwicklungs- sowie Fallback-/Backup-Infrastruktur
Standort: Nürnberg, Deutschland
Microsoft Azure
Zweck: KI-Modell-Infrastruktur für Klarvos
Standort: Standardmäßig Region Frankfurt, Deutschland; auf Wunsch Schweden; Backup in Frankreich
Enterprise API
- Rolle
- Klardaten agiert als Auftragsverarbeiter für personenbezogene Daten, die über den Service im Auftrag des Kunden verarbeitet werden.
- Gespeichert
- Kunden-Payload-Inhalte werden innerhalb der Systeme von Klardaten grundsätzlich nicht als persistente Anwendungsdaten vorgehalten. Technisch notwendige Verarbeitung sowie kurzzeitige Zwischenspeicherung in Queues oder Debugging-Artefakten können betriebsbedingt vorkommen.
- Temporär verarbeitet
- API-Anfragen werden für die Anfrageverarbeitung verarbeitet, einschließlich Zugriff auf konfigurierte DATEV-nahe Systeme oder Datenquellen. Kurzzeitige technische Zwischenverarbeitung in Queues und Error-Handling-Pfaden kann betriebsbedingt vorkommen.
- In Protokollen
- Routine-Protokolle enthalten primär Betriebsmetadaten und technische Fehlerinformationen, die für Betrieb und Fehleranalyse erforderlich sind, und werden 14 Tage aufbewahrt. Temporäre Debugging- oder Fehlerartefakte können betriebsbedingt begrenzten Anfragekontext enthalten; der Zugriff ist eingeschränkt und die Löschung erfolgt nach Zweckfortfall.
- Nicht in Protokollen
- Es ist nicht vorgesehen, Kunden-Payload-Inhalte in Routine-Protokollen zu speichern.
Unterauftragnehmer
Amazon Web Services
Zweck: Primäre Hosting- und Service-Infrastruktur
Standort: Region Frankfurt, Deutschland
Hetzner
Zweck: Interne Entwicklungs- sowie Fallback-/Backup-Infrastruktur
Standort: Nürnberg, Deutschland
DATEVconnect Gateway
- Rolle
- Klardaten agiert als Auftragsverarbeiter für personenbezogene Daten, die über den Service im Auftrag des Kunden verarbeitet werden.
- Gespeichert
- Kunden-Payload-Inhalte werden innerhalb der Systeme von Klardaten grundsätzlich nicht als persistente Anwendungsdaten vorgehalten. Technisch notwendige Verarbeitung sowie kurzzeitige Zwischenspeicherung in Queues oder Debugging-Artefakten können betriebsbedingt vorkommen. DATEV- und Windows-Zugangsdaten werden ausschließlich lokal und verschlüsselt auf den Windows-Systemen des Kunden gespeichert, nicht bei Klardaten.
- Temporär verarbeitet
- Anfragen werden für den Integrationsfluss zwischen angebundenen Systemen und DATEVconnect verarbeitet. Kurzzeitige technische Zwischenverarbeitung in Queues und Error-Handling-Pfaden kann betriebsbedingt vorkommen.
- In Protokollen
- Routine-Zugriffsprotokolle enthalten primär Betriebsmetadaten und technische Fehlerinformationen und werden 90 Tage aufbewahrt. Temporäre Debugging- oder Fehlerartefakte können betriebsbedingt begrenzten Anfragekontext enthalten; der Zugriff ist eingeschränkt und die Löschung erfolgt nach Zweckfortfall. Wir können vorgehaltene Zugriffsprotokolle unseren Kunden auf Anfrage zur Verfügung stellen.
- Nicht in Protokollen
- Es ist nicht vorgesehen, Kundeninhalte oder Payload-Daten in Routine-Zugriffsprotokollen zu speichern.
Unterauftragnehmer
Amazon Web Services
Zweck: Primäre Hosting- und Service-Infrastruktur
Standort: Region Frankfurt, Deutschland
Hetzner
Zweck: Interne Entwicklungs- sowie Fallback-/Backup-Infrastruktur
Standort: Nürnberg, Deutschland
DATEVconnect MCP Server
- Rolle
- Klardaten agiert als Auftragsverarbeiter für personenbezogene Daten, die über den Service im Auftrag des Kunden verarbeitet werden. Der verbundene MCP-/LLM-Client erhält Tool-Eingaben und Tool-Ergebnisse als vom Nutzer gewählter Empfänger.
- Gespeichert
- DATEV-Payload-Inhalte werden innerhalb der Systeme von Klardaten grundsätzlich nicht als persistente Anwendungsdaten vorgehalten. OAuth- und Sitzungsmetadaten zur Verbindung sowie Betriebs-, Sicherheits- und Diagnoseprotokolle werden nur vorgehalten, soweit dies für Betrieb, Support, Sicherheit und Nachvollziehbarkeit erforderlich ist. Temporäre DMS-Downloadlinks sind einmalig verwendbar und kurzlebig.
- Temporär verarbeitet
- Tool-Aufrufe werden ausschließlich lesend verarbeitet, um berechtigte DATEV-Datensätze, DMS-Metadaten oder DMS-Dateien über die Klardaten-API- und DATEVconnect-Gateway-Schicht abzurufen. Der ausgewählte MCP-/LLM-Client erhält die Tool-Eingaben und Tool-Ergebnisse.
- In Protokollen
- Routine- bzw. vollständige Betriebsprotokolle werden 14 Tage aufbewahrt; Zugriffs- und Audit-Protokolle werden 90 Tage aufbewahrt. OAuth-Sitzungen laufen standardmäßig nach 30 Tagen ab, MCP-HTTP-Sitzungen nach 4 Stunden; temporäre Downloadlinks sind einmalig verwendbar und laufen standardmäßig nach 3 Minuten ab. Protokolle enthalten primär Betriebsmetadaten und technische Fehlerinformationen; temporäre Debugging- oder Fehlerartefakte können betriebsbedingt begrenzten Anfragekontext enthalten.
- Nicht in Protokollen
- Es ist nicht vorgesehen, DATEV-Payloads in Routine-Protokollen zu speichern oder Klardaten-interne Kennungen, technische Token, Sitzungsdaten oder Diagnosedaten als normale Tool-Ergebnisse auszugeben.
Unterauftragnehmer
Amazon Web Services
Zweck: Primäre Hosting- und Service-Infrastruktur
Standort: Region Frankfurt, Deutschland
Hetzner
Zweck: Interne Entwicklungs- sowie Fallback-/Backup-Infrastruktur
Standort: Nürnberg, Deutschland
Datenflüsse
Die folgenden vereinfachten Datenflüsse zeigen die typischen Entstehungs-, Verarbeitungs- und Übertragungspunkte der Daten über die relevanten Komponenten hinweg.
DATEVconnect Gateway
Kundenanwendung <-> Klardaten-API-Schicht <-> Klardaten-DATEVconnect-Gateway-Service auf Zielsystem <-> DATEVconnect
DATEV- und Windows-Zugangsdaten verbleiben auf den Windows-Systemen des Kunden. Klardaten verarbeitet Anfragen für den Integrationsfluss und kann dabei betriebsbedingt kurzzeitige technische Zwischenverarbeitung nutzen.
Enterprise API
Kundenanwendung <-> Klardaten-API-Schicht <-> Klardaten-Enterprise-Service auf Zielsystem <-> DATEV
Je nach Integration kann die Verarbeitung auch Zugriff auf konfigurierte DATEV-nahe Systeme oder Datenquellen umfassen. Kurzzeitige technische Zwischenverarbeitung in Queues oder Error-Handling-Pfaden kann betriebsbedingt vorkommen.
Klarvos
Nutzereingabe oder Workflow-Trigger -> Klarvos-Anwendung -> Klardaten-API und angebundene Systeme -> optionale LLM-Ausführung -> Antwort oder Workflow-Aktion
Die LLM-Ausführung ist optional und hängt vom konfigurierten Anwendungsfall ab. Persistente Arbeitsdaten bleiben in Deutschland; die Modellausführung kann je nach vereinbartem Setup in Deutschland, Schweden oder Frankreich erfolgen.
DATEVconnect MCP Server
Ausgewählter MCP-/LLM-Client <-> Klardaten DATEVconnect MCP Server <-> Klardaten-API- und DATEVconnect-Gateway-Schicht <-> DATEV
Der vom Nutzer ausgewählte MCP-/LLM-Client erhält Tool-Eingaben und Tool-Ergebnisse. Klardaten-interne OAuth- und Sitzungsdaten, DATEV-Instanz- und Profilkennungen, technische Token, Anfrage-IDs, Diagnosedaten und Betriebsprotokolle werden intern verarbeitet und nicht als normale Tool-Ergebnisse zurückgegeben. Der ausgewählte Client ist ein vom Nutzer gewählter Empfänger und standardmäßig kein Unterauftragnehmer von Klardaten.
Verarbeitungsumfang
Für die Auftragsverarbeitung sind die folgenden Angaben für Due-Diligence- und Vertragsprüfungen relevant.
Ort der Verarbeitung
Datenverarbeitungstätigkeiten im Rahmen der Auftragsverarbeitung werden ausschließlich innerhalb der EU bzw. des EWR durchgeführt.
Zugriff durch Klardaten
Klardaten benötigt im Regelbetrieb keinen Zugriff auf Kundeninhalte. Ein Zugriff auf Kundendaten kann nur erfolgen, soweit dies betriebsbedingt erforderlich ist, etwa in Support- oder Störungsfällen, und dann nur unter kontrollierten Bedingungen, zu einem definierten Zweck und, soweit einschlägig, auf Grundlage einer Freigabe des Kunden oder dokumentierter Weisung. Solche Zugriffe sind rollenbasiert, werden protokolliert und sind nachvollziehbar ausgestaltet.
Rolle und Rechtsgrundlage
Soweit Klardaten personenbezogene Daten im Auftrag von Kunden verarbeitet, agiert Klardaten als Auftragsverarbeiter nach Art. 28 DSGVO. Die jeweilige Rechtsgrundlage nach Art. 6 DSGVO für die konkrete Verarbeitung wird vom Kunden als Verantwortlichem bestimmt.
Datenkategorien
- Stamm- und Kontaktdaten wie Name, Anschrift, E-Mail-Adresse und Telefonnummer.
- Mandanten-, Berater- und Benutzerkennungen.
- Metadaten zu Mandaten, Berechtigungen und freigeschalteten DATEV-Modulen.
- Abrechnungs- und buchhaltungsnahe Daten wie Buchungssätze, Konten sowie Beleg- oder Rechnungsmetadaten.
- DMS-Dokumentmetadaten und Dateien, Auftragsmanagementdaten sowie Payroll- oder Mitarbeiterdaten, soweit das jeweilige DATEV-System dies zulässt.
- Technische Kommunikations- und Protokolldaten wie Zeitstempel, Anfrage-IDs und Fehlercodes.
Betroffene Personengruppen
- Mandanten des Verantwortlichen, einschließlich Unternehmen und deren Ansprechpartner.
- Mitarbeitende des Verantwortlichen oder seiner Mandanten.
- Gegebenenfalls Kunden und Lieferanten der Mandanten.
- Nutzer des DATEV-Systems, etwa Kanzlei- und Mandantenanwender.
Übersicht der Unterauftragnehmer
Diese Übersicht führt die derzeit eingesetzten Unterauftragnehmer, ihren Zweck, ihren Standort und die betroffenen Services auf.
Amazon Web Services
- Zweck:
- Primäre Hosting- und Service-Infrastruktur
- Standort:
- Region Frankfurt, Deutschland
- Betroffene Services:
- Klarvos, Enterprise API, DATEVconnect Gateway, Webseite, DATEVconnect MCP Server
Hetzner
- Zweck:
- Interne Entwicklungs- sowie Fallback-/Backup-Infrastruktur
- Standort:
- Nürnberg, Deutschland
- Betroffene Services:
- Klarvos, Enterprise API, DATEVconnect Gateway, Webseite, DATEVconnect MCP Server
Microsoft Azure
- Zweck:
- KI-Modell-Infrastruktur für Klarvos
- Standort:
- Standardmäßig Region Frankfurt, Deutschland; auf Wunsch Schweden; Backup in Frankreich
- Betroffene Services:
- Klarvos
Geplante Änderungen bei Unterauftragnehmern werden Kunden vorab schriftlich mitgeteilt. Erforderliche Vereinbarungen nach Art. 28 Abs. 4 DSGVO werden abgeschlossen, bevor ein neuer Unterauftragnehmer personenbezogene Daten verarbeitet.
Incident-Handling
Für Sicherheitsvorfälle besteht ein dokumentierter Prozess mit definierten Eskalationswegen und internen Dokumentationspflichten. Kunden werden ohne unangemessene Verzögerung informiert, wenn ein Vorfall ihre Daten oder Services betrifft, und wir unterstützen bei der Erfüllung von Meldepflichten nach Art. 33 und 34 DSGVO.
Technisch-organisatorische Maßnahmen
Diese TOM-Kurzfassung beschreibt die wesentlichen technisch-organisatorischen Kontrollbereiche für Due-Diligence-Prüfungen. Sie ersetzt keine detaillierte TOM-Anlage im Vertrag.
Vertraulichkeit
Der physische Zutritt zu Verarbeitungsanlagen wird an den jeweiligen Rechenzentrumsstandorten durch die eingesetzten Infrastrukturprovider kontrolliert. Die primäre Infrastruktur läuft auf Amazon Web Services in der Region Frankfurt; Hetzner wird als interne Entwicklungs- sowie Fallback-/Backup-Infrastruktur vorgehalten. Zugriffe auf produktive Systeme erfordern personalisierte Konten und verpflichtende MFA. Berechtigungen sind rollenbasiert, werden protokolliert und im Rahmen dokumentierter Berechtigungsprozesse überprüft. Administrativer Zugriff ist auf gesicherte VPN- und SSH-Verbindungen mit schlüsselbasierter Authentifizierung beschränkt. Daten werden bei der Übertragung mit TLS 1.2+ und im Ruhezustand mit AES-256 verschlüsselt. Das Schlüsselmanagement erfolgt über die jeweiligen Cloud-KMS-Systeme mit Zugriffsbeschränkung und Rotationskontrollen. Pseudonymisierung oder Anonymisierung erfolgt, soweit technisch sinnvoll und vertraglich vereinbart.
Integrität und Verfügbarkeit
Verschlüsselte Backups werden im Rahmen eines dokumentierten Backup-Prozesses erstellt und redundant über getrennte Verfügbarkeitszonen gespeichert. Wiederherstellungsverfahren werden regelmäßig getestet. Systeme werden anhand dokumentierter Baseline-Konfigurationen gehärtet. Sicherheitsupdates werden über einen dokumentierten Patch-Management-Prozess risikobasiert priorisiert und eingespielt. Monitoring umfasst Infrastruktur, Anwendungsfehler und Security Events. Für Sicherheitsvorfälle bestehen dokumentierte Reaktionsprozesse mit Eskalation, Dokumentation und Benachrichtigung des Kunden entsprechend den DSGVO-Anforderungen.
Endgeräteschutz und Zugriffssicherheit
Geräteverschlüsselung ist auf verwalteten Endgeräten verpflichtend. Verbindungen zu produktiven Systemen sind nur über verschlüsselte Kanäle zulässig; öffentliche oder ungesicherte Netzwerke für Produktivzugriffe sind untersagt. Externe Speichermedien sind standardmäßig deaktiviert, sofern sie nicht ausdrücklich freigegeben und verschlüsselt sind. Passwortvorgaben, automatische Bildschirmsperren und Endgeräteschutzmaßnahmen werden über interne Sicherheitsrichtlinien durchgesetzt.
Organisatorische Maßnahmen
Berechtigungen folgen strikt dem Need-to-know-Prinzip, Rollenänderungen werden dokumentiert. Mitarbeitende werden vor dem Zugriff auf relevante Systeme oder Daten schriftlich auf Vertraulichkeit und dokumentierte Weisungen verpflichtet. Interne Sicherheitsüberprüfungen und Verbesserungsmaßnahmen werden dokumentiert und nachverfolgt. Wenn Kunden Berufsgeheimnisträger sind, können zusätzlich Verpflichtungen nach § 203 StGB angewendet werden. Systeme sind nach dem Prinzip Datenschutz durch datenschutzfreundliche Voreinstellungen konfiguriert.
Löschung und Aufbewahrung
Personenbezogene Daten werden nach Vertragsende oder auf Weisung des Kunden gelöscht, sofern keine gesetzlichen Aufbewahrungspflichten entgegenstehen. Audit- und Zugriffsprotokolle werden 90 Tage aufbewahrt. Vollständige Protokolle werden 14 Tage aufbewahrt. Temporäre Debugging- oder Fehlerartefakte sind zugriffsbeschränkt, werden nur so lange vorgehalten, wie dies betriebsbedingt erforderlich ist, und nach Zweckfortfall gelöscht. Löschprozesse, Aufbewahrungsvorgaben und entsprechende Nachweise werden dokumentiert und können auf Anfrage vorgelegt werden.