Beveiliging & vertrouwen

1. Samenvatting op één pagina

Nose for Horse (hierna “Nose”) is een product in een vroeg stadium. We hebben vandaag geen SOC 2 of ISO 27001, en we hebben nog geen externe penetratietest laten uitvoeren. Deze pagina beschrijft wat we bewaren, waar het draait en welke soorten maatregelen het beschermen, zodat een beveiligingsbewuste manege een geïnformeerde keuze kan maken.

• Wie we zijn. Nose is software voor het runnen van een manege — lessen inplannen, aanwezigheid bijhouden en hoe ruiters hebben betaald, rittenkaarten en cadeaubonnen beheren, verdiensten van instructeurs berekenen, en de klanten van een manege inzicht geven in hun eigen reserveringen. Het wordt geëxploiteerd door DF Daniel Fojcik, een Poolse eenmanszaak (NIP 6472592229 / REGON 387798601, Marklowice), handelend onder de naam Nose for Horse.
• Onze twee rollen. We zijn verwerkingsverantwoordelijke voor onze eigen account-, analyse- en beveiligingsgegevens, en verwerker die handelt volgens de instructies van elke manege voor de ruiter-/klantgegevens die die manege invoert. De verwerkersrelatie wordt beheerst door onze verwerkersovereenkomst (DPA). Zie “Compliance-kader” hieronder.
• Wat we bewaren. Het e-mailadres van de account en optioneel een profielnaam/telefoonnummer; e-mailadressen van uitnodigingen; de operationele gegevens die een manege over haar ruiters invoert (namen, contactgegevens, deelname aan lessen, rittenkaarten/cadeaubonnen, labels voor betalingsregistratie, vrije tekstnotities); rooster-pincodes en uitnodigingstokens die uitsluitend als eenrichtingshash worden opgeslagen. We bewaren geen betaalkaart- of bankgegevens en geen gezondheidsgegevens. Volledig overzicht in “Gegevens die we bewaren” hieronder.
• Wat het beschermt. Versleuteling onderweg en in rust; tenantisolatie die in de database zelf wordt afgedwongen; server-side sessievalidatie; step-up-herauthenticatie voor destructieve en administratieve handelingen; een strikt Content Security Policy; rate limiting en botbescherming; en een append-only auditlog. Zie “Technische maatregelen” hieronder.
• Waar het draait. In meer dan één dataregio, en we voegen regio's toe naarmate we groeien. Klantgegevens van maneges in de VS-regio worden opgeslagen in de Verenigde Staten. De Dienst wordt geëxploiteerd, beheerd en ondersteund vanuit de Europese Unie. Maneges in onze EU-regio worden bediend vanuit de EER. Een paar diensten worden door beide regio's gedeeld en draaien in de EER — transactionele e-mail, foutmonitoring, productanalyse — en een paar onderdelen draaien wereldwijd. De regio's en doorgiftemechanismen per leverancier staan op de pagina Subverwerkers.
• Wat we vandaag nog niet hebben. Geen SOC 2, geen ISO 27001 en geen externe penetratietest. Als jouw inkoopproces vandaag een van deze zaken vereist, zijn wij nog niet de juiste keuze.
• Hoe je ons bereikt over beveiliging. Mail support@nose.horse met `Security` in de onderwerpregel. Zie “Reactie op incidenten (melding van datalekken binnen 72 uur)” en “Verantwoorde openbaarmaking” hieronder.

2. Gegevens die we bewaren

We verzamelen het minimum dat nodig is om de Dienst te laten draaien. De onderstaande categorieën zijn de persoonsgegevens die Nose raken.

Waar in een rij de regio van jouw manege staat, gaat het om de EU-regio of de VS-regio — vastgelegd op het moment dat de manege werd aangemaakt, en beschreven hieronder onder “Infrastructuur — wie draait wat, en waar”.

Wat we niet bewaren

• Geen betaalkaart- of bankgegevens. Nose is nooit partij bij een betaling en verwerkt nooit kaartgegevens. Offline methoden ("contant", "rittenkaart", "cadeaubon", "overboeking") zijn labels die een manege registreert — geen transacties die Nose uitvoert. Voor de abonnementsfacturering van de manege (Stripe voor Poolse maneges, Dodo Payments als Merchant of Record voor niet-Poolse maneges) en voor online betalingen door ruiters waar een manege die inschakelt (Stripe, met afrekening op de eigen rekening van de manege) worden de kaartgegevens volledig afgehandeld op de eigen checkout van de betaalprovider en bereiken ze ons nooit — waardoor we buiten de reikwijdte van PCI DSS blijven (zie “Compliance-kader” hieronder).
• Geen identiteitsdocumenten of adressen. We verzamelen geen woonadressen, nummers van identiteitsdocumenten of overheidsidentificatoren.
• Geen bijzondere categorieën persoonsgegevens (gezondheidsgegevens). We hebben niet de bedoeling gegevens als bedoeld in artikel 9 AVG (GDPR) te verzamelen en het product is niet ontworpen om die op te slaan. Maneges krijgen (in de DPA) de instructie geen bijzondere categorieën persoonsgegevens in vrije tekstvelden in te voeren. Notities over een paard gaan over een dier, niet over een persoon, en vallen buiten de AVG.
• Geen advertentieprofielen, retargeting-identificatoren of cross-site tracking. Geen Meta-/LinkedIn-/X-/TikTok-pixels; geen browser-fingerprinting.
• Geen gegevens die worden verkocht, verhuurd of uitgeleend aan derden.
• Geen training van AI-/ML-modellen op jouw gegevens. We trainen, finetunen of evalueren geen enkel AI- of machine-learningmodel op persoonsgegevens uit Nose.

3. Infrastructuur — wie draait wat, en waar

Nose wordt gehost op beheerde cloudinfrastructuur, met een kleine set gespecialiseerde leveranciers ("subverwerkers") die elk een smal stukje afhandelen. Geen van hen heeft end-to-end toegang tot alles. Nose draait twee dataregio's: een EU-regio en een VS-regio. Klantgegevens van maneges in de VS-regio worden opgeslagen in de Verenigde Staten. De Dienst wordt geëxploiteerd, beheerd en ondersteund vanuit de Europese Unie. De operationele gegevens van een manege staan uitsluitend in de database van haar eigen regio — er is geen replicatie tussen regio's en geen pad in de applicatie dat over regio's heen leest. Drie diensten worden door beide regio's gedeeld en blijven in de EER — transactionele e-mail, foutmonitoring en productanalyse.

De canonieke, altijd actuele lijst van leveranciers — met per leverancier het doel, de categorieën persoonsgegevens, de verwerkingsregio per dataregio en het doorgiftemechanisme — is de pagina Subverwerkers. Het Privacybeleid en de DPA verwijzen naar dezelfde bron in plaats van uiteenlopende kopieën bij te houden, en deze pagina doet dat ook.

4. Technische maatregelen

Dit zijn de soorten maatregelen die vandaag daadwerkelijk aanwezig zijn. Dit is ook de inhoud achter de DPA → “Vertrouwelijkheid, beveiliging en subverwerkers”, die voor onze technische en organisatorische maatregelen naar deze pagina verwijst.

Netwerk en transport

• TLS voor al het verkeer, met HSTS-preload.
• Geen mixed content — het Content Security Policy weigert onveilige bronnen.

Tenantisolatie en autorisatie

• Row-level security afgebakend per manege op elke operationele tabel, afgedwongen in de database zelf — de gegevens van de ene manege kunnen niet door een andere worden gelezen, zelfs niet als de applicatiecode een fout zou bevatten. Dit is de primaire verdediging tussen tenants.
• Rolcontroles in de applicatielaag als defence-in-depth boven op de isolatie in de database, nooit als enige linie.

Authenticatie

• Wachtwoordloos inloggen — e-mail-magic-link, of optioneel inloggen met Google of Apple. Er worden geen wachtwoorden opgeslagen.
• Server-side sessievalidatie bij elk beschermd verzoek — de inlogcookie alleen wordt nooit vertrouwd.
• Step-up-herauthenticatie voor destructieve en administratieve handelingen; een ontbrekende of verlopen step-up blokkeert de handeling.

Geheimen en omgang met inloggegevens

• Rooster-pincodes en uitnodigingstokens worden uitsluitend als eenrichtingshash opgeslagen; uitnodigingstokens zijn eenmalig te gebruiken en in tijd beperkt, en ruwe tokens worden nooit bewaard.
• Geprivilegieerde inloggegevens van diensten zijn uitsluitend server-side — ze worden nooit naar de browser gestuurd; een controle tijdens de build dwingt dat af.

Verwerking van invoer en uitvoer

• Elke server-invoer wordt tegen een schema gevalideerd — validatie aan de clientzijde wordt uitsluitend als UX behandeld; de server is de vertrouwensgrens.
• Een strikt Content Security Policy en een dichtgetimmerde set beveiligingsheaders worden op elk antwoord toegepast.
• Automatische escaping van uitvoer; door gebruikers geschreven inhoud is in dit stadium platte tekst.

Misbruik- en botbescherming

• Rate limiting en botbescherming worden toegepast op authenticatie en andere gevoelige endpoints.

Gegevens in rust en audittrail

• Versleuteling in rust op de database en de bestandsopslag.
• Een append-only auditlog legt beveiligingsrelevante gebeurtenissen vast (authenticatie, rol- en lidmaatschapswijzigingen, financiële gebeurtenissen, exports, verwijderingen). Het wordt altijd geschreven en staat los van operationele telemetrie.
• Foutmonitoring met het wegfilteren van persoonsgegevens — persoonsgegevens worden uit foutmeldingen gefilterd voordat die onze systemen verlaten; wat overblijft is technische context plus pseudonieme identificatoren.

Back-ups en herstel

• Geautomatiseerde dagelijkse back-ups van de database met een doorlopend bewaarvenster. Eerdere deployments blijven bewaard, zodat een slechte release snel kan worden teruggedraaid.

5. Organisatorische maatregelen

• Productiegegevens blijven op beheerde infrastructuur. Dumps van de productiedatabase worden niet op lokale machines bewaard; lokale ontwikkeling gebruikt een aparte database met synthetische gegevens.
• Minimale rechten voor serviceaccounts. Geprivilegieerde inloggegevens zijn uitsluitend bedoeld voor gebruik aan de serverzijde; databasetoegang vanuit de browser verloopt via een beperkte sleutel achter row-level security.
• Toegangslogging aan leverancierszijde. Beheerhandelingen bij onze leveranciers worden door die leveranciers gelogd en beoordeeld.
• Vertrouwelijkheid. Iedereen met toegang tot de productieomgeving is tot geheimhouding gebonden ten aanzien van persoonsgegevens die via de Dienst worden verwerkt, zoals vastgelegd in de DPA.

6. Reactie op incidenten (melding van datalekken binnen 72 uur)

Monitoring. Fouten en beveiligingsrelevante gebeurtenissen worden gemonitord, en het append-only auditlog levert een duurzame vastlegging voor onderzoek.

Onze toezegging over het melden van datalekken. Als zich een inbreuk in verband met persoonsgegevens voordoet die waarschijnlijk een risico oplevert voor de rechten en vrijheden van de betrokken personen, zullen wij:

• De bevoegde toezichthoudende autoriteit informeren — de voorzitter van UODO in Polen — zonder onnodige vertraging en, indien haalbaar, binnen 72 uur nadat we kennis hebben genomen van de inbreuk (artikel 33 AVG).
• *Wanneer de inbreuk waarschijnlijk een hoog* risico voor de betrokken personen oplevert, hen informeren zonder onnodige vertraging, met een beschrijving van de aard van de inbreuk, de betrokken gegevenscategorieën, de waarschijnlijke gevolgen en de genomen maatregelen (artikel 34 AVG**).
• Wanneer we als verwerker voor een manege optreden, die manege (de verwerkingsverantwoordelijke) zonder onnodige vertraging informeren, zodat zij haar eigen verplichtingen uit artikel 33/34 jegens haar ruiters kan nakomen.

Dit is in lijn met het Privacybeleid en de DPA. Het beschrijft hoe we een verplichting die de AVG al oplegt, uitvoeren — het is geen aanvullende contractuele toezegging bovenop de AVG.

Contact. Niet urgent: support@nose.horse. Beveiliging (urgent): mail support@nose.horse met `Security` in de onderwerpregel.

7. Wat we nog niet hebben

We hebben nog geen SOC 2 en geen ISO 27001, en we hebben nog geen externe penetratietest laten uitvoeren. We publiceren een certificering pas wanneer we die hebben, niet eerder. Als het inkoopproces van een geïnteresseerde manege vandaag een van deze zaken vereist, zijn wij op dit moment niet de juiste keuze — en dat zeggen we liever meteen dan dat we het gesprek laten slepen.

8. Compliance-kader

AVG (Verordening 2016/679). Nose opereert in een dubbele rol: verwerkingsverantwoordelijke voor de gegevens waarvan het de doeleinden en middelen bepaalt (bezoekers van de marketingsite, de account-/contactgegevens van manegebeheerders en instructeurs, de inlogidentiteit van iedere accounthouder ongeacht de rol, productanalyse, en gegevens voor beveiliging/misbruikpreventie), en verwerker voor de operationele ruiter-/klantgegevens die een manege invoert — daar is de manege de verwerkingsverantwoordelijke en verwerkt Nose op basis van de gedocumenteerde instructies van de manege onder de DPA (artikel 28 AVG). Subverwerkers werken onder overeenkomsten volgens artikel 28 (DPA + SCC's/DPF, het UK-addendum, of een gelijkwaardig mechanisme wanneer een doorgifte regio's overschrijdt) — zie de pagina Subverwerkers.

Gegevens van kinderen. Maneges geven regelmatig les aan kinderen, dus Nose verwerkt bewust gegevens van minderjarigen namens een manege (bijvoorbeeld een kind dat als deelnemer aan een les is ingevoerd, vaak door een ouder die klant is van de manege). De manege is verantwoordelijk voor de rechtsgrondslag en voor de toestemming of het gezag van een ouder die vereist kan zijn op grond van het recht dat op haar van toepassing is (artikel 8 AVG in de EU en het VK; COPPA en staatsrecht in de Verenigde Staten); Nose beperkt tot een minimum wat er over een kind wordt bewaard en richt zich niet rechtstreeks met marketing tot kinderen. Zie het Privacybeleid → “Privacy van kinderen”.

Rechten van betrokkenen worden ondersteund, waaronder selfservice-inzage/-overdraagbaarheid via een JSON-export op /account/export en verwijdering via /account/delete (daarbij gelden een omkeerbare respijtperiode van 30 dagen en step-up-herauthenticatie; bij verwijdering strippen we directe identificatoren in plaats van hard te verwijderen — pseudonimisering onder art. 4, lid 5, AVG, geen volledige anonimisering onder overweging 26; zie de bewaartabel in het Privacybeleid → “Hoe lang we gegevens bewaren” voor de details per veld). Voor ruitergegevens is de manege de verwerkingsverantwoordelijke, dus een ruiter oefent de rechten uit jegens de eigen manege en Nose helpt daarbij als verwerker; de uitzondering is de inlogidentiteit van een ruiter, waarvoor Nose de verwerkingsverantwoordelijke is, dus rechten daarop worden rechtstreeks bij Nose uitgeoefend.

PCI DSS — niet van toepassing op Nose. We verwerken, bewaren of versturen geen kaartgegevens. Bij de abonnementsfacturering van de manege loopt het pad van de kaartgegevens volledig via de betaalprovider op diens gehoste checkout — Stripe (betalingsverwerker) voor Poolse maneges, met Nose als verkoper, en Dodo Payments als Merchant of Record voor niet-Poolse maneges. Bij online betalingen door ruiters, waar een manege die inschakelt, worden de kaart-, wallet- of (in Polen) BLIK-gegevens volledig door Stripe (via Stripe Connect) gedragen en afgerekend op de eigen Stripe-rekening van de manege — de manege is de verkoper en Stripe is de PCI-conforme verwerker, terwijl Nose alleen instructies doorgeeft en nooit kaartgegevens ontvangt. In alle gevallen ontvangt Nose nooit kaartgegevens en blijft het buiten de reikwijdte van PCI.

EU-AI-verordening — niet van toepassing. Nose is een operationeel hulpmiddel voor maneges; het traint, ontwikkelt of gebruikt geen AI-modellen, en geen enkel onderdeel gebruikt machine learning of generatieve AI om persoonsgegevens te verwerken. Verandert dat, dan publiceren we vóór de functie live gaat een standpunt over de EU-AI-verordening en een toezegging dat er "geen training op persoonsgegevens" plaatsvindt.

ePrivacy / cookies. Optionele analyse wordt alleen na toestemming geladen (in de Verenigde Staten: totdat je die uitzet); strikt noodzakelijke cookies zijn vrijgesteld op grond van artikel 5, lid 3, van de ePrivacy-richtlijn. Zie het Cookiebeleid.

9. Verantwoorde openbaarmaking

Als je denkt dat je een beveiligingslek in Nose hebt gevonden:

• Mail [support@nose.horse](mailto:support@nose.horse) met `Security` in de onderwerpregel. (Een apart `security@`-adres en een PGP-sleutel staan gepland.)
• Voeg genoeg details toe om het probleem te kunnen reproduceren.
• Geef ons een redelijke termijn om te onderzoeken en te herstellen voordat je iets openbaar maakt.

Wat je van ons mag verwachten:

• Een bevestiging en een eerste beoordeling zodra dat redelijkerwijs mogelijk is; we laten een geloofwaardige melding niet onbeheerd liggen.
• Statusupdates met redelijke tussenpozen zolang het probleem wordt getrieerd of opgelost.
• Vermelding in een openbaarmaking na het herstel, als je dat wilt (optioneel). We bieden geen geldelijke beloning voor meldingen.

Reikwijdte en safe harbour. Beveiligingsonderzoek te goeder trouw dat dit beleid volgt, binnen je eigen accounts blijft, de Dienst voor anderen niet verstoort en geen andere gegevens dan je eigen gegevens raadpleegt, wordt niet behandeld als een schending van ons Beleid voor acceptabel gebruik of onze Servicevoorwaarden. Probeer niet toegang te krijgen tot de gegevens van een andere manege of een andere ruiter, en voer geen geautomatiseerde scraping of denial-of-service-tests uit tegen de Dienst.

10. Wijzigingslog