Sicherheit & Vertrauen

1. Zusammenfassung auf einer Seite

Nose for Horse („Nose“) ist ein Produkt in einem frühen Entwicklungsstadium. Wir verfügen derzeit weder über eine SOC-2- noch über eine ISO-27001-Zertifizierung, und wir haben noch keinen externen Penetrationstest beauftragt. Diese Seite beschreibt, welche Daten wir vorhalten, wo sie verarbeitet werden und welche Klassen von Schutzmaßnahmen sie absichern, damit ein sicherheitsbewusster Reitstall eine informierte Entscheidung treffen kann.

• Wer wir sind. Nose ist eine Software für den Betrieb einer Reitschule — Unterrichtsplanung, Anwesenheits- und Zahlungserfassung, Verwaltung von Reitkarten 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 for Horse („Nose“) 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, Reitkarten/Gutscheine, Kennzeichnungen zur Zahlungsverfolgung, Freitextnotizen); Kalender-PINs und Einladungstoken, die ausschließlich als Einweg-Hashes gespeichert werden. Wir halten keine Zahlungskarten- oder Bankdaten und keine Gesundheitsdaten vor. Vollständige Übersicht in „Daten, die wir vorhalten“ unten.
• Was die Daten schützt. Verschlüsselung bei der Übertragung und im Ruhezustand; datenbankseitig erzwungene Mandantentrennung je Stall; 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. Siehe „Technische Maßnahmen“ unten.
• Wo die Verarbeitung stattfindet. Über mehr als eine Datenregion hinweg, und wir fügen mit unserem Wachstum weitere Regionen hinzu. Kundendaten von Ställen in der US-Region werden in den Vereinigten Staaten gespeichert. Der Dienst wird aus der Europäischen Union heraus betrieben, administriert und betreut. Ställe in unserer EU-Region werden aus dem EWR bedient. Einige Dienste teilen sich beide Regionen und laufen im EWR — transaktionsbezogene E-Mails, Fehlerüberwachung, Produktanalyse —, und einige Komponenten laufen global. Die Regionen und Übermittlungsmechanismen der einzelnen Anbieter finden Sie auf der Seite Unterauftragsverarbeiter.
• Was uns noch fehlt. Keine SOC-2- oder ISO-27001-Zertifizierung, kein externer Penetrationstest. Wenn Ihr Beschaffungsprozess heute eines davon voraussetzt, sind wir noch nicht der richtige Anbieter für Sie.
• So erreichen Sie uns in Sicherheitsfragen. E-Mail an support@nose.horse 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 Nose in Berührung kommen.

Wo eine Zeile die Region Ihres Stalls nennt, ist damit die EU-Region oder die US-Region gemeint — festgelegt bei der Erstellung des Stalls und näher beschrieben unter „Infrastruktur — wer betreibt was, und wo“ unten.

Was wir nicht vorhalten

• Keine Zahlungskarten- oder Bankdaten. Nose ist niemals Partei einer Zahlung und verarbeitet niemals Kartendaten. Offline-Methoden („Bar“, „Reitkarte“, „Gutschein“, „Überweisung“) sind Kennzeichnungen zur Nachverfolgung, die ein Stall erfasst — keine Transaktionen, die Nose ausführt. Sowohl bei der Abonnementabrechnung des Stalls (Stripe für polnische Ställe, Dodo Payments als Merchant of Record für nicht-polnische Ställe) als auch bei Online-Zahlungen von Reitern, wenn ein Stall diese aktiviert (Stripe, mit Abrechnung auf das eigene Konto des Stalls), werden die Kartendaten vollständig über die eigene Kasse des Zahlungsanbieters abgewickelt 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 Nose.

3. Infrastruktur — wer betreibt was, und wo

Nose wird auf verwalteter Cloud-Infrastruktur gehostet, mit einer kleinen Anzahl spezialisierter Anbieter („Unterauftragsverarbeiter“), von denen jeder einen eng begrenzten Ausschnitt übernimmt. Keiner von ihnen hat durchgängigen Zugriff auf alles. Nose betreibt zwei Datenregionen: eine EU-Region und eine US-Region. Kundendaten von Ställen in der US-Region werden in den Vereinigten Staaten gespeichert. Der Dienst wird aus der Europäischen Union heraus betrieben, administriert und betreut. Die operativen Daten eines Stalls liegen ausschließlich in der Datenbank seiner eigenen Region — es gibt keine Replikation zwischen den Regionen und keinen Pfad in der Anwendung, der regionsübergreifend liest. Drei Dienste teilen sich beide Regionen und verbleiben im EWR — transaktionsbezogene E-Mails, Fehlerüberwachung und Produktanalyse.

Die maßgebliche, stets aktuelle Liste der Anbieter — mit Zweck, Kategorien personenbezogener Daten, Verarbeitungsregion je Datenregion und Übermittlungsmechanismus jedes einzelnen Anbieters — ist die Seite Unterauftragsverarbeiter. Die Datenschutzerklärung und der AVV verweisen auf dieselbe Quelle, anstatt abweichende Kopien vorzuhalten, und diese Seite ebenso.

4. Technische Maßnahmen

Dies sind die Klassen von Schutzmaßnahmen, die heute tatsächlich vorhanden sind. 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, mit HSTS-Preload.
• Keine gemischten Inhalte — die Content-Security-Policy lehnt unsichere Ressourcen ab.

Mandantentrennung und Autorisierung

• Row-Level-Security, 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 Rollenprüfungen als zusätzliche Verteidigungsebene über der datenbankseitigen Isolierung, niemals als einzige Sicherung.

Authentifizierung

• Passwortlose Anmeldung — E-Mail-Magic-Link oder optionale Anmeldung über Google oder Apple. 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 fehlendes oder abgelaufenes Step-up führt zur Ablehnung.

Geheimnisse und Zugangsdatenverwaltung

• Kalender-PINs und Einladungstoken werden ausschließlich als Einweg-Hashes gespeichert; Einladungstoken sind einmalig verwendbar und zeitlich begrenzt, und Roh-Token werden nie dauerhaft gespeichert.
• Privilegierte Dienst-Zugangsdaten sind ausschließlich serverseitig — sie werden nie an den Browser ausgeliefert; eine Prüfung zur Build-Zeit setzt dies durch.

Eingabe- und Ausgabeverarbeitung

• Jede serverseitige Eingabe wird schemavalidiert — clientseitige Validierung wird nur als UX behandelt; der Server ist die Vertrauensgrenze.
• Eine strikte Content-Security-Policy und ein abgesicherter Satz von Sicherheits-Headern werden auf jede Antwort angewendet.
• Automatisches Escaping der Ausgabe; von Nutzern verfasste Inhalte sind derzeit reiner Text.

Missbrauchs- und Bot-Schutz

• Ratenbegrenzung und Bot-Schutz werden bei der Authentifizierung und weiteren sensiblen Endpunkten angewendet.

Daten im Ruhezustand und Audit-Trail

• Verschlüsselung im Ruhezustand für die Datenbank und den Dateispeicher.
• 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 — personenbezogene Daten werden aus Fehlerberichten entfernt, bevor diese unsere Systeme verlassen; was übrig bleibt, ist technischer Kontext zuzüglich pseudonymer Kennungen.

Backups und Wiederherstellung

• Automatisierte tägliche Datenbank-Backups mit einem rollierenden Aufbewahrungsfenster. Frühere Deployments werden aufbewahrt, sodass eine fehlerhafte Version schnell zurückgerollt werden kann.

5. Organisatorische Maßnahmen

• 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. Privilegierte Zugangsdaten sind 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.
• Anbieterseitige Zugriffsprotokollierung. Administrative Aktionen bei unseren Anbietern werden von diesen protokolliert und überprüft.
• Vertraulichkeit. Alle Personen mit Zugriff auf die Produktionsumgebung sind hinsichtlich der über den Dienst verarbeiteten personenbezogenen Daten zur Vertraulichkeit verpflichtet, wie im AVV festgehalten.

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

Überwachung. Fehler und sicherheitsrelevante Ereignisse werden überwacht, und das unveränderliche (append-only) Audit-Protokoll liefert eine dauerhafte Aufzeichnung 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 umsetzen — es handelt sich nicht um ein zusätzliches vertragliches Versprechen über die DSGVO hinaus.

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

7. Was wir noch nicht haben

Wir verfügen bislang weder über SOC 2 noch über ISO 27001, und wir haben noch keinen externen Penetrationstest beauftragt. Wir veröffentlichen eine Zertifizierung, wenn wir sie haben, nicht vorher. Verlangt der Beschaffungsprozess eines interessierten Reitstalls heute eines davon, sind wir derzeit nicht der richtige Anbieter — und wir sagen das lieber, als das Gespräch hinauszuzögern.

8. Compliance-Einordnung

DSGVO (Verordnung 2016/679). Nose 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, die Anmeldeidentität jedes Kontoinhabers unabhängig von seiner Rolle, 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 Nose verarbeitet nach dessen dokumentierten Weisungen gemäß AVV (Art. 28 DSGVO). Unterauftragsverarbeiter unterliegen Verträgen nach Art. 28 (AVV + SCCs/DPF, das UK-Addendum oder ein gleichwertiger Mechanismus, sofern eine Übermittlung Regionen überschreitet) — siehe die Seite Unterauftragsverarbeiter.

Daten von Kindern. Reitschulen unterrichten regelmäßig Kinder, daher verarbeitet Nose 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 nach dem für ihn geltenden Recht erforderliche elterliche Einwilligung oder Befugnis (Art. 8 DSGVO in der EU und im Vereinigten Königreich; COPPA und bundesstaatliches Recht in den Vereinigten Staaten); Nose minimiert die über ein Kind gespeicherten Daten und richtet sich nicht direkt an Kinder und bewirbt den Dienst ihnen gegenüber 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 Nose als Auftragsverarbeiter unterstützt; ausgenommen ist die Anmeldeidentität eines Reiters, für die Nose Verantwortlicher ist, sodass Rechte daran direkt gegenüber Nose geltend gemacht werden.

PCI DSS — nicht anwendbar auf Nose. Wir verarbeiten, speichern oder übermitteln keine Kartendaten. Bei der Abonnementabrechnung des Stalls wird der Kartendatenpfad vollständig vom Zahlungsanbieter über dessen gehostete Kasse abgewickelt — Stripe (Zahlungsdienstleister) für polnische Ställe, wobei Nose als Händler auftritt, und Dodo Payments als Merchant of Record für nicht-polnische Ställe. Bei Online-Zahlungen von Reitern, wenn ein Stall diese aktiviert, werden die Daten von Karte, Wallet oder (in Polen) BLIK vollständig von Stripe (über Stripe Connect) abgewickelt und auf das eigene Stripe-Konto des Stalls abgerechnet — Verkäufer ist der Stall, und Stripe ist der PCI-konforme Zahlungsdienstleister, während Nose lediglich Anweisungen weiterleitet und nie Kartendaten erhält. In jedem Fall erhält Nose nie Kartendaten und bleibt außerhalb des PCI-Anwendungsbereichs.

EU-KI-Verordnung — nicht anwendbar. Nose 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. 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 wird nur mit Einwilligung geladen (in den Vereinigten Staaten: bis Sie sie ausschalten); 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 Nose gefunden zu haben:

• Schreiben Sie eine E-Mail an [support@nose.horse](mailto:support@nose.horse) mit `Security` in der Betreffzeile. (Eine dedizierte `security@`-Adresse und ein PGP-Schlüssel sind geplant.)
• 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; wir lassen einen glaubwürdigen Bericht 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). Für Meldungen zahlen wir keine Geldprämien.

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