Sicurezza e fiducia

1. Riepilogo di una pagina

Il nostro onesto stato attuale, al 2026-07-08: Nose for Horse (di seguito “Nose”) è un prodotto in fase iniziale gestito da una sola persona. Oggi NON disponiamo della certificazione SOC 2 o ISO 27001 e non abbiamo ancora effettuato un test di penetrazione esterno. Questa pagina descrive cosa facciamo, cosa abbiamo e cosa non abbiamo ancora. Preferiamo dirti chiaramente la nostra posizione piuttosto che esagerarla.

• Chi siamo. Nose è un software per la gestione di una scuola di equitazione: programmazione delle lezioni, monitoraggio delle presenze e delle modalità di pagamento dei cavalieri, gestione di pacchetti lezioni e buoni regalo, calcolo dei guadagni degli istruttori e possibilità, per i clienti di un maneggio, di vedere le proprie prenotazioni. È gestito da DF Daniel Fojcik, una ditta individuale polacca (NIP 6472592229 / REGON 387798601, Marklowice), che opera con il nome commerciale Nose for Horse.
• I nostri due ruoli. Siamo il titolare del trattamento per i nostri dati di account, analisi e sicurezza e un responsabile del trattamento che agisce in base alle istruzioni di ciascun maneggio per i dati del cavaliere/cliente immessi dal maneggio. Il rapporto in qualità di responsabile del trattamento è regolato dal nostro Accordo sul trattamento dei dati (DPA). Vedi la sezione “Inquadramento della conformità” di seguito.
• Cosa conserviamo. E-mail dell'account e nome/telefono del profilo opzionale; indirizzi email di invito; i registri operativi che un maneggio inserisce sui propri cavalieri (nomi, contatti, partecipazione alle lezioni, pacchetti lezioni/buoni regalo, etichette per il tracciamento dei pagamenti, note di testo libero); PIN del calendario sottoposti ad hash bcrypt; token di invito sottoposti ad hash SHA-256. Non conserviamo dati bancari o di carte di pagamento e nemmeno dati sanitari. Inventario completo nella sezione "Dati in nostro possesso" di seguito.
• Cosa lo protegge. TLS ovunque con preload HSTS; crittografia a riposo (AES-256); sicurezza a livello di riga applicata dal database che isola ogni maneggio; convalida della sessione lato server; riautenticazione rafforzata (step-up) per azioni distruttive e amministrative; una rigorosa Content Security Policy; rate limiting e protezione dai bot; e un registro di controllo di sola aggiunta. Elenco completo nella sezione "Misure tecniche" di seguito.
• Dove viene eseguito. Su più di una regione di dati, e aggiungiamo regioni man mano che cresciamo. I dati dei clienti dei maneggi nella regione USA sono archiviati negli Stati Uniti. Il Servizio è gestito, amministrato e supportato dall'interno dell'Unione europea. I maneggi nella nostra regione UE sono serviti dal SEE. Alcuni servizi sono condivisi da entrambe le regioni e sono eseguiti nel SEE — e-mail transazionali, monitoraggio degli errori, analisi basate sul consenso — e alcuni componenti sono eseguiti a livello globale. Le regioni e i meccanismi di trasferimento dei singoli fornitori, per ciascuna regione di dati, si trovano in "Infrastruttura: chi gestisce cosa e dove" di seguito e nella pagina Sub-responsabili del trattamento.
• Ciò che non abbiamo ancora. Nessun SOC 2, ISO 27001, test di penetrazione esterna o programma bug-bounty. Se oggi il tuo processo di approvvigionamento richiede SOC 2, non siamo ancora la soluzione giusta.
• Come contattarci in merito alla sicurezza. Invia un'e-mail a support@nose.horse con `Security` nella riga dell'oggetto. Vedi “Risposta all'incidente (notifica di violazione entro 72 ore)” e “Divulgazione responsabile” di seguito.

2. Dati in nostro possesso

Raccogliamo il minimo necessario per eseguire il Servizio. Le categorie seguenti sono i dati personali che toccano Nose.

Dove una riga indica la regione del tuo maneggio, si tratta della regione UE o della regione USA — stabilita al momento della creazione del maneggio e descritta in "Infrastruttura: chi gestisce cosa e dove" di seguito.

Ciò che non conserviamo

• Nessun dato di carte di pagamento o bancario. Nose non è mai parte di un pagamento e non gestisce mai i dati della carta. I metodi offline ("contanti", "pacchetto", "buono regalo", "bonifico") sono etichette di tracciamento registrate da un maneggio — non transazioni eseguite da Nose. Per la fatturazione dell'abbonamento del maneggio (Stripe per i maneggi polacchi, Dodo Payments come Merchant of Record per i maneggi non polacchi) e per i pagamenti online dei cavalieri, quando un maneggio li attiva (Stripe, con liquidazione sull'account proprio del maneggio), i dati della carta vengono gestiti interamente sul checkout del fornitore di servizi di pagamento e non ci raggiungono mai — quindi rimaniamo fuori dall'ambito PCI DSS (vedi “Inquadramento della conformità” di seguito).
• Nessun documento d'identità o indirizzo. Non raccogliamo indirizzi di casa, numeri di documenti d'identità o identificatori governativi.
• Nessun dato di categorie speciali (salute). Non intendiamo raccogliere dati ai sensi dell'articolo 9 GDPR e il prodotto non è progettato per memorizzarli. Ai maneggi viene richiesto (nel DPA) di non inserire dati di categorie speciali nei campi di testo libero. Le note su un cavallo riguardano un animale, non una persona, e non rientrano nell'ambito del GDPR.
• Nessun profilo pubblicitario, identificatore di retargeting o tracciamento tra siti. Nessun pixel Meta/LinkedIn/X/TikTok; nessun fingerprinting del browser.
• Nessun dato venduto, affittato o prestato a terzi.
• Nessun addestramento dei modelli AI/ML sui tuoi dati. Non addestriamo, perfezioniamo o valutiamo alcun modello di intelligenza artificiale o di apprendimento automatico sui dati personali estratti da Nose. L'estensione `pgvector` è abilitata nel nostro Postgres per futuri casi d'uso di ricerca interna ma, oggi, non è popolata con alcun embedding derivato da dati personali.

3. Infrastruttura: chi gestisce cosa e dove

Nose è un'applicazione Next.js ospitata su Vercel, supportata da un database Postgres Supabase, con un piccolo insieme di provider specializzati ("sub-responsabili del trattamento"), ciascuno dei quali gestisce una fetta ristretta. Nessuno ha accesso end-to-end a tutto. Nose opera in due regioni di dati: una regione UE e una regione USA. I dati dei clienti dei maneggi nella regione USA sono archiviati negli Stati Uniti. Il Servizio è gestito, amministrato e supportato dall'interno dell'Unione europea. I dati operativi di un maneggio si trovano esclusivamente nel database della sua stessa regione — non c'è replica tra le regioni né alcun percorso applicativo che legga dall'una all'altra. Tre servizi sono condivisi da entrambe le regioni e restano nel SEE — e-mail transazionali, monitoraggio degli errori e analisi del prodotto basate sul consenso. La tabella qui sotto indica la regione di ciascun fornitore per ciascuna regione di dati; l'elenco canonico, con le categorie di dati e i meccanismi di trasferimento, è la pagina Sub-responsabili del trattamento.

La versione canonica e sempre aggiornata di questa tabella, con le categorie di dati personali per fornitore e i meccanismi di trasferimento, è mantenuta nella pagina Sub-responsabili del trattamento; l'Informativa sulla privacy e il DPA si collegano alla stessa fonte anziché conservare copie divergenti.

4. Misure tecniche

Questi sono i controlli effettivamente in atto oggi. Questa è anche la sostanza alla base del DPA → "Riservatezza, sicurezza e sub-responsabili del trattamento", che indica qui le nostre misure tecniche e organizzative.

Rete e trasporto

• TLS per tutto il traffico, applicato da Vercel e Supabase. HSTS è impostato con `max-age=63072000; includeSubDomains; preload`.
• Nessun contenuto misto: la Content Security Policy rifiuta le risorse `http://`.

Isolamento e autorizzazione del tenant

• Sicurezza a livello di riga (RLS) limitata a ciascun maneggio su ogni tabella operativa, applicata nel database stesso: i dati di un maneggio non possono essere letti da un altro anche se il codice dell'applicazione presenta un bug. Questa è la principale difesa tra tenant.
• Controlli di ruolo a livello applicativo (autenticati/con ambito maneggio/istruttore o amministratore/super amministratore) come difesa in profondità sopra RLS, mai come unica linea.
• I controlli a livello di percorso richiedono una sessione attiva per i percorsi protetti e lo stato di super amministratore per la superficie di amministrazione.

Autenticazione

• Accesso senza password: link magico via e-mail (gestito da Supabase Auth) o accesso Google opzionale (OAuth). Nessuna password viene memorizzata.
• Convalida della sessione lato server su ogni richiesta protetta: il solo cookie di accesso non è mai considerato attendibile.
• Riautenticazione step-up per azioni distruttive e amministrative: è richiesto un cookie step-up di breve durata e firmato separatamente per operazioni quali l'eliminazione dell'account, le modifiche al ruolo dell'ultimo amministratore, la disattivazione collettiva, l'archiviazione maneggio e tutte le scritture dei super amministratori; in assenza di step-up, o se è scaduto, l'operazione viene rifiutata (fail-closed).
• La superficie di amministrazione della piattaforma restituisce 404 quando non è configurato alcun super amministratore, quindi non ne viene rivelata l'esistenza.

Segreti e gestione delle credenziali

• I PIN del calendario vengono archiviati come hash bcrypt; i token di invito vengono archiviati come hash SHA-256: monouso, limitati nel tempo (scadenza di 7 giorni) e vincolati a un indirizzo e-mail; i token grezzi non vengono mai conservati.
• La chiave service-role del database è riservata al server: non viene mai inclusa nel JavaScript del client; un validatore in fase di build fa fallire la build se una variabile sensibile ha un prefisso errato.

Gestione degli input e degli output

• Convalida dello schema a ogni limite di input del server: la convalida lato client viene trattata solo come UX; il server è il confine di fiducia.
• Una rigorosa Content Security Policy con un nonce per richiesta, oltre a un set restrittivo di intestazioni di sicurezza (`X-Content-Type-Options`, `X-Frame-Options` / `frame-ancestors`, `Referrer-Policy`, intestazioni di isolamento multiorigine e una `Permissions-Policy` restrittiva).
• Escaping automatico dell'output; in questa fase il contenuto creato dall'utente è testo semplice.

Protezione da abusi e bot

• Rate limiting su accesso, registrazione, link magico, accettazione invito, esportazione/cancellazione e altri endpoint sensibili (per e-mail, per IP, per utente o per maneggio a seconda dell'azione; ogni policy è di tipo fail-open o fail-closed per progettazione).
• Cloudflare Turnstile protezione dai bot nel modulo di accesso, nel modulo di iscrizione, nella richiesta di link magico, nella pagina di accettazione dell'invito e nell'immissione del PIN del calendario pubblico.

Dati a riposo e traccia di audit

• Crittografia a riposo tramite Supabase (AES-256).
• Un registro di controllo di sola aggiunta registra eventi rilevanti per la sicurezza (autenticazione, modifiche di ruolo e appartenenza, eventi finanziari, esportazioni, eliminazioni). È sempre scritto ed è distinto dalla telemetria operativa.
• Monitoraggio degli errori con la pulizia dei dati personali: prima che qualsiasi errore venga inviato a Sentry, uno scrubber personalizzato elimina indirizzi email, numeri di telefono, corpi dei messaggi, note e qualsiasi campo che assomigli a un token. Ciò che rimane è il contesto tecnico più un UUID utente pseudonimo, l'identificatore del maneggio, le impostazioni locali e il nome dell'operazione non riuscita.

Backup e ripristino

• Supabase fornisce backup giornalieri automatizzati (conservazione di 7 giorni al livello attuale; è prevista una conservazione più lunga man mano che il Servizio matura). Vercel conserva i deployment precedenti per il rollback quasi istantaneo di una release difettosa.

5. Misure organizzative

• Operatore singolo. Nose è gestito da una persona (Daniel Fojcik). Al momento non sono presenti dipendenti con accesso alla produzione. Se ciò cambia, ad esempio se viene coinvolto un collaboratore esterno con accesso alla produzione, questa pagina verrà aggiornata e i maneggi attivi verranno informati.
• I dati di produzione rimangono sull'infrastruttura gestita. I dump del database di produzione non vengono archiviati sulle macchine locali; lo sviluppo locale utilizza un database separato con dati sintetici.
• Privilegio minimo per gli account di servizio. La chiave service-role del database è limitata al solo utilizzo lato server; l'accesso al database dal browser utilizza una chiave limitata, protetta dalla sicurezza a livello di riga.
• Gestione dei segreti. I segreti risiedono nella configurazione dell'ambiente del provider di hosting e in un file locale gitignorato, mai salvato nel repository. I segreti di produzione non vengono copiati sui computer locali.
• Registrazione degli accessi lato provider. Le azioni amministrative sui nostri provider vengono registrate da tali provider; le esaminiamo su base ad hoc.
• Riservatezza. Il personale (attualmente il titolare dell'impresa) è tenuto alla riservatezza in merito ai dati personali trattati attraverso il Servizio, come indicato nel DPA.
• Disciplina delle modifiche. Le modifiche al codice superano un rigoroso gate di controllo dei tipi, lint e test automatizzati prima del deploy, mentre le migrazioni dei database vengono applicate a un ambiente di staging prima della produzione.

6. Risposta all'incidente (notifica di violazione entro 72 ore)

Monitoraggio. Gli errori vengono inviati a Sentry (con la cancellazione dei dati personali descritta in "Misure tecniche" sopra); la diagnostica a livello di richiesta è disponibile nei log di hosting; un monitoraggio del tempo di attività e avvisi sul tasso di errore fanno parte della linea di base del rafforzamento. Il registro di controllo di sola aggiunta fornisce una registrazione duratura degli eventi rilevanti per la sicurezza a scopo di indagine.

Il nostro impegno di notifica delle violazioni. Se si verifica una violazione dei dati personali che potrebbe comportare un rischio per i diritti e le libertà delle persone interessate, ci impegniamo a:

• Informare l'autorità di controllo competente — il presidente di UODO in Polonia — senza indebito ritardo e, ove possibile, entro 72 ore dal venire a conoscenza della violazione (articolo 33 GDPR).
• *Laddove la violazione possa comportare un rischio elevato* per le persone interessate, informarle senza indebito ritardo, descrivendo la natura della violazione, le categorie di dati coinvolti, le probabili conseguenze e le misure adottate (articolo 34 GDPR**).
• Quando agiamo in qualità di responsabile del trattamento per un maneggio, informare tale maneggio (il titolare del trattamento) senza indebito ritardo in modo che possa adempiere ai propri obblighi ai sensi dell'articolo 33/34 nei confronti dei suoi cavalieri.

Ciò rispecchia l'Informativa sulla privacy e il DPA. Indica come intendiamo attuare un obbligo già imposto dal GDPR: non si tratta di una promessa contrattuale aggiuntiva rispetto al GDPR. Nella tabella di marcia è presente un runbook di risposta agli incidenti formalmente documentato; fino ad allora un team composto da una sola persona risponde ad hoc entro le tempistiche sopra indicate.

Contatto. Non urgente: support@nose.horse. Sicurezza (urgente): invia un'e-mail a support@nose.horse con `Security` nella riga dell'oggetto.

7. Inquadramento della conformità

GDPR (Regolamento 2016/679). Nose opera sotto un doppio ruolo: titolare del trattamento per i dati di cui determina scopi e mezzi (visitatori del nostro sito di marketing, dati di account/contatto di amministratori e istruttori dei maneggi, analisi del prodotto subordinate al consenso e dati di sicurezza/prevenzione degli abusi) e responsabile del trattamento dei dati operativi del cavaliere/cliente immessi da un maneggio: lì, il maneggio è il titolare del trattamento e Nose tratta secondo le istruzioni documentate del maneggio ai sensi del DPA (articolo 28 GDPR). I sub-responsabili del trattamento operano in base ai contratti previsti dall'articolo 28 (DPA + SCC/DPF, l'addendum del Regno Unito o un meccanismo equivalente laddove un trasferimento attraversa le regioni) — consulta la pagina Sub-responsabili del trattamento.

Dati dei bambini. I maneggi insegnano regolarmente ai bambini, quindi Nose tratta consapevolmente i dati dei minori per conto di un maneggio (ad esempio, un bambino inserito come partecipante alla lezione, spesso da un genitore cliente del maneggio). Il maneggio è responsabile della base giuridica e di qualsiasi consenso o autorità genitoriale richiesti dalla legge ad esso applicabile (articolo 8 GDPR nell'UE e nel Regno Unito; COPPA e legge statale negli Stati Uniti); Nose riduce al minimo ciò che viene conservato su un bambino e non si rivolge ai bambini né fa marketing diretto nei loro confronti. Consulta l'Informativa sulla privacy → “Privacy dei bambini”.

Sono supportati i diritti dell'interessato, incluso l'accesso/portabilità self-service tramite un'esportazione JSON su /account/export e la cancellazione tramite /account/delete (si applicano un periodo di grazia reversibile di 30 giorni e una riautenticazione rafforzata; in caso di cancellazione rimuoviamo gli identificatori diretti anziché eliminarli definitivamente — pseudonimizzazione ai sensi dell'articolo 4, paragrafo 5, GDPR, non anonimizzazione completa ai sensi del considerando 26; consulta la tabella di conservazione nell'Informativa sulla privacy → “Per quanto tempo conserviamo i dati” per il dettaglio a livello di campo). Per i dati del cavaliere, il titolare del trattamento è il maneggio, quindi un cavaliere esercita diritti nei confronti del suo maneggio e Nose lo assiste come responsabile del trattamento.

PCI DSS — non applicabile a Nose. Non gestiamo, archiviamo o trasmettiamo i dati della carta. Per la fatturazione dell'abbonamento del maneggio, il percorso dei dati della carta è interamente a carico del fornitore di servizi di pagamento, sul suo checkout ospitato — Stripe (processore dei pagamenti) per i maneggi polacchi, con Nose come commerciante, e Dodo Payments come Merchant of Record per i maneggi non polacchi. Per i pagamenti online dei cavalieri, quando un maneggio li attiva, i dati di carta, portafoglio o (in Polonia) BLIK vengono trasmessi interamente da Stripe (tramite Stripe Connect) e confluiscono sull'account Stripe proprio del maneggio — il maneggio è il commerciante e Stripe è il processore dei pagamenti conforme allo standard PCI, mentre Nose si limita a trasmettere le istruzioni e non riceve mai i dati della carta. In ogni caso Nose non riceve mai i dati della carta e rimane fuori dall'ambito PCI.

Regolamento UE sull'intelligenza artificiale (AI Act) — non applicabile. Nose è uno strumento operativo per i maneggi; non addestra, sviluppa o distribuisce modelli di intelligenza artificiale e nessun componente utilizza l'apprendimento automatico o l'intelligenza artificiale generativa per trattare i dati personali. L'estensione `pgvector` Postgres è abilitata per possibili futuri casi d'uso di ricerca interna, ma oggi non è popolata con embedding derivati da dati personali; se ciò dovesse cambiare, pubblicheremo una posizione sul regolamento UE sull'intelligenza artificiale e un impegno a "nessun addestramento su dati personali" prima del rilascio della funzionalità.

ePrivacy/cookie. Le analisi facoltative (PostHog) vengono caricate solo previo consenso; i cookie strettamente necessari sono esenti ai sensi dell'articolo 5, paragrafo 3, della direttiva ePrivacy. Consulta l'Informativa sui cookie.

8. Divulgazione responsabile

Se ritieni di aver trovato una vulnerabilità di sicurezza in Nose:

• Invia un'e-mail a [support@nose.horse](mailto:support@nose.horse) con `Security` nella riga dell'oggetto. (Sono previsti un indirizzo `security@` dedicato e una chiave PGP.)
• Includi dettagli sufficienti per riprodurre il problema.
• Concedici un periodo ragionevole per indagare e porre rimedio prima di qualsiasi divulgazione pubblica.

Cosa puoi aspettarti da noi:

• Un riconoscimento e una valutazione iniziale non appena ragionevolmente possibile. Nose è un servizio gestito da una sola persona e non può garantire una risposta in giornata; non lasceremo che una segnalazione credibile resti senza risposta.
• Lo stato viene aggiornato a intervalli ragionevoli durante la valutazione o la risoluzione del problema.
• Un riconoscimento (credit) in qualsiasi divulgazione successiva alla correzione, se lo desideri (facoltativo).

Ciò che non possiamo ancora offrire: non paghiamo ricompense monetarie per i bug in questa fase. Lo diremo chiaramente se e quando un programma di bug bounty sarà disponibile.

Ambito e porto sicuro. La ricerca sulla sicurezza in buona fede che segue questa politica, rimane all'interno dei tuoi account, evita di degradare il Servizio per altri e non accede a dati diversi dai tuoi non sarà trattata come una violazione della nostra Politica di utilizzo accettabile o dei Termini di servizio. Non tentare di accedere ai dati di un altro maneggio o di un altro cavaliere e non eseguire test automatizzati di scraping o di negazione del servizio contro il Servizio.

9. Registro delle modifiche