Sikkerhet og tillit

1. Sammendrag på én side

Vår ærlige nåværende status per 2026-07-08: Nose for Horse («Nose») er et produkt i tidlig fase som drives av én enkelt person. Vi har IKKE SOC 2 eller ISO 27001 i dag, og vi har ennå ikke fått utført en ekstern penetrasjonstest. Denne siden beskriver hva vi gjør, hva vi oppbevarer, og hva vi ennå ikke har. Vi vil heller fortelle deg rett ut hvor vi står, enn å overdrive.

• Hvem vi er. Nose er programvare for å drive en rideskole — planlegge ridetimer, registrere oppmøte og hvordan ryttere har betalt, administrere klippekort og gavekort, beregne instruktørenes inntekter og gi en stalls kunder innsyn i sine egne bestillinger. Nose drives av DF Daniel Fojcik, et polsk enkeltpersonforetak (NIP 6472592229 / REGON 387798601, Marklowice), under navnet Nose for Horse.
• Våre to roller. Vi er behandlingsansvarlig for våre egne konto-, analyse- og sikkerhetsdata, og databehandler som handler etter hver stalls instrukser for rytter-/kundedataene den stallen legger inn. Databehandlerforholdet reguleres av vår databehandleravtale. Se «Etterlevelse av regelverk» nedenfor.
• Hva vi oppbevarer. E-postadressen for kontoen og valgfritt profilnavn/telefonnummer; e-postadresser i invitasjoner; driftsoppføringene en stall legger inn om rytterne sine (navn, kontaktopplysninger, deltakelse i ridetimer, klippekort/gavekort, merkelapper for registrering av betaling, fritekstnotater); PIN-koder for timeplanen hashet med bcrypt; invitasjonstokener hashet med SHA-256. Vi oppbevarer ingen betalingskort- eller bankdata og ingen helsedata. Fullstendig oversikt under «Data vi oppbevarer» nedenfor.
• Hva som beskytter dem. TLS overalt med HSTS preload; kryptering av lagrede data (AES-256); radnivåsikkerhet håndhevet av databasen, som isolerer hver stall; validering av økter på serversiden; ny autentisering (step-up) for destruktive handlinger og administratorhandlinger; en streng Content Security Policy; hastighetsbegrensning og beskyttelse mot roboter; og en revisjonslogg der oppføringer bare kan legges til (append-only). Fullstendig liste under «Tekniske tiltak» nedenfor.
• Hvor det kjører. I mer enn én dataregion, og vi legger til regioner etter hvert som vi vokser. Kundedata for staller i US-regionen lagres i USA. Drift, administrasjon og brukerstøtte for tjenesten skjer fra Den europeiske union. Staller i EU-regionen vår betjenes fra EØS. Noen få tjenester deles av begge regionene og kjører i EØS — transaksjonell e-post, feilovervåking og analyse som krever samtykke — og noen få komponenter kjører globalt. Regioner og overføringsmekanismer for hver leverandør, per dataregion, står under «Infrastruktur — hvem som drifter hva, og hvor» nedenfor og på siden Underdatabehandlere.
• Hva vi ennå ikke har. Ingen SOC 2, ISO 27001, ekstern penetrasjonstest eller bug bounty-program. Hvis innkjøpsprosessen din krever SOC 2 i dag, er vi ennå ikke det rette valget.
• Slik kontakter du oss om sikkerhet. Send e-post til support@nose.horse med `Security` i emnefeltet. Se «Hendelseshåndtering (varsling av brudd innen 72 timer)» og «Ansvarlig avsløring av sårbarheter» nedenfor.

2. Data vi oppbevarer

Vi samler inn det minimum som trengs for å drive Tjenesten. Kategoriene nedenfor er de personopplysningene som kommer i berøring med Nose.

Der det i en rad står regionen til stallen din, betyr det EU-regionen eller US-regionen — fastsatt da stallen ble opprettet, og beskrevet nærmere under «Infrastruktur — hvem som drifter hva, og hvor» nedenfor.

Hva vi ikke oppbevarer

• Ingen betalingskort- eller bankdata. Nose er aldri part i en betaling og håndterer aldri kortdata. Betalingsmåter utenfor nett («kontant», «klippekort», «gavekort», «bankoverføring») er merkelapper for registrering som en stall fører — ikke transaksjoner Nose gjennomfører. For stallens abonnementsfakturering (Stripe for polske staller, Dodo Payments som Merchant of Record for ikke-polske staller) og for nettbetalinger fra ryttere der en stall aktiverer dem (Stripe, med oppgjør til stallens egen konto), håndteres kortdataene utelukkende i betalingsleverandørens egen betalingsløsning og når aldri oss — derfor forblir vi utenfor virkeområdet for PCI DSS (se «Etterlevelse av regelverk» nedenfor).
• Ingen identitetsdokumenter eller adresser. Vi samler ikke inn hjemmeadresser, ID-dokumentnumre eller offentlige identifikatorer.
• Ingen særlige kategorier av personopplysninger (helsedata). Vi har ikke til hensikt å samle inn opplysninger etter artikkel 9 i GDPR, og produktet er ikke utformet for å lagre dem. Staller er instruert (i databehandleravtalen) om ikke å legge inn særlige kategorier av personopplysninger i fritekstfelt. Notater om en hest gjelder et dyr, ikke en person, og faller utenfor GDPR.
• Ingen annonseprofiler, identifikatorer for retargeting eller sporing på tvers av nettsteder. Ingen Meta-/LinkedIn-/X-/TikTok-piksler; ingen fingeravtrykk av nettlesere.
• Ingen data selges, leies ut eller lånes ut til tredjeparter.
• Ingen trening av KI-/ML-modeller på dataene dine. Vi verken trener, finjusterer eller evaluerer noen KI- eller maskinlæringsmodell på personopplysninger hentet fra Nose. Utvidelsen `pgvector` er aktivert i Postgres-databasen vår for fremtidige interne søkebruksområder, men inneholder i dag ingen embeddings avledet fra personopplysninger.

3. Infrastruktur — hvem som drifter hva, og hvor

Nose er en Next.js-applikasjon som hostes hos Vercel, med en Supabase Postgres-database i bunnen og et lite sett spesialiserte leverandører («underdatabehandlere») som hver håndterer en smal del. Ingen av dem har ende-til-ende-tilgang til alt. Nose har to dataregioner: en EU-region og en US-region. Kundedata for staller i US-regionen lagres i USA. Drift, administrasjon og brukerstøtte for tjenesten skjer fra Den europeiske union. En stalls driftsdata ligger bare i databasen i stallens egen region — det finnes ingen replikering mellom regionene og ingen applikasjonsvei som leser på tvers av dem. Tre tjenester deles av begge regionene og blir værende i EØS — transaksjonell e-post, feilovervåking og produktanalyse som krever samtykke. Tabellen nedenfor viser hver leverandørs region per dataregion; den kanoniske listen, med datakategorier og overføringsmekanismer, er siden Underdatabehandlere.

Den kanoniske, alltid oppdaterte versjonen av denne tabellen — med kategorier av personopplysninger og overføringsmekanismer for hver leverandør — vedlikeholdes på siden Underdatabehandlere; personvernerklæringen og databehandleravtalen lenker til den samme kilden i stedet for å ha avvikende kopier.

4. Tekniske tiltak

Dette er kontrollene som faktisk er på plass i dag. Dette er også innholdet bak Databehandleravtale → «Konfidensialitet, sikkerhet og underdatabehandlere», som viser hit for våre tekniske og organisatoriske tiltak.

Nettverk og overføring

• TLS for all trafikk, håndhevet av Vercel og Supabase. HSTS er satt med `max-age=63072000; includeSubDomains; preload`.
• Ikke noe blandet innhold — ressurser over `http://` avvises av Content Security Policy.

Tenant-isolasjon og autorisasjon

• Radnivåsikkerhet (Row-Level Security, RLS) avgrenset til hver stall på hver driftstabell, håndhevet i selve databasen — én stalls data kan ikke leses av en annen, selv om applikasjonskoden skulle ha en feil. Dette er det primære forsvaret på tvers av tenanter.
• Rollekontroller i applikasjonslaget (autentisert / avgrenset til stall / instruktør eller administrator / superadministrator) som ekstra forsvarslag (defence-in-depth) oppå RLS, aldri som den eneste forsvarslinjen.
• Kontroller i rutelaget krever en aktiv økt for beskyttede stier og superadministratorstatus for administrasjonsflaten.

Autentisering

• Innlogging uten passord — innloggingslenke på e-post (håndtert av Supabase Auth) eller valgfri innlogging med Google eller «Logg på med Apple» (OAuth). Ingen passord lagres.
• Validering av økten på serversiden ved hver beskyttet forespørsel — man stoler aldri på informasjonskapselen for innlogging alene.
• Ny autentisering (step-up) for destruktive og administrative handlinger — en kortvarig, separat signert step-up-informasjonskapsel kreves for operasjoner som sletting av konto, rolleendringer som berører den siste administratoren, massedeaktivering, arkivering av stall og alle skriveoperasjoner som superadministrator; manglende eller utløpt step-up gir avvisning (fail-closed).
• Administrasjonsflaten for plattformen returnerer 404 når ingen superadministrator er konfigurert, slik at det ikke avsløres at den finnes.

Håndtering av hemmeligheter og påloggingsopplysninger

• PIN-koder for timeplanen lagres som bcrypt-hasher; invitasjonstokener lagres som SHA-256-hasher — til engangsbruk, tidsbegrensede (utløper etter 7 dager) og knyttet til en e-postadresse; rå tokener lagres aldri.
• Databasens service-role-nøkkel finnes bare på serveren — den pakkes aldri inn i JavaScript på klientsiden; en validator ved bygging får byggingen til å feile hvis en sensitiv variabel har feil prefiks.

Håndtering av inndata og utdata

• Skjemavalidering ved hver inndatagrense på serveren — validering på klientsiden regnes bare som brukeropplevelse (UX); serveren er tillitsgrensen.
• En streng Content Security Policy med en nonce per forespørsel, pluss et låst sett med sikkerhetshoder (`X-Content-Type-Options`, `X-Frame-Options` / `frame-ancestors`, `Referrer-Policy`, hoder for cross-origin-isolasjon og en restriktiv `Permissions-Policy`).
• Automatisk escaping av utdata; brukerskrevet innhold er ren tekst på dette stadiet.

Beskyttelse mot misbruk og robottrafikk

• Hastighetsbegrensning på innlogging, registrering, innloggingslenker, godtakelse av invitasjoner, eksport/sletting og andre sensitive endepunkter (per e-postadresse, per IP, per bruker eller per stall avhengig av handlingen; hver regel er fail-open eller fail-closed etter bevisst valg).
• Cloudflare Turnstile-robotbeskyttelse på innloggingsskjemaet, registreringsskjemaet, forespørselen om innloggingslenke, siden for å godta invitasjoner og inntastingen av PIN-kode for den offentlige timeplanen.

Lagrede data og revisjonsspor

• Kryptering av lagrede data via Supabase (AES-256).
• En revisjonslogg der oppføringer bare kan legges til (append-only) registrerer sikkerhetsrelevante hendelser (autentisering, endringer i roller og medlemskap, økonomiske hendelser, eksporter, slettinger). Den skrives alltid og er atskilt fra driftstelemetri.
• Feilovervåking med fjerning av personopplysninger — før en feil sendes til Sentry, fjerner et egenutviklet filter e-postadresser, telefonnumre, meldingstekster, notater og ethvert felt som ligner et token. Det som gjenstår, er teknisk kontekst pluss en pseudonym bruker-UUID, stallidentifikatoren, språkinnstillingen og navnet på operasjonen som feilet.

Sikkerhetskopier og gjenoppretting

• Supabase leverer automatiske daglige sikkerhetskopier (7 dagers lagringstid på gjeldende nivå; lengre lagringstid er planlagt etter hvert som Tjenesten modnes). Vercel beholder tidligere utrullinger for nesten umiddelbar tilbakerulling av en feilaktig versjon.

5. Organisatoriske tiltak

• Drevet av én person. Nose drives av én person (Daniel Fojcik). Det finnes for øyeblikket ingen ansatte med tilgang til produksjonsmiljøet. Hvis dette endres — for eksempel hvis en oppdragstaker med produksjonstilgang tas inn — vil denne siden bli oppdatert og aktive staller varslet.
• Produksjonsdata blir på administrert infrastruktur. Dumper av produksjonsdatabasen lagres ikke på lokale maskiner; lokal utvikling bruker en separat database med syntetiske data.
• Minste privilegium for tjenestekontoer. Databasens service-role-nøkkel er begrenset til bruk på serversiden; databasetilgang fra nettleseren bruker en begrenset nøkkel bak radnivåsikkerhet.
• Håndtering av hemmeligheter. Hemmeligheter ligger i hostingleverandørens miljøkonfigurasjon og i en lokal fil som er utelatt fra git (gitignore) — de sjekkes aldri inn i kodelageret. Produksjonshemmeligheter kopieres ikke til lokale maskiner.
• Tilgangslogging hos leverandørene. Administrative handlinger hos leverandørene våre logges av disse leverandørene; vi gjennomgår loggene ad hoc.
• Konfidensialitet. Personell (for tiden innehaveren) er bundet av konfidensialitetsplikt når det gjelder personopplysninger som behandles gjennom Tjenesten, slik det fremgår av databehandleravtalen.
• Endringsdisiplin. Kodeendringer må passere en streng kontroll med typesjekk, linting og automatiserte tester før utrulling, og databasemigreringer tas i bruk i et stagingmiljø før produksjon.

6. Hendelseshåndtering (varsling av brudd innen 72 timer)

Overvåking. Feil sendes til Sentry (med fjerningen av personopplysninger beskrevet under «Tekniske tiltak» ovenfor); diagnostikk på forespørselsnivå er tilgjengelig i hostingloggene; en overvåker for oppetid og varsling basert på feilrate er en del av grunnlinjen for sikkerhetsherding. Revisjonsloggen, der oppføringer bare kan legges til, gir en varig registrering av sikkerhetsrelevante hendelser for etterforskning.

Vår forpliktelse til å varsle om brudd. Hvis det oppstår et brudd på personopplysningssikkerheten som sannsynligvis vil medføre en risiko for de berørte personenes rettigheter og friheter, vil vi:

• Varsle den kompetente tilsynsmyndigheten — presidenten for UODO i Polen — uten ugrunnet opphold og, når det er mulig, innen 72 timer etter at vi ble kjent med bruddet (artikkel 33 i GDPR).
• *Der bruddet sannsynligvis vil medføre en høy* risiko for de berørte personene, varsle dem uten ugrunnet opphold, med en beskrivelse av bruddets art, de berørte kategoriene av opplysninger, de sannsynlige konsekvensene og tiltakene som er truffet (artikkel 34 i GDPR**).
• Der vi opptrer som databehandler for en stall, varsle den stallen (den behandlingsansvarlige) uten ugrunnet opphold, slik at den kan oppfylle sine egne forpliktelser etter artikkel 33/34 overfor rytterne sine.

Dette tilsvarer personvernerklæringen og databehandleravtalen. Det beskriver hvordan vi har til hensikt å oppfylle en forpliktelse GDPR allerede pålegger — det er ikke et ytterligere kontraktsløfte utover GDPR. En formelt dokumentert rutine for hendelseshåndtering står på veikartet; inntil da reagerer et team på én person ad hoc innenfor tidsfristene ovenfor.

Kontakt. Ikke hastesaker: support@nose.horse. Sikkerhet (hastesaker): send e-post til support@nose.horse med `Security` i emnefeltet.

7. Etterlevelse av regelverk

GDPR (forordning 2016/679). Nose opererer i en dobbel rolle: behandlingsansvarlig for dataene der Nose bestemmer formål og midler (besøkende på markedsføringsnettstedet, konto- og kontaktdata for stallenes administratorer og instruktører, innloggingsidentiteten til hver kontoinnehaver uansett rolle, produktanalyse som krever samtykke, og data for sikkerhet og forebygging av misbruk), og databehandler for rytter-/kundedriftsdataene en stall legger inn — der er stallen behandlingsansvarlig, og Nose behandler dataene etter stallens dokumenterte instrukser i henhold til databehandleravtalen (artikkel 28 i GDPR). Underdatabehandlere opererer under avtaler etter artikkel 28 (databehandleravtale + SCCs/DPF, UK Addendum eller en tilsvarende mekanisme der en overføring krysser regioner) — se siden Underdatabehandlere.

Barns data. Rideskoler underviser jevnlig barn, så Nose behandler bevisst mindreåriges data på vegne av en stall (for eksempel et barn som er registrert som deltaker i en ridetime, ofte av en forelder som er stallens kunde). Stallen er ansvarlig for det rettslige grunnlaget og for eventuelt foreldresamtykke eller foreldrefullmakt som kreves etter lovgivningen som gjelder for den (artikkel 8 i GDPR i EU og Storbritannia; COPPA og delstatslovgivning i USA); Nose minimerer det som lagres om et barn, og verken retter seg direkte mot eller markedsfører direkte til barn. Se Personvernerklæring → «Barns personvern».

Rettighetene til de registrerte støttes, inkludert selvbetjent innsyn/dataportabilitet via en JSON-eksport på /account/export og sletting via /account/delete (det gjelder en gjenopprettingsperiode på 30 dager der slettingen kan omgjøres, og det kreves ny autentisering (step-up); ved sletting fjerner vi direkte identifikatorer i stedet for å slette permanent — pseudonymisering etter GDPR art. 4 nr. 5, ikke full anonymisering etter fortalepunkt 26; se lagringstabellen i Personvernerklæring → «Hvor lenge vi lagrer data» for detaljer på feltnivå). For rytterdata er stallen behandlingsansvarlig, så en rytter utøver rettighetene sine overfor stallen sin, og Nose bistår som databehandler; unntaket er rytterens innloggingsidentitet, der Nose er behandlingsansvarlig, så rettighetene knyttet til den utøves direkte overfor Nose.

PCI DSS — gjelder ikke for Nose. Vi verken håndterer, lagrer eller overfører kortdata. For stallens abonnementsfakturering håndteres kortdataene utelukkende av betalingsleverandøren i dens hostede betalingsløsning — Stripe (betalingsbehandler) for polske staller, med Nose som selger, og Dodo Payments som Merchant of Record for ikke-polske staller. For nettbetalinger fra ryttere, der en stall aktiverer dem, håndteres kort-, mobillommebok- eller (i Polen) BLIK-dataene utelukkende av Stripe (via Stripe Connect), og oppgjøret går til stallens egen Stripe-konto — stallen er selgeren, og Stripe er den PCI-kompatible betalingsbehandleren, mens Nose bare formidler instrukser og aldri mottar kortdata. I alle tilfeller mottar Nose aldri kortdata og forblir utenfor PCI-virkeområdet.

EUs KI-forordning (EU AI Act) — gjelder ikke. Nose er et driftsverktøy for rideskoler; det verken trener, utvikler eller tar i bruk KI-modeller, og ingen komponent bruker maskinlæring eller generativ KI til å behandle personopplysninger. Postgres-utvidelsen `pgvector` er aktivert for mulige fremtidige interne søkebruksområder, men inneholder i dag ingen embeddings avledet fra personopplysninger; hvis det endres, vil vi publisere et standpunkt til EUs KI-forordning og en forpliktelse om «ingen trening på personopplysninger» før funksjonen lanseres.

ePrivacy / informasjonskapsler. Valgfri analyse (PostHog) lastes bare med samtykke; strengt nødvendige informasjonskapsler er unntatt etter artikkel 5 nr. 3 i ePrivacy-direktivet. Se Retningslinjer for informasjonskapsler.

8. Ansvarlig avsløring av sårbarheter

Hvis du mener at du har funnet en sikkerhetssårbarhet i Nose:

• Send e-post til [support@nose.horse](mailto:support@nose.horse) med `Security` i emnefeltet. (En egen `security@`-adresse og en PGP-nøkkel er planlagt.)
• Ta med nok detaljer til at problemet kan reproduseres.
• Gi oss en rimelig frist til å undersøke og utbedre problemet før det skjer noen offentliggjøring.

Hva du kan forvente av oss:

• En bekreftelse på mottak og en første vurdering så snart det er rimelig praktisk mulig. Nose er en tjeneste som drives av én person, og kan ikke garantere svar samme dag; vi vil ikke la en troverdig rapport bli liggende uten oppfølging.
• Statusoppdateringer med rimelige mellomrom mens problemet vurderes eller utbedres.
• Kreditering i en eventuell offentliggjøring etter utbedringen, hvis du ønsker det (valgfritt).

Hva vi ennå ikke kan tilby: vi betaler ikke pengebelønning for sårbarheter (bug bounty) på dette stadiet. Vi vil si tydelig fra dersom og når et belønningsprogram blir tilgjengelig.

Omfang og trygg havn (safe harbour). Sikkerhetsforskning i god tro som følger denne policyen, holder seg innenfor dine egne kontoer, unngår å forringe Tjenesten for andre og ikke innebærer tilgang til andre data enn dine egne, vil ikke bli behandlet som et brudd på våre Retningslinjer for akseptabel bruk eller Brukervilkår. Ikke forsøk å skaffe deg tilgang til en annen stalls eller en annen rytters data, og ikke kjør automatisert skraping eller tester av tjenestenekt (denial of service) mot Tjenesten.

9. Endringslogg