Odoo DSGVO-konform betreiben: Datenhoheit & EU-Standort

Datenhoheit bei Odoo - Definition und warum sie mehr ist als DSGVO

Datenhoheit heißt: Du hast die tatsächliche Kontrolle darüber, wo deine Odoo-Daten liegen, wer auf sie zugreifen kann und ob du sie jederzeit exportieren und verlagern kannst. Das ist mehr als DSGVO-Konformität - und der Unterschied ist wichtig, weil beide oft in einen Topf geworfen werden.

DSGVO-Konformität ist der rechtliche Rahmen: Verträge, Maßnahmen und Prozesse, die die Verordnung (EU) 2016/679 - in Österreich ergänzt durch das DSG - von dir verlangt. Datenhoheit ist die faktische Ebene darunter: Selbst mit perfekten Verträgen hast du wenig Kontrolle, wenn deine Daten auf einem Server außerhalb der EU liegen, an einen einzigen Anbieter gebunden sind und du sie im Ernstfall nicht sauber herausbekommst. Umgekehrt gilt: Volle Kontrolle über Speicherort und Export ist die Basis, auf der Konformität überhaupt erst tragfähig wird.

Dieser Artikel nimmt die Datenhoheits-Perspektive: Serverstandort, digitale Souveränität, Lock-in-Freiheit - die strategischen Weichen. Die operative DSGVO-Ebene mit Rollen, Vertragsinhalten und Betroffenenrechten im Detail behandelt der Cluster-Artikel dazu, was Betreiber bei Odoo & DSGVO konkret beachten müssen. Beides zusammen ergibt das Bild.

Keine Rechtsberatung. Dieser Artikel ordnet Datenhoheit und die zugehörigen DSGVO-Grundlagen praktisch ein. Rechtlich verbindlich beurteilt deinen Fall nur dein Datenschutzbeauftragter oder ein Anwalt - im Zweifel zieh ihn früh dazu. Rechtsgrundlage ist die DSGVO (Verordnung (EU) 2016/679), in Österreich ergänzt durch das DSG.

Zwei Ebenen: rechtliche Konformität und tatsächliche Kontrolle

Kern-Aussage: Wenn du Datenhoheit sauber angehen willst, trenn zwei Ebenen, die zusammengehören, aber nicht dasselbe sind. Die eine fragt “Ist es erlaubt?”, die andere “Habe ich es im Griff?”.

Ebene	Kern-Frage	Wer sichert das
Rechtliche Konformität	Ist die Verarbeitung DSGVO-konform vertraglich und organisatorisch abgesichert?	Betreiber (Prozesse, Verzeichnis) + Hoster (AVV, TOMs)
Tatsächliche Kontrolle	Wo liegen die Daten, wer kann zugreifen, komme ich jederzeit wieder raus?	Hoster (Standort, Infrastruktur) + Betreiber (Edition, Export)

Die beiden Ebenen greifen ineinander. Ein US-Cloud-Anbieter kann dir einen formal sauberen Auftragsverarbeitungsvertrag geben und trotzdem ein Datenhoheits-Problem bleiben, weil der Speicherort und der mögliche behördliche Zugriff im Drittland die tatsächliche Kontrolle untergraben. Und umgekehrt nützt dir ein EU-Server wenig, wenn die vertragliche Basis fehlt. Datenhoheit entsteht nur, wenn beide Ebenen stimmen - deshalb behandelt dieser Guide sie zusammen, aber getrennt benannt.

Ein Beispiel macht das greifbar. Angenommen, deine Odoo-Instanz läuft technisch einwandfrei, du hast einen AVV unterschrieben und die Zugriffsrechte in Odoo sind sauber gepflegt - rechtlich sieht das erst mal gut aus. Liegt der Server aber in einem US-Rechenzentrum und werden die Backups nach Übersee repliziert, dann hast du auf der Kontroll-Ebene ein Loch: Im Ernstfall entscheidet nicht allein europäisches Recht darüber, wer auf diese Daten zugreifen darf. Der umgekehrte Fall ist genauso lückenhaft - ein Server in Wien ohne AVV und ohne Verarbeitungsverzeichnis ist zwar souverän gelagert, aber rechtlich angreifbar. Erst wenn beide Ebenen zusammenpassen, trägt das Fundament. Deshalb lohnt es sich, bei jeder Hosting-Entscheidung beide Fragen getrennt zu stellen: Ist es erlaubt - und habe ich es tatsächlich im Griff?

Wer bei Odoo verantwortlich ist - kurz und ehrlich

Kern-Aussage: Die wichtigste Weiche vorab - bei Odoo bist du der Verantwortliche, dein Hoster ist Auftragsverarbeiter. Das bestimmt, wer bei der Datenhoheit welchen Hebel hat.

Die DSGVO verteilt dafür zwei Rollen: Als Verantwortlicher (Art. 4 Nr. 7 DSGVO) entscheidest du über Zweck und Mittel der Verarbeitung - die Kunden-, Mitarbeiter- und Rechnungsdaten in deinem Odoo laufen auf deine Verantwortung. Der Hoster fasst diese Daten nur in deinem Auftrag an und ist damit Auftragsverarbeiter nach Art. 4 Nr. 8 - diese Rolle nimmt auch erpdock ein, während die Hoheit über die Daten bei dir bleibt. Diese Rollen-Aufteilung ist der Grund, warum es “DSGVO-konformes Odoo” nicht als fertigen Software-Haken gibt: Konformität und Kontrolle entstehen aus dem Zusammenspiel beider Seiten.

Für die Datenhoheit heißt das konkret: Der Hoster liefert Standort, Infrastruktur und Vertrag; du steuerst Zwecke, Prozesse und die Frage, wie eng du dich an ein Ökosystem bindest. Diese Aufteilung kannst du nicht delegieren - auch der beste Auftragsverarbeiter nimmt dir die Verantwortung nicht ab, er stellt dir nur die Mittel bereit, sie wahrzunehmen. Wer glaubt, mit der Wahl des Hosters sei das Datenschutz-Thema erledigt, verkennt genau diese Rollen-Aufteilung. Die vollständige Rollen-Analyse mit allen Pflichten steht im Cluster-Artikel was Betreiber bei Odoo & DSGVO konkret beachten müssen. Hier geht es weiter mit dem Hebel, der bei Datenhoheit am schwersten wiegt: dem Serverstandort.

Der Serverstandort als Kern der Datenhoheit

Kern-Aussage: Wo deine Odoo-Daten physisch liegen, entscheidet über den härtesten Punkt der Datenhoheit - den Drittlandtransfer. In DACH-Ausschreibungen und Audits hängt an genau dieser Frage regelmäßig der Zuschlag.

Sobald personenbezogene Daten die EU verlassen, greift Kapitel V der DSGVO (Art. 44 ff.): Der Transfer braucht eine eigene Rechtsgrundlage. Für die USA hat die EU-Kommission am 10.07.2023 einen Angemessenheitsbeschluss erlassen - das EU-US Data Privacy Framework (Durchführungsbeschluss (EU) 2023/1795). Er gilt nicht für die USA als Land, sondern nur für Organisationen, die auf der DPF-Liste des US-Handelsministeriums stehen und ihre Zertifizierung jährlich erneuern. Für jeden nicht gelisteten US-Empfänger bleibt es bei dem, was der EuGH im Schrems-II-Urteil (C-311/18, 2020) festgelegt hat, als er den Vorgänger Privacy Shield kippte: Standardvertragsklauseln plus eigene, dokumentierte Prüfung des Schutzniveaus, und zwar “in jedem Einzelfall” (Rn. 134). Das ist keine Einmal-Übung - du prüfst je Empfänger, dokumentierst und ziehst jede Re-Zertifizierung nach.

Ein ruhender Pol ist der DPF dabei nicht: Die Nichtigkeitsklage gegen den Beschluss wurde in erster Instanz abgewiesen (EuG T-553/23, 03.09.2025), das Rechtsmittel liegt beim EuGH (C-703/25 P). Im Juni 2026 hat der US-Supreme-Court zudem den Kündigungsschutz der FTC-Kommissare für verfassungswidrig erklärt (Trump v. Slaughter) - ausgerechnet die FTC-Unabhängigkeit führt der Angemessenheitsbeschluss als tragende Begründung an. Wer auf den DPF baut, prüft also nicht einmal, sondern dauerhaft - und trägt ein Bestandsrisiko, auf das er keinen Einfluss hat.

Am eigentlichen Kern ändert der DPF nichts: der US-Zugriffslage. Der CLOUD Act (18 U.S.C. § 2713) verpflichtet erfasste US-Anbieter, Daten herauszugeben, die sie “within such provider’s possession, custody, or control” haben - “regardless of whether such communication, record, or other information is located within or outside of the United States”. Der Speicherort ist für diese Pflicht also egal; ein Rechenzentrum in Europa allein hebt sie nicht auf. Umgekehrt erkennt die EU einen solchen Herausgabebeschluss nicht ohne Weiteres an: Nach Art. 48 DSGVO ist die Entscheidung einer Drittstaats-Behörde für sich genommen keine taugliche Rechtsgrundlage - sie trägt nur auf Basis einer internationalen Übereinkunft, etwa eines Rechtshilfeabkommens. Wer beiden Rechtsordnungen unterliegt, sitzt im Pflichtenkonflikt. Grenzenlos ist die US-Jurisdiktion dabei nicht - das US-Justizministerium selbst hält im CLOUD-Act-White-Paper (April 2019) fest: “But neither is U.S. jurisdiction unlimited.” Ein Anbieter ohne Anknüpfung an die USA ist gar nicht erst Adressat.

Der robusteste Umgang damit ist, den Transfer gar nicht erst entstehen zu lassen: Bleibt die gesamte Verarbeitung in der EU beziehungsweise in Österreich, stellt sich die Drittland-Frage nicht. erpdock hostet deshalb sämtliche Kundendaten in Wiener Rechenzentren, inklusive des eigenen S3-Speichers - ein Drittlandtransfer findet nicht statt, und auch die übrige Infrastruktur bleibt in der EU. Das ist keine juristische Feinheit, sondern der Unterschied zwischen “wir müssen den Transfer prüfen und dokumentieren und tragen ein Restrisiko” und “es gibt keinen Drittlandtransfer”.

Läuft deine Instanz derzeit außerhalb der EU, führt der Weg aus der Schrems-II-Frage über den Umzug auf einen EU-Serverstandort. Der Serverstandort ist auch deshalb der Kern der Datenhoheit, weil du ihn nicht nachträglich per Vertrag reparieren kannst - er ist eine physische Tatsache. Ein perfekter AVV ändert nichts daran, in welchem Land der Server steht.

In der Praxis wird der Standort meist an einer konkreten Stelle zum Thema: im Einkauf oder im Audit. Größere Kunden, öffentliche Auftraggeber und regulierte Branchen fragen den Serverstandort inzwischen standardmäßig ab, oft mit dem expliziten Ausschluss von Drittland-Verarbeitung. Wer dann einen US-Anbieter im Stack hat, muss erklären, prüfen und dokumentieren - und steht im Zweifel schlechter da als ein Mitbewerber mit sauberem EU-Standort. Datenhoheit ist damit nicht nur eine Compliance-Frage, sondern ein Verkaufsargument gegenüber deinen eigenen Kunden: Du kannst zusichern, dass ihre Daten die EU nicht verlassen. Genau das ist in DACH zunehmend ein Kriterium, an dem Aufträge hängen.

Digitale Souveränität - warum EU-Infrastruktur zählt

Kern-Aussage: Datenhoheit bei einer einzelnen Instanz ist der Anfang; digitale Souveränität ist der größere Rahmen - die Unabhängigkeit von der Rechts- und Zugriffslage fremder Staaten und von einzelnen Anbietern. Für ein ERP, das den Kern deines Unternehmens abbildet, ist das keine ideologische, sondern eine praktische Frage.

Der praktische Kern lässt sich nüchtern benennen: Solange deine Daten in der EU liegen und die Infrastruktur - Server, Speicher, Mail-Versand - in europäischer Hand ist, unterliegen sie dem europäischen Rechtsrahmen und nicht dem eines Drittstaats. Bei einem US-Anbieter oder einer US-Muttergesellschaft kommt eine zweite Rechtsordnung ins Spiel, die im Zweifel Zugriff verlangen kann - genau das ist der Punkt, den Schrems II sichtbar gemacht hat. Digitale Souveränität heißt, diese zweite Rechtsordnung erst gar nicht in die eigene Datenverarbeitung zu holen.

Das ist bewusst keine Marketing-Erzählung, sondern eine Abwägung mit realen Konsequenzen: Wie viel Kontrolle willst du über das System behalten, in dem deine Buchhaltung, deine Kundendaten und dein HR liegen? EU-Infrastruktur ist die Antwort für Unternehmen, die diese Kontrolle nicht aus der Hand geben wollen. Bei erpdock heißt das konkret: Rechenzentren in Wien, europäischer Speicher, jede Odoo-Instanz sauber von den anderen getrennt, und ein Mail-Versand mit SPF/DKIM/DMARC über ein EU-Versandsystem - die technische Basis liegt vollständig in Europa.

Ein Punkt, der bei der Souveränität gern übersehen wird: Es reicht nicht, dass der Odoo-Server in der EU steht, wenn Nebendienste anderswo laufen. Backups, die in ein Drittland repliziert werden, ein Mail-Versand über einen US-Dienstleister, ein Monitoring-Tool, das Daten außerhalb der EU verarbeitet - jeder dieser Nebenwege kann die Souveränität aushebeln, die der Hauptserver verspricht. Digitale Souveränität ist deshalb eine Eigenschaft der gesamten Kette, nicht nur des einen Servers, auf dem Odoo läuft. Beim Prüfen eines Hosters lohnt es sich, genau diese Nebendienste zu hinterfragen - dazu gleich eine konkrete Fragenliste.

Lock-in als Datenhoheits-Risiko - Editionen und Exportierbarkeit

Kern-Aussage: Der zweite große Hebel neben dem Standort ist die Bindung an einen Anbieter. Datenhoheit heißt auch: jederzeit wieder herauskommen zu können. Wenn dein Ausstieg teuer, riskant oder technisch verbaut ist, hast du deine Kontrolle faktisch abgegeben - egal, was im Vertrag steht.

Bei Odoo hat das eine handfeste Dimension: die Edition. Die Community Edition als Datenhoheits-Argument kommt ohne Cloud-Bindung an Odoo SA aus: Betrieb und Datenfluss liegen komplett bei dir, ein Hoster-Wechsel steht jederzeit offen, kein proprietäres Cloud-Modell hängt dazwischen. Die Enterprise Edition bringt zusätzliche Module und offiziellen Support, hängt dafür aber an einer Subscription - was Portabilität und Kontrolle in Teilen an das Odoo-Ökosystem bindet. Der DSGVO unterliegen beide Editionen gleichermaßen; mehr Datenhoheit in der eigenen Hand hast du mit Community.

Exportierbarkeit ist der Praxistest für Lock-in. Frag bei jedem Setup: Kommst du an eine vollständige Kopie deiner Datenbank und deines Filestores? Kannst du sie auf einem anderen Hoster einspielen? Genau diese Beweglichkeit ist der Grund, warum ein Hoster-Wechsel überhaupt möglich ist - und warum ein sauberer, getesteter Ausstiegsweg ein Teil von Datenhoheit ist, nicht ein Nebenaspekt. Wenn ein Standortwechsel ansteht, fällt er praktisch mit einem Umzug zusammen: Der Umzug auf einen EU-Serverstandort ist der Moment, in dem sich Datenhoheit und Migration treffen.

Lock-in hat neben der Edition noch eine technische Seite, die man beim Einstieg selten bedenkt. Proprietäre Erweiterungen, die es nur bei einem einzigen Anbieter gibt, Datenformate, die sich nicht sauber exportieren lassen, oder ein Betriebsmodell, das den Zugriff auf die eigene Datenbank verwehrt - all das erhöht die Ausstiegskosten, ohne dass es im Vertrag als “Bindung” auftaucht. Datenhoheit im vollen Sinn heißt deshalb auch: auf einem offenen Fundament zu stehen. Odoo Community ist quelloffen, deine Datenbank ist eine Standard-PostgreSQL-Datenbank, dein Filestore sind Dateien - nichts davon ist an ein Geheimformat gebunden. Diese Offenheit ist der beste Schutz gegen Lock-in, weil sie den Wechsel technisch überhaupt erst zu einer realistischen Option macht.

Der Datenhoheits-Test: fünf Fragen an jeden Odoo-Hoster

Kern-Aussage: Ob ein Hoster dir echte Datenhoheit gibt, klärst du nicht am Marketing-Text, sondern an fünf konkreten Fragen. Wer sie nicht klar und schriftlich beantwortet, gibt dir die Kontrolle nicht - egal, wie das Angebot klingt.

Wo liegen die Daten - inklusive Backups? Nicht nur der Hauptserver, sondern auch Backup-Speicher und Replikate müssen in der EU bleiben. Eine EU-Adresse auf der Website reicht als Antwort nicht.
Wer sind die Subprozessoren, und wo sitzen sie? Speicher, Mail-Versand, Monitoring - jeder Nebendienst zählt. Ein einzelner Subprozessor im Drittland kann die Souveränität der ganzen Kette brechen.
Bekomme ich jederzeit eine vollständige, einspielbare Kopie meiner Daten? Datenbank plus Filestore, in einem Standardformat, ohne Sonderantrag. Das ist dein Ausstiegsweg - und damit der Kern deiner Kontrolle.
Liegt ein AVV nach Art. 28 unterschriftsfertig bereit? Ein Muster, das du prüfen kannst, bevor du dich bindest - nicht eine vage Zusage, dass “man sich schon einigen wird”.
Gibt es eine US-Muttergesellschaft oder US-Rechtsbindung? Selbst bei EU-Servern kann eine US-Konzernstruktur eine zweite Rechtsordnung ins Spiel bringen. Diese Frage gehört offen beantwortet.

Diese fünf Fragen decken beide Ebenen ab, die weiter oben getrennt wurden: die tatsächliche Kontrolle (Fragen 1 bis 3) und die rechtliche Basis (Fragen 4 und 5). Ein Hoster, der hier klar liefert, gibt dir Datenhoheit; einer, der ausweicht, verkauft dir eine EU-Fassade. Bei erpdock sind die Antworten dokumentiert: Wien als Standort samt Backups, Subprozessoren-Liste und AVV-Muster im Datenschutz-Center, offene Standardformate für den Export.

Die Verträge dahinter: AVV, TOMs, Subprozessoren

Kern-Aussage: Standort und Edition sind die strategischen Weichen; darunter liegt die vertragliche Basis, ohne die keine Datenhoheit rechtlich hält. Hier nur der Überblick - die Details stehen im Cluster-Artikel und im Datenschutz-Center.

AVV (Art. 28 DSGVO). Der Auftragsverarbeitungsvertrag zwischen dir und dem Hoster ist gesetzlich verpflichtend, sobald ein Dienstleister personenbezogene Daten in deinem Auftrag verarbeitet. Er regelt Weisungsbindung, Vertraulichkeit, Maßnahmen, Subprozessoren, Löschung und Audit-Recht. Bei erpdock liegt der unterschriftsfertige Auftragsverarbeitungsvertrag als Muster bereit.
TOMs (Art. 32 DSGVO). Die technisch-organisatorischen Maßnahmen sichern ein dem Risiko angemessenes Schutzniveau - Zugriffskontrolle, Verschlüsselung, Mandantentrennung, Backup und Wiederherstellung. Manche davon liefert der Hoster, andere bleiben deine Aufgabe als Betreiber.
Subprozessoren (Art. 28 Abs. 2/4). Jeder weitere Dienstleister, den der Hoster einbindet - etwa für Speicher oder Mail-Versand - muss offengelegt und vertraglich sauber eingebunden sein. Wer das konkret ist, muss der Hoster dir nennen - das ist keine Kulanz, sondern dein vertraglicher Anspruch.

Gebündelt findest du AVV-Muster, TOM-Katalog und Subprozessoren-Liste im Datenschutz-Center - das ist der Startpunkt, bevor die erste echte Instanz produktiv geht. Wie ein AVV inhaltlich aufgebaut ist, welche TOMs wer verantwortet und welche Betroffenenrechte du in Odoo umsetzen musst, steht ausführlich im Cluster-Artikel zu den Betreiber-Pflichten.

Was du als Betreiber für Datenhoheit konkret tun kannst

Kern-Aussage: Datenhoheit ist kein Zustand, den man kauft, sondern eine Reihe von Entscheidungen. Diese Schritte bringen dich in die Kontrolle - unabhängig davon, welchen Hoster du am Ende wählst:

Serverstandort festlegen. Entscheide bewusst für einen EU-/AT-Standort und lass dir bestätigen, dass auch Speicher und Backups die EU nicht verlassen. Der Standort ist der Hebel, den du nachträglich am schwersten änderst.
Edition und Lock-in prüfen. Kläre, ob deine Edition dich an ein Cloud-Modell bindet, und ob du jederzeit eine vollständige, einspielbare Kopie deiner Daten bekommst.
AVV abschließen. Ohne Auftragsverarbeitungsvertrag verarbeitest du rechtswidrig - unabhängig davon, wie gut die Technik ist. Das Muster sollte bereitliegen, nicht erst verhandelt werden.
Subprozessoren kennen. Lass dir die Liste geben und prüfe, ob alle in der EU sitzen. Ein einzelner Subprozessor im Drittland holt dir die Schrems-II-Frage zurück.
Verzeichnis und Löschkonzept führen. Dokumentiere, welche personenbezogenen Daten du in Odoo zu welchem Zweck verarbeitest, und lege fest, wann was gelöscht wird. Das ist deine Pflicht als Verantwortlicher.
Betroffenenrechte prozessual absichern. Sorge dafür, dass du Auskunft, Löschung und Datenübertragbarkeit in Odoo praktisch erfüllen kannst - über CRM, Rechnungen und Mail-Verlauf hinweg.

Die Punkte 3 bis 6 sind die operative DSGVO-Ebene - dafür liefert der Cluster-Artikel die Details und das Datenschutz-Center die fertigen Bausteine. Die Punkte 1 und 2 sind die strategischen Weichen der Datenhoheit, um die es in diesem Guide vor allem geht: Wenn du Standort und Lock-in richtig setzt, steht das Fundament, auf dem der Rest aufbaut.

FAQ

Was bedeutet Datenhoheit bei Odoo? Datenhoheit ist die tatsächliche Kontrolle darüber, wo deine Odoo-Daten liegen, wer auf sie zugreifen kann und ob du sie jederzeit exportieren und verlagern kannst. Das geht über die reine DSGVO-Konformität hinaus - Konformität ist der rechtliche Rahmen, Datenhoheit die faktische Kontrolle darunter.

Reicht ein EU-Serverstandort für DSGVO-Konformität? Nein. Ein EU-/AT-Standort löst den Drittlandtransfer und ist ein starker Baustein, aber Konformität braucht zusätzlich den AVV nach Art. 28, angemessene TOMs nach Art. 32 und deine eigenen Betreiber-Prozesse. Der Standort ist notwendig, aber nicht allein hinreichend.

Ist Odoo bei einem US-Anbieter DSGVO-problematisch? Nicht per se. Steht dein US-Anbieter auf der DPF-Liste (EU-US Data Privacy Framework, Angemessenheitsbeschluss vom 10.07.2023), ist die Übermittlung gedeckt. Steht er nicht drauf, brauchst du Standardvertragsklauseln plus eigene Prüfung im Einzelfall (Schrems II, EuGH C-311/18, 2020). Dazu kommt: Der Angemessenheitsbeschluss selbst ist beim EuGH angefochten (C-703/25 P) - fällt er, stehst du wieder bei Standardvertragsklauseln. In beiden Fällen bleibt die Zugriffsfrage: Der CLOUD Act (18 U.S.C. § 2713) verpflichtet erfasste US-Anbieter zur Herausgabe, unabhängig davon, wo die Daten liegen - eine zweite Rechtsordnung ist also im Spiel. Ein europäischer Anbieter mit EU-/AT-Standort macht diese ganze Prüfkette überflüssig.

Gibt mir Community Edition mehr Datenhoheit als Enterprise? Beide Editionen unterliegen der DSGVO gleichermaßen. Die Community Edition läuft aber ohne Cloud-Bindung an Odoo SA und gibt dir dadurch mehr Kontrolle und weniger Lock-in - im Sinne der Datenhoheit ein Vorteil.

Wer ist für die Datenhoheit verantwortlich - ich oder der Hoster? Du bleibst der Verantwortliche und Herr der Daten (Art. 4 Nr. 7 DSGVO). Der Hoster ist Auftragsverarbeiter (Art. 4 Nr. 8) und liefert Standort, Vertrag und technische Basis. Kontrolle und Konformität entstehen aus dem Zusammenspiel beider - abgeben kannst du die Verantwortung nicht.