Validare un'idea non mette i dati al sicuro. Se ti sembra noiosa la cybersicurezza, aspetta la prima notte in cui un account che non è tuo è aperto e non sai chi ha le chiavi. In Snowinch è un pilastro del live, anche quando in call fa spegnere gli occhi.
La conversazione tipica è: "prima facciamo uscire, poi mettiamo a posto accessi e backup". Suona agile. È come spedire un giocattolo con le anagrafiche di gente vera.
Cosa entra in scope (prima che sia "dopo")
Non serve un film. Basta un token di servizio nel repo, uno staging indicizzato, un admin dato "tanto per testare", un export in una cartella condivisa. Quelli sono i modi in cui "abbiamo validato" diventa "ce li hanno portati via".
In scope, sul live, ci stanno cose noiose. Chi può entrare, e come si toglie. Dove stanno le copie, e chi le legge. Cosa finisce nei log (password, token, dati sanitari incollati per sbaglio). Cosa succede quando una persona chiede di essere cancellata. Cosa succede quando se ne va qualcuno del team con un laptop.
Niente di questo vende. Niente si vede nella landing. È comunque quello su cui sta in piedi il business, se il business è fatto di dati altrui.
Non basta validare proprio per questo. L'ipotesi può reggere e tu puoi comunque non dormire. L'intervista non tocca chi ha le chiavi.
Preferisco slittare un lancio e chiudere accessi, backup e cancellazione, piuttosto che spedire il test. Il costo è visibile: sembri più lento del founder che ha appena fatto una demo. Lo prendo. L'alternativa è spiegare che i dati sono usciti da un ambiente che "tanto era solo per validare".
Cosa non è fase 2: autenticazione vera (non un link magico mandato in una chat di gruppo), ruoli che non sono tutti admin, copie che hai provato a ripristinare almeno una volta, un modo per revocare un accesso senza chiedere a chi ha costruito il giocattolo. Se una di queste manca e hai già utenti estranei, non sei in un passaggio intermedio. Sei scoperto.
Un aside specifico: ho aperto un .env "di esempio" che era l'env di staging, con una chiave vera, committato perché "così il collega parte". Il collega è partito. Anche chiunque altro, in teoria. Non era un attacco. Era fretta.
Trade-off che prendo (e quale no)
Esiste un trade-off vero. Puoi spedire più stretto, con meno cerimonie, se lo scope dei dati è stretto: waitlist, nessun pagamento, nessuna anagrafica pesante, e lo dite. Il cartello può vivere con meno. Il prodotto con carte e documenti no.
Quello che non prendo: "zero problemi", "non ci entreranno", "il vendor ci copre". Non firmiamo il zero. Non abbiamo un benchmark da appendere. Possiamo dirti cosa è chiuso, cosa è accettato per iscritto, e chi risponde. Il resto è marketing della paura o della rassicurazione. Tutti e due sono la call sbagliata.
L'altro trade-off è tempo. Chiudere bene ritarda la slide. Aprirlo male anticipa la notte. Io sto sul primo. Se ti serve il secondo per una scadenza da pitch, cerca chi dice di sì.
C'è un caso in cui "dopo" è onesto: non ci sono ancora dati altrui, e il prototipo non li chiede. Allora la sicurezza del live non è il mestiere di quella settimana. Il mestiere è non fingere che quel prototipo sia produzione. Lo abbiamo scritto sul MVP che non è in produzione.
Cosa questa pagina non è
Non è un audit. Non è un elenco ISO. Non ti dice come configurare un vendor. Non promette che non succederà nulla. Se qualcuno ti promette il breach zero, sta vendendo sonno in bottiglia.
Su servizi la sicurezza entra nel perimetro del live, non in un'offerta a parte da sbloccare dopo il wow. Se lo scope è "usciamo, poi vediamo i dati", si dice di no.
Se hai già un segnale e ti serve qualcosa che tenga gli account degli altri, il discorso è concreto: cosa entra, cosa resta fuori, chi risponde. Si fa in contatti.
