Datenresidenz und DSGVO für Agenturen: wie BYOC hilft

Ein BYOC-Modell (Bring Your Own Cloud) hilft der DSGVO-Konformität, indem es deine Kunden-CRM-Daten in eine Datenbank auf deinem eigenen Cloud-Konto verlegt, in einer von dir gewählten Region, statt in eine geteilte Datenbank, die der Softwareanbieter kontrolliert. Das verwandelt “wo liegen die Daten dieses Kunden, und wer sonst kann sie erreichen” von einer Richtlinienaussage, der du vertrauen musst, in eine Ressource, auf die du in deinem eigenen Cloudflare-Dashboard zeigen kannst. Es lässt deine AVV-Pflichten nicht verschwinden — du bist weiterhin der Verantwortliche, und du solltest deine eigene Auftragsverarbeiter-Dokumentation weiterhin mit einem Anwalt bestätigen — aber es verkürzt wirklich die Verwahrungskette für die Daten, die am meisten zählen.

In diesem Beitrag geht es um den Mechanismus, nicht um eine Compliance-Garantie. Wenn du eine Agentur führst, die EU-Kundendaten verarbeitet, hier ist, was sich tatsächlich ändert.

Warum Agenturen die DSGVO-Auftragsverarbeiter-Frage stärker spüren als die meisten Unternehmen

Wenn du eine Agentur führst, sind die personenbezogenen Daten deines Kunden — Kontaktdaten, Deal-Notizen, Kalendereinträge, manchmal Abrechnungsinformationen — nicht nebensächlich für dein Geschäft. Sie sind das Geschäft. Und sie durchlaufen üblicherweise mehrere Schichten, bevor sie “deine” sind:

• Die Datenbank deines CRM-Anbieters.
• Die eigenen Auftragsverarbeiter dieses Anbieters (Hosting, E-Mail-Zustellung, KI-Features).
• Dein Projektmanagement-Werkzeug, oft ein separater Anbieter mit eigener Liste.
• Dein Rechnungswerkzeug, oft ein dritter.

Jeder davon ist ein Auftragsverarbeiter, den du dokumentieren musst, und jeder von ihnen kann dich bitten, deine Verzeichnis-nach-Artikel-30-Einträge oder die Artikel-28-Offenlegungen deiner Kunden zu aktualisieren, wenn sich seine Infrastruktur ändert. Werkzeuge zu konsolidieren hilft (weniger Anbieter im Blick), aber es beantwortet nicht die schwierigere Frage, die Kunden und Prüfer zunehmend direkt stellen: wo, physisch und rechtlich, liegt genau dieser Datensatz, und wer außer dir kann ihn lesen?

Für herkömmliches Multi-Tenant-SaaS lautet die ehrliche Antwort “in unserer geteilten Datenbank, neben den Daten aller anderen Kunden, in welcher Region auch immer wir gewählt haben.” Das ist für sich genommen kein Verstoß gegen irgendetwas — viele konforme SaaS-Produkte funktionieren genau so, mit ordentlichen AVVs und Auftragsverarbeiter-Listen. Aber es bedeutet, dass Residenz eine Richtlinienentscheidung des Anbieters ist, und du dieser Richtlinie vertraust, statt auf eine Ressource zu zeigen, die du kontrollierst.

Was “Auftragsverarbeiter-Kette” in der Praxis bedeutet

Ein Auftragsverarbeiter ist unter der DSGVO jeder Dritte, den dein Anbieter nutzt, um in deinem Auftrag personenbezogene Daten zu verarbeiten — sein Cloud-Host, sein E-Mail-Anbieter, sein KI-Anbieter, wenn er Daten durch einen leitet. Artikel 28 verlangt von dir (dem Verantwortlichen), zu wissen, wer sie sind, und verlangt von deinem Anbieter (dem Verarbeiter), dieselben Pflichten an jeden von ihnen weiterzugeben.

Die Kette wird länger, nicht kürzer, je “all-in-one-er” Software im herkömmlichen Sinn wird: Ein zentraler Anbieter berührt jetzt dein CRM, deine Projekte und deine Abrechnung auf einmal, und jede nachgelagerte Infrastruktur-Entscheidung, die er trifft (eine neue Hosting-Region, ein neuer KI-Anbieter), ist eine Auftragsverarbeiter-Änderung, die du in seinem Auftrag nachverfolgen musst. Konsolidierung ohne Eigentum zentralisiert nur das Risiko bei einem Anbieter statt bei dreien.

Wie ändert das BYOC-Modell von sSystm das?

sSystm ist um einen anderen Standard für die CRM-Schicht herum gebaut: es gibt keine zentrale Datenbank, die dem Anbieter für deine Kontakte, Firmen, Deals, Aufgaben und Kalender gehört. Wenn deine Organisation ihr eigenes Cloudflare-Konto verbindet, wird dort eine dedizierte D1-Datenbank bereitgestellt, und eine BYOC-fähige Datenschicht in den API-Routen liest und schreibt für diese Org in diese Datenbank statt in die geteilte von sSystm.

Konkret ist das in der API eine Routing-Entscheidung pro Anfrage: Hat deine Organisation eine funktionierende Cloudflare-Verbindung, löst der CRM-Scope deinen Cloudflare-API-Token auf (verschlüsselt gespeichert, nur pro Anfrage entschlüsselt) und spricht mit deiner eigenen D1-Instanz; falls nicht, fällt er auf die zentrale Datenbank zurück, so wie die Daten jedes Nicht-BYOC-Kunden behandelt würden. Entscheidend ist, dass das fail-closed, nicht fail-open ist: Ist deine Organisation verbunden, aber der gespeicherte Token kann dein Konto nicht mehr erreichen (widerrufen, abgelaufen, fehlkonfiguriert), schlägt die Anfrage fehl und bittet dich, dich neu zu verbinden — sie schreibt deine CRM-Daten nicht still als Ausweichlösung in die geteilte zentrale Datenbank. Eine kaputte Verbindung degradiert zu “du musst die Verbindung reparieren”, nicht zu “deine Residenzgarantie bricht leise”.

Diese eine Design-Entscheidung bedeutet, dass das Auftragsverarbeiter-Bild für deine CRM-Datensätze anders aussieht: Statt “sSystm, plus die Infrastruktur-Anbieter von sSystm” sitzt die Datenbank selbst auf Infrastruktur, zu der du bereits eine direkte Beziehung hast (Cloudflare, auf deinem eigenen Konto), in der Region, die du beim Verbinden gewählt hast.

Welche Daten wandern unter BYOC tatsächlich, und was bleibt zentral — sei da genau

Es lohnt sich, hier exakt zu sein, denn “BYOC” kann anderswo locker vermarktet werden, und wir möchten lieber, dass du genau weißt, was der heutige Split abdeckt, bevor du dich für ein Compliance-Gespräch darauf verlässt:

Daten	Wo sie heute liegen
CRM-Kontakte, Firmen, Deals	Dein eigenes Cloudflare-D1, wenn verbunden, sonst zentral
Aufgaben, Kalendereinträge	Dein eigenes Cloudflare-D1, wenn verbunden, sonst zentral
Projekte, Dokumente	Zentrale Plattform-Datenbank von sSystm
Rechnungen, Angebote, Abrechnungspositionen	Zentrale Plattform-Datenbank von sSystm
Design-Systeme, Brand Assets, Routinen	Zentrale Plattform-Datenbank von sSystm
Org-Metadaten, Berechtigungen, KI-Credit-Kassenbuch	Zentrale Plattform-Datenbank von sSystm (immer)
Workers/Code, den du im Build-Modul baust	Auf dein eigenes Cloudflare-Konto deployt

Die CRM-Schicht ist der Ort, an dem sich der Großteil der personenbezogenen Kundendaten konzentriert — die Namen, E-Mails und Deal-Notizen, um die es der DSGVO im Kern geht — und das ist die Schicht, die BYOC heute abdeckt. Projekttitel, Dokumentinhalte und Rechnungspositionen liegen derzeit zentral, neben echten Plattform-Metadaten (Tarif deiner Org, Berechtigungen, Verbrauchs-Kassenbuch). Wenn deine Compliance-Prüfung den ganzen Workspace auf deiner eigenen Infrastruktur braucht, frag nach dem aktuellen Stand dieses Splits, bevor du dich darauf verlässt — Architektur entwickelt sich, und das ist genau die Art von Aussage, die es sich lohnt neu zu prüfen, statt sie aus einem Blogbeitrag zu übernehmen.

Heißt das, sSystm ist überhaupt kein Auftragsverarbeiter?

Nein, und das behaupten wir nicht. sSystm betreibt weiterhin die Software, die in deine Datenbank liest und schreibt, führt weiterhin den zentralen Metadatenspeicher der Plattform und gilt für die Daten, die es berührt, weiterhin als Verarbeiter unter der DSGVO. Was BYOC ändert, ist die Verwahrung speziell deiner CRM-Datensätze — sie sitzen in einer Datenbank, die du bereitgestellt hast, unter deinem Konto, nicht in einer Datenbank, die sSystm für alle Kunden auf einmal betreibt. Das ist eine echte Reduktion des Schadensradius und der Zahl der Parteien mit technischem Zugriff auf diese Daten, aber es ist kein Ersatz für deinen eigenen AVV, dein eigenes Verzeichnis nach Artikel 30 oder deine eigene rechtliche Prüfung, was “Verarbeiter” für deine spezifische regulatorische Exponierung bedeutet. Wenn DSGVO-Konformität für deine Agentur ein akutes Thema ist, sprich mit einem Anwalt darüber, welche Dokumentation du brauchst, unabhängig davon, welchen Anbieter du wählst.

Wie beweist du, wo deine Daten liegen — einem Kunden oder einem Prüfer?

Zwei konkrete Dinge, über eine Richtlinienaussage hinaus:

1. Die Datenbank ist eine Ressource in deinem eigenen Cloudflare-Dashboard, keine Abstraktion. Du kannst einem Kunden oder Prüfer das tatsächliche Konto und die Region zeigen, in der sie liegt, genauso wie du ihnen jedes andere Stück deiner eigenen Infrastruktur zeigen würdest.
2. Ein On-Demand-Export. sSystm stellt einen nur dem Eigentümer zugänglichen Datenexport-Endpunkt bereit, der einen vollständigen JSON-Snapshot deines Workspace erzeugt — CRM-Datensätze, Projekte, Dokumente, Abrechnungshistorie — in einer Anfrage. Das ist nützlich sowohl als eigenes Backup als auch als Nachweis, den du einem Kunden reichen kannst, der fragt “kannst du mir zeigen, was ihr über uns habt.”

Keines davon ist eine Zertifizierung. Es ist die Art von konkretem Artefakt, das ein Residenzgespräch von “wir vertrauen der Richtlinie des Anbieters” zu “hier ist die Ressource, hier ist der Export” bringt — was Kunden und Prüfer im Allgemeinen tatsächlich sehen wollen.

Eine Checkliste zur Bewertung von Agentursoftware bei der Datenresidenz

Bevor du einem Kunden sagst (oder in einen AVV schreibst), wo seine Daten liegen, bestätige das Folgende über jedes Werkzeug, das du nutzt — sSystm eingeschlossen:

• Ist die Datenbank meiner Organisation gewidmet oder mit jedem Tenant geteilt? Dediziert-aber-anbietereigen ist Isolation; das ist nicht dasselbe wie Daten auf deinem eigenen Konto.
• Auf wessen Cloud-Konto sitzt sie — dem des Anbieters oder meinem?
• Kann ich die Region wählen, und ist das eine echte Provisioning-Entscheidung oder eine Marketing-Behauptung?
• Was passiert, wenn die Verbindung zu meinem Konto abbricht — ist der Anbieter fail-closed oder fällt er still auf einen geteilten Speicher zurück?
• Welche konkreten Datenkategorien sind abgedeckt — alle oder eine Teilmenge? (Hol dir die ehrliche Antwort, nicht die Marketing-Antwort.)
• Brauche ich weiterhin meinen eigenen AVV und meine Auftragsverarbeiter-Dokumentation? Ja, immer — keine Architektur beseitigt diese Pflicht, sie ändert nur, was hineingehört.

Wo dich das lässt

BYOC macht DSGVO-Konformität nicht zum Problem eines anderen — das kann es nie, denn du bleibst der Verantwortliche für die Daten deiner Kunden, egal wo die Bytes sitzen. Was es leistet, ist, die Kette für die Datenschicht zu verkürzen, die am meisten zählt (Kunden-CRM-Datensätze), dir eine konkrete Ressource zu geben, auf die du zeigen kannst, statt einer Richtlinie, der du vertraust, und fail-closed zu sein, statt still deine Residenzgarantie zu brechen, wenn eine Verbindung abfällt. Lies mehr über die zugrunde liegende Architektur in was ein BYOC-Agentur-OS ist und dem Sicherheits- und Datenmodell, sieh, wie die Verbindung selbst funktioniert, in wie sSystm funktioniert, und prüfe den Modulkatalog dafür, was heute auf deinem eigenen Konto läuft.