Beveiliging & vertrouwen

1. Samenvatting op één pagina

Onze eerlijke stand van zaken, per 2026-07-08: Nose for Horse (hierna “Nose”) is een product in een vroeg stadium dat door één persoon wordt geëxploiteerd. We hebben vandaag GEEN SOC 2 of ISO 27001, en er heeft nog geen externe penetratietest plaatsgevonden. Deze pagina beschrijft wat we doen, wat we bewaren en wat we nog niet hebben. We vertellen je liever ronduit waar we staan dan dat we het mooier maken dan het is.

• 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); met bcrypt gehashte rooster-pincodes; met SHA-256 gehashte uitnodigingstokens. We bewaren geen betaalkaart- of bankgegevens en geen gezondheidsgegevens. Volledig overzicht in “Gegevens die we bewaren” hieronder.
• Wat het beschermt. Overal TLS met HSTS-preload; versleuteling in rust (AES-256); door de database afgedwongen row-level security die elke manege isoleert; 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. Volledige lijst in “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, analyse achter toestemming — en een paar onderdelen draaien wereldwijd. De regio's en doorgiftemechanismen per leverancier, per dataregio, staan hieronder onder “Infrastructuur — wie draait wat, en waar” en op de pagina Subverwerkers.
• Wat we nog niet hebben. Geen SOC 2, geen ISO 27001, geen externe penetratietest en geen bug-bountyprogramma. Als jouw inkoopproces vandaag SOC 2 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. De `pgvector`-extensie staat aan in onze Postgres voor toekomstige interne zoektoepassingen, maar is vandaag niet gevuld met embeddings die van persoonsgegevens zijn afgeleid.

3. Infrastructuur — wie draait wat, en waar

Nose is een Next.js-applicatie die op Vercel wordt gehost, met daarachter een Supabase-Postgres-database en 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 achter toestemming. De tabel hieronder noemt de regio van elke leverancier per dataregio; de canonieke lijst — met per leverancier de categorieën persoonsgegevens en de doorgiftemechanismen — is de pagina Subverwerkers.

De canonieke, altijd actuele versie van deze tabel — met per leverancier de categorieën persoonsgegevens en de doorgiftemechanismen — wordt bijgehouden op de pagina Subverwerkers; het Privacybeleid en de DPA verwijzen naar dezelfde bron in plaats van uiteenlopende kopieën bij te houden.

4. Technische maatregelen

Dit zijn de 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, afgedwongen door Vercel en Supabase. HSTS is ingesteld met `max-age=63072000; includeSubDomains; preload`.
• Geen mixed content — het Content Security Policy weigert `http://`-bronnen.

Tenantisolatie en autorisatie

• Row-Level Security (RLS) 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 (ingelogd / manege-gebonden / instructeur-of-beheerder / superbeheerder) als defence-in-depth boven op RLS, nooit als enige linie.
• Controles op routeniveau vereisen een actieve sessie voor beschermde paden en superbeheerderstatus voor het beheerdersgedeelte.

Authenticatie

• Wachtwoordloos inloggen — e-mail-magic-link (afgehandeld door Supabase Auth) of optioneel Google-inloggen (OAuth). 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 kortlevende, apart ondertekende step-up-cookie is vereist voor bewerkingen zoals het verwijderen van een account, rolwijzigingen van de laatste beheerder, bulkdeactivering, het archiveren van een manege en alle schrijfacties van een superbeheerder; een ontbrekende of verlopen step-up faalt gesloten (fail closed).
• Het platformbeheerdersgedeelte geeft 404 terug wanneer er geen superbeheerder is geconfigureerd, zodat het bestaan ervan niet uitlekt.

Geheimen en omgang met inloggegevens

• Rooster-pincodes worden opgeslagen als bcrypt-hashes; uitnodigingstokens worden opgeslagen als SHA-256-hashes — eenmalig te gebruiken, in tijd beperkt (7 dagen geldig) en gebonden aan een e-mailadres; ruwe tokens worden nooit bewaard.
• De service-role-sleutel van de database is uitsluitend server-side — die wordt nooit meegebundeld in client-JavaScript; een validator tijdens de build laat de build mislukken als een gevoelige variabele een verkeerde prefix heeft.

Verwerking van invoer en uitvoer

• Schemavalidatie op elke server-invoergrens — validatie aan de clientzijde wordt uitsluitend als UX behandeld; de server is de vertrouwensgrens.
• Een strikt Content Security Policy met een nonce per verzoek, plus een dichtgetimmerde set beveiligingsheaders (`X-Content-Type-Options`, `X-Frame-Options` / `frame-ancestors`, `Referrer-Policy`, cross-origin-isolatieheaders en een restrictief `Permissions-Policy`).
• Automatische escaping van uitvoer; door gebruikers geschreven inhoud is in dit stadium platte tekst.

Misbruik- en botbescherming

• Rate limiting op inloggen, registreren, magic-link, het accepteren van een uitnodiging, export/verwijdering en andere gevoelige endpoints (per e-mailadres, per IP, per gebruiker of per manege, afhankelijk van de handeling; elk beleid is bij ontwerp fail-open of fail-closed).
• Cloudflare Turnstile-botbescherming op het inlogformulier, het registratieformulier, het magic-link-verzoek, de pagina om een uitnodiging te accepteren en de pincode-invoer van het openbare lesrooster.

Gegevens in rust en audittrail

• Versleuteling in rust via Supabase (AES-256).
• 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 — voordat een fout naar Sentry wordt gestuurd, verwijdert een eigen scrubber e-mailadressen, telefoonnummers, berichtteksten, notities en elk veld dat op een token lijkt. Wat overblijft is technische context plus een pseudonieme gebruikers-UUID, de identificator van de manege, de taal en de naam van de mislukte bewerking.

Back-ups en herstel

• Supabase levert geautomatiseerde dagelijkse back-ups (7 dagen bewaartermijn op het huidige niveau; een langere bewaartermijn is gepland naarmate de Dienst volwassener wordt). Vercel bewaart eerdere deployments voor een vrijwel directe rollback van een slechte release.

5. Organisatorische maatregelen

• Eenmansbedrijf. Nose wordt door één persoon gerund (Daniel Fojcik). Er zijn op dit moment geen werknemers met toegang tot de productieomgeving. Verandert dat — bijvoorbeeld doordat een opdrachtnemer met productietoegang wordt aangetrokken — dan wordt deze pagina bijgewerkt en worden actieve maneges geïnformeerd.
• 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. De service-role-sleutel van de database is uitsluitend bedoeld voor gebruik aan de serverzijde; databasetoegang vanuit de browser gebruikt een beperkte sleutel achter row-level security.
• Beheer van geheimen. Geheimen staan in de omgevingsconfiguratie van de hostingprovider en in een lokaal bestand dat buiten versiebeheer valt — ze worden nooit in de repository vastgelegd. Productiegeheimen worden niet naar lokale machines gekopieerd.
• Toegangslogging aan leverancierszijde. Beheerhandelingen bij onze leveranciers worden door die leveranciers gelogd; we bekijken ze op ad-hocbasis.
• Vertrouwelijkheid. Personeel (op dit moment de eigenaar) is tot geheimhouding gebonden ten aanzien van persoonsgegevens die via de Dienst worden verwerkt, zoals vastgelegd in de DPA.
• Wijzigingsdiscipline. Codewijzigingen doorlopen vóór de deploy een strikte type-, lint- en geautomatiseerde-testpoort, en databasemigraties worden vóór productie toegepast op een stagingomgeving.

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

Monitoring. Fouten stromen naar Sentry (met het wegfilteren van persoonsgegevens zoals beschreven in “Technische maatregelen” hierboven); diagnostiek op verzoekniveau is beschikbaar in de hostinglogs; een uptime-monitor en alerting op foutpercentages horen bij de hardening-basislijn. Het append-only auditlog levert een duurzame vastlegging van beveiligingsrelevante gebeurtenissen 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, willen uitvoeren — het is geen aanvullende contractuele toezegging bovenop de AVG. Een formeel gedocumenteerd incident-response-runbook staat op de roadmap; tot die tijd reageert een eenpersoonsteam ad hoc binnen de bovenstaande termijnen.

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

7. 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, productanalyse die van toestemming afhangt, 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.

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. De Postgres-extensie `pgvector` staat aan voor mogelijke toekomstige interne zoektoepassingen, maar is vandaag niet gevuld met embeddings die van persoonsgegevens zijn afgeleid; 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 (PostHog) wordt alleen na toestemming geladen; strikt noodzakelijke cookies zijn vrijgesteld op grond van artikel 5, lid 3, van de ePrivacy-richtlijn. Zie het Cookiebeleid.

8. 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. Nose is een dienst die door één persoon wordt gerund en kan geen antwoord op dezelfde dag garanderen; 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).

Wat we nog niet kunnen bieden: we betalen in dit stadium geen geldelijke bug bounties. We zullen het duidelijk zeggen als en wanneer er een bounty-programma komt.

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.

9. Wijzigingslog