Sicherheit & Vertrauen

1. Zusammenfassung auf einer Seite

Unser ehrlicher aktueller Stand, mit Datum 2026-07-08: horsenose ist ein Produkt in einem frühen Entwicklungsstadium, das von einem Einzelunternehmer betrieben wird. Wir verfügen derzeit WEDER über eine SOC-2- noch über eine ISO-27001-Zertifizierung, und es hat noch kein externer Penetrationstest stattgefunden. Diese Seite beschreibt, was wir tun, welche Daten wir vorhalten, was uns noch fehlt und was auf der Roadmap steht. Wir legen unseren aktuellen Stand lieber offen dar, als ihn zu beschönigen.

• Wer wir sind. horsenose ist eine Software für den Betrieb einer Reitschule — Unterrichtsplanung, Anwesenheits- und Zahlungserfassung, Verwaltung von Reitpässen und Gutscheinen, Berechnung der Einnahmen von Reitlehrern und ein Einblick für die Kunden eines Stalls in ihre eigenen Buchungen. Betrieben wird es von DF Daniel Fojcik, einem polnischen Einzelunternehmen (NIP 6472592229 / REGON 387798601, Marklowice), das unter Nose / horsenose firmiert.
• Unsere zwei Rollen. Für unsere eigenen Konto-, Analyse- und Sicherheitsdaten sind wir Verantwortlicher; für die Reiter-/Kundendaten, die ein Stall einträgt, handeln wir als Auftragsverarbeiter nach dessen Weisungen. Das Auftragsverarbeitungsverhältnis wird durch unseren Auftragsverarbeitungsvertrag (AVV) geregelt. Siehe „Compliance-Einordnung" unten.
• Was wir vorhalten. Konto-E-Mail-Adresse und optionaler Profilname/Telefonnummer; Einladungs-E-Mail-Adressen; die operativen Datensätze, die ein Stall über seine Reiter einträgt (Namen, Kontaktdaten, Unterrichtsteilnahme, Reitpässe/Gutscheine, Kennzeichnungen zur Zahlungsverfolgung, Freitextnotizen); mit bcrypt gehashte Zeitplan-PINs; mit SHA-256 gehashte Einladungstoken. Wir halten keine Zahlungskarten- oder Bankdaten und keine Gesundheitsdaten vor. Vollständige Übersicht in „Daten, die wir vorhalten" unten.
• Was die Daten schützt. TLS für den gesamten Datenverkehr mit HSTS-Preload; Verschlüsselung im Ruhezustand (AES-256); datenbankseitig erzwungene Row-Level-Security zur Isolierung jedes Stalls; serverseitige Sitzungsvalidierung; erneute Authentifizierung (Step-up) bei destruktiven und administrativen Aktionen; eine strikte Content-Security-Policy; Ratenbegrenzung und Bot-Schutz; sowie ein unveränderliches (append-only) Audit-Protokoll. Vollständige Liste in „Technische Maßnahmen" unten.
• Wo die Verarbeitung stattfindet. Standardmäßig EU — Datenbank, E-Mail-Versand, Analyse, Fehlerüberwachung und der Ratenbegrenzungsspeicher werden im EWR gehostet. Es sind nicht 100 % EWR: Zwei Randbereiche (das globale Netzwerk von Cloudflare und die optionale Google-Anmeldung in den USA) liegen außerhalb, abgesichert durch das EU-US Data Privacy Framework und/oder Standardvertragsklauseln. Siehe „Infrastruktur — wer betreibt was, und wo" unten.
• Was uns noch fehlt. Keine SOC-2- oder ISO-27001-Zertifizierung, kein externer Penetrationstest, kein Bug-Bounty-Programm. Siehe „Was uns noch fehlt — Roadmap" unten. Wenn Ihr Beschaffungsprozess heute eine SOC-2-Zertifizierung voraussetzt, sind wir noch nicht der richtige Anbieter für Sie.
• So erreichen Sie uns in Sicherheitsfragen. E-Mail an support@horsenose.eu mit `Security` in der Betreffzeile. Siehe „Reaktion auf Vorfälle (72-Stunden-Meldung von Verletzungen)" und „Verantwortungsvolle Offenlegung" unten.

2. Daten, die wir vorhalten

Wir erheben nur das Minimum, das für den Betrieb des Dienstes erforderlich ist. Die folgenden Kategorien sind die personenbezogenen Daten, die mit horsenose in Berührung kommen.

Was wir nicht vorhalten

• Keine Zahlungskarten- oder Bankdaten. Wir verarbeiten keine Zahlungen der Reiter. „Bar“, „Reitpass“, „Gutschein“ und „BLIK“ sind Kennzeichnungen zur Nachverfolgung, die ein Stall erfasst — keine Transaktionen, die horsenose ausführt. Die Abonnementabrechnung (die Gebühr, die ein Stall für horsenose zahlt) ist live, aber Kartendaten werden vollständig über die gehostete Kasse des Zahlungsanbieters abgewickelt — Stripe für polnische Ställe, Dodo Payments (Merchant of Record) für nicht-polnische Ställe — und erreichen uns nie, sodass wir außerhalb des Anwendungsbereichs von PCI DSS bleiben (siehe „Compliance-Einordnung" unten).
• Keine Ausweisdokumente oder Adressen. Wir erheben keine Wohnadressen, Ausweisnummern oder staatlichen Identifikatoren.
• Keine besonderen Kategorien personenbezogener Daten (Gesundheitsdaten). Wir beabsichtigen nicht, Daten nach Art. 9 DSGVO zu erheben, und das Produkt ist nicht darauf ausgelegt, solche zu speichern. Ställe werden (im AVV) angewiesen, keine besonderen Kategorien personenbezogener Daten in Freitextfelder einzutragen. Notizen zu einem Pferd betreffen ein Tier, keine Person, und fallen daher nicht unter die DSGVO.
• Keine Werbeprofile, Retargeting-Kennungen oder seitenübergreifendes Tracking. Keine Meta/LinkedIn/X/TikTok-Pixel; kein Browser-Fingerprinting.
• Keine Daten werden verkauft, vermietet oder an Dritte verliehen.
• Kein Training von KI-/ML-Modellen mit Ihren Daten. Wir trainieren, feinjustieren oder evaluieren kein KI- oder Machine-Learning-Modell mit personenbezogenen Daten aus horsenose. Die `pgvector`-Erweiterung ist in unserem Postgres für künftige interne Suchanwendungsfälle aktiviert, wird aber derzeit nicht mit aus personenbezogenen Daten abgeleiteten Embeddings befüllt.

3. Infrastruktur — wer betreibt was, und wo

horsenose ist eine Next.js-Anwendung, die auf Vercel gehostet wird, mit einer Supabase-Postgres-Datenbank im Hintergrund und einer kleinen Anzahl spezialisierter Anbieter („Unterauftragsverarbeiter“), von denen jeder einen eng begrenzten Ausschnitt übernimmt. Keiner von ihnen hat durchgängigen Zugriff auf alles. Unser Standard ist die EU, und das sagen wir ehrlich: Datenbank, E-Mail-Versand, Produktanalyse und Fehlerüberwachung laufen alle im EWR. Es sind nicht 100 % EWR — einige Randbereiche liegen außerhalb, abgesichert durch das EU-US Data Privacy Framework und/oder Standardvertragsklauseln (SCCs). Wir werden keine uneingeschränkte Aussage wie „alle Daten bleiben in der EU“ veröffentlichen, solange das nicht zutrifft.

Die maßgebliche, stets aktuelle Fassung dieser Tabelle — mit anbieterbezogenen Kategorien personenbezogener Daten und Übermittlungsmechanismen — wird auf der Seite Unterauftragsverarbeiter gepflegt; die Datenschutzerklärung und der AVV verweisen auf dieselbe Quelle, anstatt abweichende Kopien vorzuhalten.

4. Technische Maßnahmen

Dies sind die Kontrollen, die heute tatsächlich vorhanden sind. (Kontrollen, die wir noch nicht umgesetzt haben, sind gesondert unter „Was uns noch fehlt — Roadmap" unten aufgeführt — wir stellen geplante Maßnahmen nicht als bereits bestehend dar.) Dies ist zugleich die inhaltliche Grundlage hinter dem AVV → „Vertraulichkeit, Sicherheit und Unterauftragsverarbeiter", der für unsere technischen und organisatorischen Maßnahmen auf diese Seite verweist.

Netzwerk und Übertragung

• TLS für den gesamten Datenverkehr, durchgesetzt von Vercel und Supabase. HSTS ist gesetzt mit `max-age=63072000; includeSubDomains; preload`.
• Keine gemischten Inhalte — die Content-Security-Policy lehnt `http://`-Ressourcen ab.

Mandantentrennung und Autorisierung

• Row-Level-Security (RLS), auf jeden Stall begrenzt, für jede operative Tabelle, durchgesetzt in der Datenbank selbst — die Daten eines Stalls können nicht von einem anderen gelesen werden, selbst wenn der Anwendungscode fehlerhaft wäre. Dies ist die primäre Verteidigung gegen mandantenübergreifenden Zugriff.
• Anwendungsseitige Rollenschranken (authentifiziert / stall-gebunden / Instructor-oder-Admin / Super-Admin) als zusätzliche Verteidigungsebene zur RLS, niemals als einzige Sicherung.
• Prüfungen auf Routenebene verlangen eine aktive Sitzung für geschützte Pfade und Super-Admin-Status für die Admin-Oberfläche.

Authentifizierung

• Passwortlose Anmeldung — E-Mail-Magic-Link (verwaltet von Supabase Auth) oder optionale Google-Anmeldung (OAuth). Es werden keine Passwörter gespeichert.
• Serverseitige Sitzungsvalidierung bei jeder geschützten Anfrage — dem Anmelde-Cookie allein wird nie vertraut.
• Erneute Authentifizierung (Step-up) für destruktive und administrative Aktionen — ein kurzlebiges, separat signiertes Step-up-Cookie ist erforderlich für Vorgänge wie Kontolöschung, Änderungen der letzten Admin-Rolle, Massendeaktivierung, Stallarchivierung und alle Super-Admin-Schreibvorgänge; ein fehlendes oder abgelaufenes Step-up führt zur Ablehnung (fail closed).
• Die Plattform-Admin-Oberfläche liefert 404, wenn kein Super-Admin konfiguriert ist, sodass ihre Existenz nicht offengelegt wird.

Geheimnisse und Zugangsdatenverwaltung

• Zeitplan-PINs werden als bcrypt-Hashes gespeichert; Einladungstoken werden als SHA-256-Hashes gespeichert — einmalig verwendbar, zeitlich begrenzt (7 Tage Gültigkeit) und an eine E-Mail-Adresse gebunden; Roh-Token werden nie dauerhaft gespeichert.
• Der Datenbank-Service-Role-Key ist ausschließlich serverseitig — er wird nie in Client-JavaScript eingebettet; ein Build-Time-Validator lässt den Build fehlschlagen, wenn eine sensible Variable falsch präfixiert ist.

Eingabe- und Ausgabeverarbeitung

• Schemavalidierung an jeder serverseitigen Eingabegrenze — clientseitige Validierung wird nur als UX behandelt; der Server ist die Vertrauensgrenze.
• Eine strikte Content-Security-Policy mit einem Nonce pro Anfrage, zusammen mit einem restriktiven Satz von Sicherheits-Headern (`X-Content-Type-Options`, `X-Frame-Options` / `frame-ancestors`, `Referrer-Policy`, Cross-Origin-Isolation-Header und eine restriktive `Permissions-Policy`).
• Automatisches Escaping der Ausgabe; von Nutzern verfasste Inhalte sind derzeit reiner Text.

Missbrauchs- und Bot-Schutz

• Ratenbegrenzung bei Anmeldung, Registrierung, Magic-Link, Einladungsannahme, Export/Löschung und weiteren sensiblen Endpunkten (je nach Aktion pro E-Mail, pro IP, pro Nutzer oder pro Stall; jede Richtlinie ist gezielt entweder fail-open oder fail-closed konzipiert).
• Cloudflare Turnstile-Bot-Schutz auf dem Anmeldeformular, dem Registrierungsformular, der Magic-Link-Anforderung, der Einladungsannahmeseite und der PIN-Eingabe des öffentlichen Stundenplans.

Daten im Ruhezustand und Audit-Trail

• Verschlüsselung im Ruhezustand über Supabase (AES-256).
• Ein unveränderliches (append-only) Audit-Protokoll erfasst sicherheitsrelevante Ereignisse (Authentifizierung, Rollen- und Mitgliedschaftsänderungen, finanzielle Ereignisse, Exporte, Löschungen). Es wird immer geschrieben und ist von der operativen Telemetrie getrennt.
• Fehlerüberwachung mit Bereinigung personenbezogener Daten — bevor ein Fehler an Sentry gesendet wird, entfernt ein eigens entwickelter Bereinigungsmechanismus E-Mail-Adressen, Telefonnummern, Nachrichtentexte, Notizen und jedes Feld, das wie ein Token aussieht. Was übrig bleibt, ist technischer Kontext zusammen mit einer pseudonymen Nutzer-UUID, der Stall-Kennung, der Sprache und dem Namen des fehlgeschlagenen Vorgangs.

Backups und Wiederherstellung

• Supabase stellt automatisierte tägliche Backups bereit (7 Tage Aufbewahrung in der aktuellen Stufe; eine längere Aufbewahrung ist geplant, sobald der Dienst reift). Vercel behält frühere Deployments für ein nahezu sofortiges Rollback einer fehlerhaften Version vor.

5. Organisatorische Maßnahmen

• Einzelunternehmer. horsenose wird von einer Person betrieben (Daniel Fojcik). Derzeit gibt es keine Angestellten mit Produktionszugriff. Sollte sich dies ändern — etwa durch die Einbindung eines Auftragnehmers mit Produktionszugriff — wird diese Seite aktualisiert und aktive Ställe werden benachrichtigt.
• Produktionsdaten verbleiben auf verwalteter Infrastruktur. Produktions-Datenbankdumps werden nicht auf lokalen Rechnern gespeichert; die lokale Entwicklung nutzt eine separate Datenbank mit synthetischen Daten.
• Minimalprinzip für Dienstkonten. Der Datenbank-Service-Role-Key ist ausschließlich für den serverseitigen Einsatz vorgesehen; der Datenbankzugriff aus dem Browser erfolgt über einen eingeschränkten Schlüssel hinter der Row-Level-Security.
• Verwaltung von Geheimnissen. Geheimnisse befinden sich in der Umgebungskonfiguration des Hosting-Anbieters und in einer lokalen, von der Versionskontrolle ausgeschlossenen Datei — sie werden nie in das Repository übernommen. Produktionsgeheimnisse werden nicht auf lokale Rechner kopiert.
• Anbieterseitige Zugriffsprotokollierung. Administrative Aktionen bei unseren Anbietern werden von diesen protokolliert; wir prüfen sie anlassbezogen.
• Vertraulichkeit. Das Personal (derzeit der Inhaber) ist hinsichtlich der über den Dienst verarbeiteten personenbezogenen Daten zur Vertraulichkeit verpflichtet, wie im AVV festgehalten.
• Änderungsdisziplin. Codeänderungen durchlaufen vor der Bereitstellung eine strikte Typ-, Lint- und automatisierte Testprüfung, und Datenbankmigrationen werden vor der Produktivsetzung in einer Staging-Umgebung angewendet.

6. Reaktion auf Vorfälle (72-Stunden-Meldung von Verletzungen)

Überwachung. Fehler fließen an Sentry (mit der unter „Technische Maßnahmen" oben beschriebenen Bereinigung personenbezogener Daten); Diagnosedaten auf Anfrageebene sind in den Hosting-Protokollen verfügbar; ein Uptime-Monitor und Alarmierung bei erhöhter Fehlerrate sind Teil der Baseline-Härtung. Das unveränderliche Audit-Protokoll liefert eine dauerhafte Aufzeichnung sicherheitsrelevanter Ereignisse für Untersuchungen.

Unsere Verpflichtung zur Meldung von Datenschutzverletzungen. Kommt es zu einer Verletzung des Schutzes personenbezogener Daten, die voraussichtlich ein Risiko für die Rechte und Freiheiten betroffener Personen zur Folge hat, werden wir:

• Die zuständige Aufsichtsbehörde benachrichtigen — den Präsidenten der UODO in Polen — unverzüglich und, soweit möglich, innerhalb von 72 Stunden, nachdem uns die Verletzung bekannt wurde (Art. 33 DSGVO).
• *Besteht voraussichtlich ein hohes* Risiko für die betroffenen Personen, werden wir diese unverzüglich benachrichtigen und dabei die Art der Verletzung, die betroffenen Datenkategorien, die wahrscheinlichen Folgen und die ergriffenen Maßnahmen beschreiben (Art. 34 DSGVO**).
• Handeln wir als Auftragsverarbeiter für einen Stall, benachrichtigen wir diesen Stall (den Verantwortlichen) unverzüglich, damit er seinen eigenen Pflichten nach Art. 33/34 gegenüber seinen Reitern nachkommen kann.

Dies entspricht der Datenschutzerklärung und dem AVV. Es beschreibt, wie wir eine ohnehin durch die DSGVO auferlegte Pflicht umzusetzen beabsichtigen — es handelt sich nicht um ein zusätzliches vertragliches Versprechen über die DSGVO hinaus. Ein formal dokumentiertes Incident-Response-Runbook ist in Planung (siehe „Was uns noch fehlt — Roadmap" unten); bis dahin reagiert ein Ein-Personen-Team anlassbezogen innerhalb der oben genannten Fristen.

Kontakt. Nicht dringend: support@horsenose.eu. Sicherheit (dringend): E-Mail an support@horsenose.eu mit `Security` in der Betreffzeile.

7. Was uns noch fehlt — Roadmap

Dies ist der Abschnitt, der der restlichen Seite ihre Glaubwürdigkeit verleiht: Wir verbergen die Lücke nicht. Wir sind ein kleiner, junger Betrieb, und mehrere Kontrollen, die ein größerer Kunde erwarten könnte, sind noch nicht vorhanden.

Erfordert der Beschaffungsprozess eines interessierten Stalls heute eine SOC-2-Zertifizierung, sind wir derzeit nicht der richtige Anbieter — und das sagen wir offen, anstatt das Gespräch hinauszuzögern.

8. Compliance-Einordnung

DSGVO (Verordnung 2016/679). horsenose agiert in einer doppelten Rolle: als Verantwortlicher für die Daten, deren Zwecke und Mittel es selbst festlegt (Besucher der Marketing-Website, die Konto-/Kontaktdaten von Stall-Administratoren und Reitlehrern, einwilligungsabhängige Produktanalyse sowie Sicherheits-/Missbrauchspräventionsdaten), und als Auftragsverarbeiter für die operativen Reiter-/Kundendaten, die ein Stall einträgt — dort ist der Stall Verantwortlicher, und horsenose verarbeitet nach dessen dokumentierten Weisungen gemäß AVV (Art. 28 DSGVO). Unterauftragsverarbeiter unterliegen Verträgen nach Art. 28 (AVV + SCCs/DPF, sofern eine Übermittlung den EWR verlässt) — siehe die Seite Unterauftragsverarbeiter.

Daten von Kindern. Reitschulen unterrichten regelmäßig Kinder, daher verarbeitet horsenose wissentlich Daten Minderjähriger im Auftrag eines Stalls (zum Beispiel ein als Unterrichtsteilnehmer eingetragenes Kind, häufig durch einen Elternteil, der Kunde des Stalls ist). Der Stall ist verantwortlich für die Rechtsgrundlage und jede erforderliche elterliche Einwilligung oder Befugnis (Art. 8 DSGVO); horsenose minimiert die über ein Kind gespeicherten Daten und richtet sich nicht direkt an Kinder oder bewirbt diese nicht. Siehe die Datenschutzerklärung → „Datenschutz von Kindern".

Betroffenenrechte werden unterstützt, einschließlich des Self-Service-Zugriffs/der Datenübertragbarkeit über einen JSON-Export unter /account/export und der Löschung über /account/delete (eine 30-tägige, umkehrbare Karenzzeit und eine erneute Authentifizierung per Step-up gelten dabei; bei Löschung entfernen wir direkte Identifikatoren, statt hart zu löschen — Pseudonymisierung nach Art. 4 Abs. 5 DSGVO, keine vollständige Anonymisierung nach Erwägungsgrund 26; siehe die Aufbewahrungstabelle in der Datenschutzerklärung → „Wie lange wir Daten aufbewahren" für die Einzelheiten auf Feldebene). Für Reiterdaten ist der Stall Verantwortlicher, sodass ein Reiter seine Rechte gegenüber seinem Stall geltend macht und horsenose als Auftragsverarbeiter unterstützt.

PCI DSS — nicht anwendbar. Wir verarbeiten, speichern oder übermitteln keine Kartendaten; Bar/Reitpass/Gutschein/BLIK sind Kennzeichnungen zur Nachverfolgung (siehe „Daten, die wir vorhalten" oben). Bei der Abonnementabrechnung wird der Kartendatenpfad vollständig vom Zahlungsanbieter über dessen gehostete Kasse abgewickelt — Stripe (Zahlungsdienstleister) für polnische Ställe, wobei horsenose als Händler auftritt, und Dodo Payments als Merchant of Record für nicht-polnische Ställe — sodass horsenose nie Kartendaten erhält und außerhalb des PCI-Anwendungsbereichs bleibt.

EU-KI-Verordnung — nicht anwendbar. horsenose ist ein Betriebswerkzeug für Reitschulen; es trainiert, entwickelt oder betreibt keine KI-Modelle, und keine Komponente nutzt maschinelles Lernen oder generative KI zur Verarbeitung personenbezogener Daten. Die Postgres-Erweiterung `pgvector` ist für mögliche künftige interne Suchanwendungsfälle aktiviert, wird aber heute nicht mit aus personenbezogenen Daten abgeleiteten Embeddings befüllt; sollte sich dies ändern, werden wir vor Einführung der Funktion eine Position zur EU-KI-Verordnung und eine Verpflichtung „kein Training mit personenbezogenen Daten“ veröffentlichen.

ePrivacy / Cookies. Optionale Analyse (PostHog) wird nur mit Einwilligung geladen; unbedingt erforderliche Cookies sind nach Art. 5 Abs. 3 der ePrivacy-Richtlinie ausgenommen. Siehe die Cookie-Richtlinie.

9. Verantwortungsvolle Offenlegung

Wenn Sie glauben, eine Sicherheitslücke in horsenose gefunden zu haben:

• Schreiben Sie eine E-Mail an [support@horsenose.eu](mailto:support@horsenose.eu) mit `Security` in der Betreffzeile. (Eine dedizierte `security@`-Adresse und ein PGP-Schlüssel sind geplant — siehe „Was uns noch fehlt — Roadmap" oben.)
• Fügen Sie ausreichend Details bei, um das Problem nachvollziehen zu können.
• Geben Sie uns einen angemessenen Zeitraum zur Untersuchung und Behebung, bevor Sie das Problem öffentlich machen.

Was Sie von uns erwarten können:

• Eine Bestätigung und eine erste Einschätzung, sobald dies vernünftigerweise möglich ist. horsenose wird von einer einzelnen Person betrieben und kann keine Antwort am selben Tag garantieren; wir lassen einen glaubwürdigen Bericht jedoch nicht unbeachtet.
• Statusaktualisierungen in angemessenen Abständen, während das Problem geprüft oder behoben wird.
• Nennung in einer Offenlegung nach der Behebung, falls von Ihnen gewünscht (optional).

Was wir derzeit nicht anbieten können: Wir zahlen in diesem Stadium keine finanziellen Bug-Bounties. Wir werden dies klar mitteilen, sobald ein Bounty-Programm verfügbar wird.

Umfang und sicherer Hafen. Sicherheitsforschung in gutem Glauben, die dieser Richtlinie folgt, sich auf Ihre eigenen Konten beschränkt, den Dienst für andere nicht beeinträchtigt und nicht auf andere Daten als Ihre eigenen zugreift, wird nicht als Verstoß gegen unsere Richtlinie zur zulässigen Nutzung oder unsere Nutzungsbedingungen gewertet. Versuchen Sie nicht, auf die Daten eines anderen Stalls oder eines anderen Reiters zuzugreifen, und führen Sie kein automatisiertes Scraping oder Denial-of-Service-Testing gegen den Dienst durch.

10. Änderungsprotokoll