SOC 2 und HIPAA für Link-Tracking: Eine Antwort für den Einkauf

Ein URL-Shortener erscheint bei einer Überprüfung durch den Einkauf oft nur als kleine Fläche. Zwei Absätze im Sicherheitsfragebogen für Anbieter, eine kurze Bestätigung, ein Häkchen. Dann öffnet das Sicherheitsteam das Architekturdiagramm und stellt fest, dass der Shortener im Request-Pfad jeder Kampagnen-URL, jeder transaktionalen E-Mail und jedes QR-Code-Redirects liegt. Die Prüfung, die eigentlich zwei Absätze lang sein sollte, führt zu drei Wochen Nachfassen.

Dieser Beitrag beantwortet die Fragen, die IT-Einkaufsteams in Unternehmen tatsächlich zu SOC 2 Type II und HIPAA stellen, wenn sie einen Anbieter für Link-Tracking bewerten. Er ist sowohl für die Person geschrieben, die den Fragebogen ausfüllt, als auch für die Person, die die Antwort prüft.

Die Kurzfassung#

Elido verfügt über eine ISO 27001-Zertifizierung. SOC 2 Type II ist in Arbeit, mit einem Zieltermin für den Abschluss in der zweiten Jahreshälfte 2026 – das Audit-Fenster begann im Februar 2026, die Beweiserhebung läuft bis Juli und der Type II-Bericht wird bis Ende Q4 erwartet. HIPAA wird in den Plänen Business und Enterprise mit einem unterzeichneten Business Associate Agreement (BAA) unterstützt; die zugrunde liegenden Kontrollen sind dieselben, die auch für SOC 2 verwendet werden.

Die GDPR-Compliance-Position ist unabhängig von SOC 2 und HIPAA und wird im Cornerstone-Beitrag GDPR für URL-Shortener behandelt. Dieser Beitrag konzentriert sich auf die Attestierungs-Frameworks nach US-Vorbild, die die Überprüfungen im Unternehmenseinkauf vorantreiben.

Was SOC 2 tatsächlich über einen URL-Shortener aussagt#

SOC 2 ist ein Bericht, keine Zertifizierung. Ein unabhängiger Prüfer (eine CPA-Firma in den US oder eine anerkannte Prüfstelle in der EU) untersucht eine Serviceorganisation anhand der AICPA Trust Services Criteria und gibt ein Urteil ab. Type I dokumentiert, dass Kontrollen zu einem bestimmten Zeitpunkt angemessen konzipiert sind; Type II dokumentiert, dass sie über einen Zeitraum – in der Regel sechs bis zwölf Monate – effektiv funktionierten.

Die Trust Services Criteria fallen in fünf Kategorien. Jeder SOC 2-Bericht deckt Security ab; die anderen vier (Availability, Processing Integrity, Confidentiality, Privacy) werden nach Wahl der Serviceorganisation einbezogen, je nachdem, was der Kundenstamm benötigt.

Security — die immer enthaltene Kategorie#

Die Security-Kriterien decken Zugangskontrolle, Change Management, Monitoring, Incident Response und Risikobewertung ab. Für einen URL-Shortener sind die wichtigsten Kontrollen:

CC6.1 Logical access: Wer kann einen Kurzlink erstellen, ändern oder löschen, und wie wird dieser Zugriff gewährt und entzogen. Das Audit wird spezifische Benutzer vom HR-Onboarding-Datensatz über den IdP (Ory Kratos für Elido) bis hin zur Rollenzuweisung im Workspace zurückverfolgen und überprüfen, ob ihr Zugriff innerhalb des Richtlinienfensters nach dem Ausscheiden entfernt wurde.
CC6.6 External access: Wie sich externe Benutzer (Besitzer von benutzerdefinierten Domains, API-Konsumenten, Partnerintegrationen) authentifizieren und welche Scopes sie erhalten. Das API-Token-Modell mit Idempotenz-Schlüsseln und Workspace-bezogenem Scoping ist das Artefakt, das der Prüfer sehen möchte.
CC7.2 Monitoring: Was protokolliert wird, wohin die Logs gehen und wie Anomalien gemeldet werden. Für einen Redirect-Service sind die relevanten Signale ungewöhnliches Redirect-Volumen pro Workspace, Rate-Limit-Trigger am Edge und Authentifizierungsfehler.
CC8.1 Change management: Code-Änderungen vom Pull Request bis zum Deployment, mit Aufgabentrennung zwischen dem Ingenieur, der die Änderung geschrieben hat, und dem Reviewer, der sie genehmigt hat. Das Audit wird Pull Requests stichprobenartig prüfen und den Genehmigungs- und Deployment-Prozess durchlaufen.

Die Security-Kriterien sind auch der Bereich, in dem SOC 2 einen dokumentierten Incident Response-Plan erwartet. Für einen Redirect-Service sind die relevanten Vorfälle die unbefugte Erstellung von Links, Manipulationen am Redirect-Ziel und Datenexfiltration über die Analytics-Export-Endpunkte. Das Runbook unter /docs/runbooks/ deckt das Playbook für jeden dieser Fälle ab.

Availability — die zweithäufigste Kategorie#

Availability deckt Uptime-Zusagen, Kapazitätsplanung und Disaster Recovery ab. Für einen URL-Shortener sind die relevanten Artefakte:

Ein dokumentiertes Service-Level Objective (SLO). Elidos veröffentlichtes SLO beträgt 99,95 % Verfügbarkeit der Redirects pro Quartal, mit separaten SLOs für das Dashboard (99,9 %) und die Analytics-API (99,5 %).
Nachweise über Kapazitätstests. Der Edge-Redirect-Service führt kontinuierliche Lasttests im Staging durch; das Audit sucht nach Beweisen, dass der Produktions-Kapazitätsrahmen bekannt ist und gegen das SLO überwacht wird.
Nachweise über Backup und Restore. Postgres läuft mit Patroni HA und Point-in-Time-Recovery; ClickHouse exportiert täglich in den Objektspeicher; das Audit verlangt das Restore-Protokoll, das zeigt, dass das Wiederherstellungszeitziel erreichbar ist.
Dokumentation zum Multi-Region-Failover. Die drei POPs (Frankfurt, Ashburn, Singapore) sind aktiv-aktiv für Redirects; der Prüfer wird das Failover-Runbook und das Post-mortem des jüngsten regionalen Ereignisses lesen.

Confidentiality und Privacy — selektiv enthalten#

Confidentiality und Privacy fügen Kategorien hinzu, die sich mit der GDPR-Position überschneiden. Die meisten Unternehmenskunden in der EU ziehen es vor, den Datenschutz über die GDPR-Dokumentation (Auftragsverarbeitungsverträge nach Artikel 28, Transfer Impact Assessments, das öffentliche DPA) zu adressieren, anstatt über SOC 2 Privacy. Elidos aktueller SOC 2-Audit-Scope umfasst Security, Availability und Confidentiality. Privacy wird separat über die GDPR-Dokumentation unter /trust behandelt.

Der Grund für die Trennung: SOC 2 Privacy orientiert sich an den AICPA Generally Accepted Privacy Principles, die für US-Datenschutz-Frameworks entwickelt wurden. GDPR ist ein eigenständiges rechtliches Framework mit eigenen Kontrollen. Die Vermischung beider in einer einzigen Attestierung neigt dazu, beide zu schwächen.

Was HIPAA tatsächlich über einen URL-Shortener aussagt#

HIPAA — der Health Insurance Portability and Accountability Act, aktualisiert durch HITECH und die Omnibus Rule von 2013 — regelt den Umgang mit Protected Health Information (PHI) durch Covered Entities (Gesundheitsdienstleister, Kostenträger, Clearingstellen) und deren Business Associates.

Ein URL-Shortener wird zum Business Associate, wenn der Kurzlink oder die dahinterstehenden Daten PHI enthalten. Die interessante Frage ist, ob das jemals der Fall ist, und die Antwort ist nuancierter, als die meisten Prüfungen im Einkauf annehmen.

Wenn PHI durch einen Redirect fließt#

Ein Kurzlink an sich — s.elido.me/abc123 — ist kein PHI. Die Ziel-URL, die Workspace-Metadaten und die Kampagnen-Tags sind im Regelfall ebenfalls kein PHI.

Die PHI-Frage stellt sich an drei spezifischen Stellen:

Ziel-URLs, die Identifikatoren enthalten: Ein Kurzlink, der auf https://provider.example/patient/12345/results weiterleitet, enthält eine Patienten-ID im URL-Pfad. Diese Ziel-URL wird vom Shortener gespeichert und ist daher PHI im strengen Sinne – auch wenn der Link perfekt funktioniert, ohne dass jemand beim Shortener die Patienten-ID interpretiert.
Benutzerdefinierte Parameter, die beim Klick angehängt werden: Wenn ein Redirect eine Sitzungs-ID oder eine Benutzer-ID als URL-Parameter anhängt und diese ID später mit PHI verknüpft werden kann, wird das Klick-Ereignis Teil der PHI-Kette.
Klick-Ereignisse mit Referrer-Daten: Ein Klick-Ereignis enthält die Referrer-URL. Falls ein Referrer zufällig eine Patienten-ID enthält (eine Deep-Link-Seite eines Patientenportals, die den Benutzer zum Kurzlink weitergeleitet hat), ist das Referrer-Feld PHI.

Die meisten Marketing-Anwendungsfälle im Gesundheitswesen erzeugen über keinen dieser Kanäle PHI. Eine Marketingabteilung eines Gesundheitssystems, die Kampagnen für Grippeschutzimpfungen, Wellness-Events oder allgemeine Gesundheitsinhalte durchführt, erstellt Redirects mit PHI-freien Zielen und PHI-freien Referrern. Für diesen Workload ist das BAA eine Vorsichtsmaßnahme, aber architektonisch nicht zwingend erforderlich.

Für Workloads, die tatsächlich über PHI-Ziele routen – Patientenportale, Terminbestätigungslinks, URLs zur Übermittlung von Laborergebnissen – ist das BAA erforderlich, und die unten beschriebenen architektonischen Kontrollen müssen beim Shortener vorhanden sein.

Die HIPAA Security Rule übertragen auf einen Redirect-Service#

Die HIPAA Security Rule (45 CFR Part 164, Subpart C) schreibt administrative, physische und technische Schutzmaßnahmen vor. Für einen Redirect-Service, der PHI in Ziel-URLs verarbeitet:

Access controls (164.312(a)): Eindeutige Benutzeridentifikation, automatisches Logoff, Verschlüsselung von ePHI bei der Übertragung und im Ruhezustand. Elido erzwingt eindeutige, vom IdP zugewiesene Benutzer-IDs, konfigurierbare Sitzungs-Timeouts pro Workspace, TLS 1.3 an allen externen Endpunkten und AES-256 Envelope-Verschlüsselung im Ruhezustand für die relevanten Datenspeicher.
Audit controls (164.312(b)): Aufzeichnung und Untersuchung von Aktivitäten in Systemen, die ePHI enthalten oder verwenden. Elido gibt Audit-Logs für die Link-Erstellung, Link-Änderung, Zieländerungen und den Analytics-Export an einen manipulationssicheren Append-Only-Speicher aus. Die Aufbewahrungsfrist für Audit-Logs beträgt in den Business+-Plänen standardmäßig 24 Monate.
Integrity controls (164.312(c)): Schutz von ePHI vor unbefugter Änderung. Ziel-URLs werden mit einer Historisierung auf Zeilenebene gespeichert; jede Änderung wird mit der Identität des Akteurs und einem Zeitstempel protokolliert, wobei der vorherige Wert in der Historientabelle erhalten bleibt.
Transmission security (164.312(e)): Schutz von ePHI bei der Übertragung über offene Netzwerke. TLS 1.3 auf allen Redirect-Endpunkten; HSTS-Preload; Certificate Pinning für benutzerdefinierte Domains verfügbar.

Die administrativen und physischen Schutzmaßnahmen (Schulung der Belegschaft, Sanktionsrichtlinien, Zugangskontrollen für Einrichtungen) überschneiden sich stark mit den SOC 2 Security-Kontrollen. Dieselben Nachweise unterstützen beide Audits, weshalb wir sie nach einem gemeinsamen Zeitplan für die Beweiserhebung durchführen.

Was das BAA abdeckt und was nicht#

Ein Business Associate Agreement ist ein Vertrag gemäß HIPAA 164.504(e). Er verpflichtet den Business Associate zu spezifischen Schutzmaßnahmen, Zeitplänen für die Benachrichtigung bei Datenschutzverletzungen und Verpflichtungen zur Weitergabe an Subunternehmer. Es ändert nichts an der zugrunde liegenden Architektur; es verpflichtet den Anbieter, die Architektur in einer HIPAA-konformen Weise zu betreiben.

Das Standard-BAA von Elido, das in den Plänen Business und Enterprise verfügbar ist, deckt Folgendes ab:

Die vier Kategorien der HIPAA Security Rule, angewendet auf alle Daten, die der Kunde über den Redirect-Service routet.
Benachrichtigung bei Datenschutzverletzungen innerhalb von 60 Tagen nach Entdeckung, mit detaillierten Zeitplänen für die Reaktion auf Vorfälle im BAA und im entsprechenden Runbook unter /docs/runbooks/incident-response.
Weitergabe an die genannten Unterauftragsverarbeiter (Hetzner, OVH, Postmark, Cloudflare, monobank Plata) unter deren eigenen BAAs, sofern anwendbar. Die aktuelle Liste der Unterauftragsverarbeiter befindet sich unter /legal/subprocessors und ist dieselbe Liste, die auch für die GDPR Artikel 28-Dokumentation verwendet wird.
Rückgabe oder Vernichtung von PHI bei Vertragsende, mit einem 30-tägigen Fenster für den Kunden, um Daten vor der Löschung zu exportieren.

Was das BAA nicht tut: Es macht eine nicht HIPAA-fähige Planstufe nicht fähig. Free- und Pro-Pläne beinhalten keinen BAA-Abschluss. Die Infrastruktur ist in allen bezahlten Stufen dieselbe; die rechtlichen Verpflichtungen sind es nicht.

Der Fragebogen für den Einkauf — Antworten zum Kopieren#

Die meisten Sicherheitsfragebögen im Einkauf stellen die gleichen Fragen. Die folgenden Antworten stellen wir direkt zur Verfügung, inklusive Links zu den Artefakten.

Verfügen Sie über einen aktuellen SOC 2 Type II-Bericht? ISO 27001-zertifiziert; SOC 2 Type II-Audit in Arbeit, Type II-Bericht für Q4 2026 geplant. Bridge-Letter und das aktuelle ISO 27001-Zertifikat sind unter NDA über /trust verfügbar. SOC 2 Type I wurde im November 2025 abgeschlossen; der Type I-Bericht ist ebenfalls unter NDA verfügbar.

Unterzeichnen Sie unser BAA? Wir unterzeichnen unser Standard-BAA in den Plänen Business und Enterprise. Kundeneigene BAAs werden im Enterprise-Plan geprüft; gängige Anpassungen (erweiterte Benachrichtigungsfristen bei Verstößen, zusätzliche Bestätigungen von Schutzmaßnahmen, vom Kunden festgelegte Kontrollen für Subunternehmer) werden akzeptiert. Kontaktieren Sie [email protected] für den Standardtext oder um eine Prüfung eines kundeneigenen Dokuments zu starten.

Wo werden die Daten gespeichert? EU-Kunden werden standardmäßig nach Frankfurt (Hetzner FRA1, EU-Region) geleitet. US-Kunden können Ashburn (Hetzner ASH) wählen. Singapore (OVH SGP) ist für APAC-Kunden verfügbar. Die regionsübergreifende Replikation ist pro Workspace optional; ohne diese bleiben alle Kundendaten in der gewählten Region. Der Beitrag zur Datenresidenz beschreibt die Architektur der Datenresidenz im Detail.

Welche Verschlüsselung wird verwendet? TLS 1.3 bei der Übertragung auf allen externen Endpunkten (Redirect, API, Dashboard, Analytics). AES-256 Envelope-Verschlüsselung im Ruhezustand für die Postgres-Primary, den ClickHouse-Cluster und den Objektspeicher. Vom Kunden bereitgestelltes KMS wird im Enterprise-Plan über die BYO KMS-Integration unterstützt.

Wie wird der Zugriff bereitgestellt und entzogen? Single Sign-On über SAML oder OIDC via WorkOS; SCIM-Provisionierung für den Benutzerlebenszyklus. Rollenbasierte Zugriffskontrolle auf Workspace-Ebene mit benutzerdefinierten Rollen im Enterprise-Plan verfügbar. Der Beitrag zu SCIM und SSO behandelt die Integration und die Lebenszyklus-Kontrollen.

Wie sieht Ihr Incident Response-Prozess aus? Dokumentiertes Runbook mit einer SLA von 60 Minuten für die erste Reaktion, einer SLA von 24 Stunden für technische Updates und benannten Rotationen für Incident Commander. Benachrichtigungen bei Datenschutzverletzungen folgen den Zeitplänen in unserem BAA und unserem DPA. Der vollständige Runbook-Index befindet sich unter /docs/runbooks/.

Wer sind Ihre Unterauftragsverarbeiter? Fünf namentlich genannte Unterauftragsverarbeiter: Hetzner (Infrastruktur, EU), OVH (Infrastruktur, APAC), Postmark (transaktionale E-Mails), Cloudflare (DDoS-Schutz auf öffentlichen Marketing-Oberflächen; nicht auf der Redirect-Datenebene), monobank Plata (Abrechnung für den EU-Kundenstamm). Die vollständige Liste mit Kontaktdaten finden Sie unter /legal/subprocessors.

Wie lange bewahren Sie Kundendaten auf? Klick-Ereignisse werden für die Dauer des Vertrages plus dem 30-tägigen Exportfenster bei Vertragsende aufbewahrt und dann gelöscht. Die Link-Konfiguration wird für die Dauer des Vertrages plus dem Exportfenster aufbewahrt. Aggregierte Metriken (Anzahl der Links pro Workspace, Anzahl der Klicks pro Tag, keine PII) werden über den Vertrag hinaus für die Abrechnung und interne Kapazitätsplanung aufbewahrt.

Die Beweisdatei, die ein Prüfer sehen möchte#

Wenn Sie ein Unternehmenskunde sind, der sein eigenes SOC 2-Audit durchführt, und Elido ein relevanter Anbieter ist, wird Ihr Prüfer wahrscheinlich nach Beweisen im Rahmen Ihrer CC9.2- (Anbietermanagement) und CC1.4- (Verpflichtungen) Kontrollen fragen. Die Anbieterakte sollte enthalten:

Unser aktuelles ISO 27001-Zertifikat (jährlich erneuerbar).
Unseren SOC 2 Type I-Bericht und den SOC 2 Type II Bridge-Letter (verfügbar unter NDA).
Unser unterzeichnetes DPA und ggf. BAA.
Unsere Liste der Unterauftragsverarbeiter und die Daten etwaiger Änderungen.
Einen Schnappschuss unserer öffentlichen Sicherheitsseite unter /trust und die aktuellste Version der Datenschutzrichtlinie.
Unsere Historie der Benachrichtigungen bei Datenschutzverletzungen (die öffentliche Historie ist leer – das interne Protokoll wird während des Einkaufs unter NDA eingesehen).

Die Beweisdatei wird einmal pro Kundenbeziehung erstellt und jährlich aktualisiert. Die oben genannte Liste ist das Standardset; prüferspezifische Ergänzungen werden von Fall zu Fall behandelt.

Was wirklich schwierig ist#

Zwei Dinge sind bei SOC 2 und HIPAA für einen Redirect-Service wirklich schwierig, und wir erwähnen sie, weil sie im Gespräch mit dem Einkauf meist irgendwann zur Sprache kommen.

Der Nachweis der kontinuierlichen Überwachung der Edge-POPs ist nicht trivial. Die Redirect-Datenebene verarbeitet große Mengen an Traffic über drei Regionen hinweg, und der Prüfer verlangt Beweise dafür, dass das Monitoring kontinuierlich läuft und nicht nur Stichproben macht. Der aktuelle Ansatz verwendet jede Minute synthetische Redirects aus jeder Region, wobei der Alarmstatus in einem manipulationssicheren Protokoll festgehalten wird. Die Kosten für dieses Monitoring sind real und das Design hat drei Iterationen durchlaufen, um das richtige Signal-Rausch-Verhältnis zu finden. Der Observability-Leitfaden in der Dokumentation deckt die aktuelle Konfiguration ab; die zugrunde liegende ADR befindet sich unter /docs/adr/0024-sla-monitoring.md.

Die HIPAA-Fristen für die Benachrichtigung bei Datenschutzverletzungen sind strenger als die der GDPR. HIPAA verlangt die Benachrichtigung betroffener Personen innerhalb von 60 Tagen nach Entdeckung; bei Verstößen, die mehr als 500 Personen betreffen, sind zusätzliche Benachrichtigungen an das HHS und an die Medien erforderlich. Die GDPR erlaubt 72 Stunden an die Aufsichtsbehörde, aber die Frist für die Benachrichtigung der betroffenen Personen lautet „unverzüglich“. Bei einer Verletzung in mehreren Gerichtsbarkeiten dominiert oft der HIPAA-Zeitplan. Wir verpflichten uns standardmäßig zum HIPAA-Zeitplan für alle Vorfälle, die über die US geroutete Kundendaten betreffen, und unser Incident Response-Runbook spiegelt dies wider.