Sicurezza e Misure Tecniche e Organizzative

Ultimo aggiornamento: 20 maggio 2026
Versione: 1.0
Link permanente a questa versione: bespokely.io/legal/security/v1.0

Questa pagina descrive le misure tecniche e organizzative ("TOMs") che Bespokely Inc. ("Bespokely") implementa per proteggere i dati personali trattati nei suoi prodotti, in adempimento dell'Art. 32 GDPR e obblighi equivalenti ai sensi di altre leggi sulla protezione dei dati.

Questa pagina si applica a tutti i prodotti gestiti da Bespokely Inc. Quando un prodotto differisce materialmente dalla baseline della piattaforma, ciò è evidenziato in §13 Note specifiche del prodotto.

§1 Governance della sicurezza delle informazioni

• Un programma di sicurezza delle informazioni documentato, rivisto almeno annualmente.
• Proprietà della sicurezza a livello di fondatore (Edgardo Romo, dirigente responsabile).
• Politiche di sicurezza che coprono: controllo degli accessi, uso accettabile, risposta agli incidenti, gestione dei fornitori, gestione delle modifiche, continuità aziendale.
• Tutti i dipendenti riconoscono la politica di sicurezza al momento dell'assunzione e ad ogni aggiornamento materiale.

§2 Controllo degli accessi

§2.1 Identità e autenticazione

• Account individuali nominativi per ogni operatore di Bespokely. Nessuna credenziale condivisa.
• Autenticazione a più fattori obbligatoria (TOTP minimo) per tutti gli accessi amministrativi ai sistemi di produzione.
• Accesso single sign-on tramite il fornitore di identità di Bespokely per qualsiasi operatore con accesso alla produzione.
• Gli utenti finali dei clienti si autenticano tramite il sistema di autenticazione del prodotto pertinente (Supabase Auth), con password hashate bcrypt e TOTP opzionale.

§2.2 Autorizzazione e minimo privilegio

• Principio del bisogno di sapere: l'accesso ai dati dei clienti è concesso solo agli operatori che ne hanno bisogno per un compito specifico.
• Controllo degli accessi basato sui ruoli a livello di applicazione.
• Politiche di Sicurezza a Livello di Riga (RLS) su tutte le tabelle del database contenenti dati personali.
• La chiave service_role di Supabase è conservata solo nelle variabili ambientali lato server; non è mai esposta ai bundle lato client.

§2.3 Processo di assunzione/movimento/uscita

• Provisioning tramite ticket contro il fornitore di identità.
• Revisione trimestrale degli accessi da parte del proprietario della sicurezza; il personale dimesso viene rimosso entro 24 ore dall'uscita.

§3 Crittografia dei dati

§3.1 A riposo

• Crittografia AES-256 per tutti i dati dei clienti memorizzati in PostgreSQL, storage di oggetti (Supabase Storage) e backup.
• I backup del database sono crittografati con chiavi gestite dal fornitore; rotazione delle chiavi secondo la politica del fornitore.
• Segreti sensibili (chiavi API, token OAuth, riferimenti ai pagamenti) memorizzati in gestori di segreti dedicati o crittografati a livello di colonna utilizzando pgsodium / pgcrypto.

§3.2 In transito

• TLS 1.2 minimo; TLS 1.3 preferito. I protocolli insicuri sono disabilitati.
• HSTS abilitato su tutti i domini rivolti ai clienti.
• Le connessioni al database utilizzano SSL con sslmode=require minimo (verify-full preferito per le connessioni server-database).
• Le chiamate interne da servizio a servizio utilizzano TLS terminato presso il servizio ricevente.

§4 Sicurezza della rete e dell'infrastruttura

• Tutta l'infrastruttura è gestita da fornitori (Vercel, Supabase) con la loro postura di conformità sottostante (Vercel e Supabase si basano sull'infrastruttura AWS per la regione UE — AWS detiene ISO 27001, SOC 2 Tipo II e altre certificazioni).
• Protezione DDoS al confine tramite Vercel.
• Segmentazione della rete tra ambienti di produzione, staging e sviluppo. Nessun database condiviso tra gli ambienti.
• Isolamento dei dati per tenant: un progetto Supabase per cliente per i carichi di lavoro dei dati dei clienti.

§5 Sicurezza delle applicazioni e ciclo di vita dello sviluppo software

• Tutte le modifiche al codice passano attraverso una revisione della pull request.
• Analisi statica (linters, controllori di tipo, scansione delle dipendenze) eseguita su ogni modifica.
• Le dipendenze sono tracciate tramite lockfile; gli aggiornamenti sono revisionati almeno mensilmente.
• I deployment in produzione sono immutabili e versionati; il rollback è a un clic.
• I segreti non vengono mai commessi nel controllo del codice sorgente; la scansione dei segreti pre-commit è abilitata.
• Le vulnerabilità web sono mitigate attraverso protezioni a livello di framework (token CSRF, codifica dell'output, query parametrizzate) e protezioni a livello di piattaforma (Vercel WAF, intestazioni CSP).

§6 Registrazione, monitoraggio e audit

• Il registro di audit a livello di applicazione registra ogni mutazione di dati personali: attore, timestamp, id record, azione. I payload del registro di audit fanno riferimento solo agli id record — non contengono i dati personali stessi.
• Registro di audit del database abilitato a livello di Supabase; le query degli operatori contro le tabelle con dati personali sono registrate.
• I log di runtime di Vercel catturano dati a livello di richiesta (indirizzo IP troncato, timestamp, percorso, stato). Conservazione: 30 giorni.
• Sentry cattura errori dell'applicazione con scrubbing PII abilitato (campi email e testo libero redatti prima della trasmissione).
• I registri di audit sono conservati per 3 anni per soddisfare il requisito di prova del consenso dell'Art. 7 GDPR e le esigenze forensi operative.

§7 Rilevamento e risposta agli incidenti

• Allerta 24×7 su segnali di disponibilità e sicurezza (picchi di autenticazione fallita, volumi di esportazione dati insoliti, picchi di errore).
• Piano di risposta agli incidenti documentato con classificazione della gravità.
• Notifica al cliente: per qualsiasi incidente di sicurezza confermato che influisce sui dati personali di un cliente, Bespokely notifica il cliente (titolare) senza indebito ritardo e in ogni caso entro 24 ore dalla conferma. Questo è più veloce della finestra di 72 ore dal titolare al DPA ai sensi dell'Art. 33 GDPR per dare tempo ai titolari.
• Post-incidente: post-mortem scritto entro 14 giorni, inclusi azioni di rimedio e aggiornamenti alla documentazione di sicurezza se applicabile.

§8 Backup e continuità aziendale

• Backup giornalieri crittografati di tutti i database dei clienti.
• Conservazione dei backup: 7 giorni, con recupero a un punto nel tempo disponibile all'interno di quella finestra.
• I backup sono memorizzati nella stessa regione UE dei dati primari (Francoforte per i prodotti della regione UE).
• Test di ripristino trimestrali per almeno un database di produzione per convalidare la recuperabilità.
• Piano di recupero da disastri documentato con RTO target ≤ 4 ore e RPO ≤ 24 ore per guasti in regione; più lungo per guasti a livello regionale.

§9 Sicurezza del personale

• Controlli dei precedenti per tutti gli operatori con accesso alla produzione, soggetti alla legge applicabile.
• Obblighi di riservatezza in ogni contratto di lavoro e di appalto.
• Formazione annuale sulla consapevolezza della sicurezza, inclusa la simulazione di phishing.
• Portare il proprio dispositivo è consentito solo per accesso non di produzione; accesso alla produzione solo da dispositivi gestiti.

§10 Gestione dei fornitori e sub-processori

• Ogni sub-processore è soggetto a un Accordo di Trattamento dei Dati scritto che include Clausole Contrattuali Standard dove applicabile.
• Revisione annuale della postura di sicurezza di ciascun sub-processore e stato di DPF / certificazione.
• Elenco pubblico dei sub-processori mantenuto su bespokely.io/legal/sub-processors, aggiornato con un preavviso di 30 giorni sulle modifiche secondo il DPA del cliente.
• I clienti mantengono il diritto di opporsi a un nuovo sub-processore.

§11 Posizione e sovranità dei dati

• I dati dei clienti per i prodotti che servono clienti UE sono ospitati in AWS eu-central-1 (Francoforte, Germania).
• Nessuna replicazione multi-regione dei dati dei clienti al di fuori dell'UE.
• I sub-processori di inferenza LLM (OpenAI, Anthropic) operano negli Stati Uniti e trattano i prompt lì sotto DPF / SCCs; configuriamo questi fornitori per rinunciare all'addestramento sui contenuti dei clienti dove l'opzione esiste.
• I dati dei contenuti dei clienti inviati agli LLM sono minimizzati e possono essere redatti a livello di applicazione dove il caso d'uso lo consente.

§12 Richieste degli interessati e assistenza ai titolari

• Assistiamo i clienti (titolari) nel soddisfare le richieste degli interessati ai sensi degli Art. 12–22 GDPR entro il SLA definito nel DPA del cliente (tipicamente: risposta al titolare entro 14 giorni dal ricevimento di una richiesta inoltrata).
• Forniamo ai titolari gli strumenti necessari per: esportare i dati dei clienti, eliminare i record su richiesta e pseudonimizzare i record dove l'eliminazione non è ancora possibile a causa degli obblighi di conservazione legale del titolare.

§13 Note specifiche del prodotto

§14 Certificazioni e attestazioni

Le seguenti certificazioni sono detenute o in corso. Dove Bespokely stessa non è ancora certificata, ci affidiamo alle certificazioni dei fornitori di infrastruttura sottostanti.

• AWS (infrastruttura sottostante per Vercel e Supabase regione UE): ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3, PCI DSS Livello 1, C5 (Germania).
• Vercel: SOC 2 Tipo II, ISO 27001.
• Supabase: SOC 2 Tipo II.
• Bespokely Inc. (diretto): SOC 2 Tipo II — in corso per il 2026 (programmato).

§15 Aggiornamenti a questa pagina

Gli aggiornamenti materiali sono versionati (v1.0, v1.1, ecc.) e notificati ai clienti attivi via email almeno 30 giorni prima che entrino in vigore, tranne nei casi in cui un aggiornamento inasprisce (anziché allentare) una misura, nel qual caso entra in vigore immediatamente e viene notificato entro 30 giorni dalla pubblicazione.

Le versioni precedenti sono conservate su bespokely.io/legal/security/v[VERSION].

Contatto per domande sulla sicurezza:
Bespokely Inc., 251 Little Falls Drive, Wilmington, DE 19808, USA · privacy@bespokely.io · +1 (512) 348-6588