Cosa imparano i fondatori B2B SaaS durante la prima security review enterprise

Un fondatore di B2B SaaS chiude il primo deal enterprise verbalmente. Si stappa lo champagne. Due settimane dopo arriva il questionario di sicurezza, tre settimane dopo la revisione legale, e intorno alla sesta settimana il deal che era chiuso in spirito viene rinegoziato, rimandato, o silenziosamente perso. Il fondatore trascorre il trimestre successivo a rincorrere tutto ciò che il questionario ha portato alla luce.

È una sequenza così prevedibile da essere diventata una fase nella vita di un'azienda SaaS. I fondatori che la superano imparano le stesse lezioni. Quelli che non la superano le imparano lo stesso — solo a caro prezzo.

Cosa chiede davvero il questionario

Un questionario di sicurezza di quaranta pagine proveniente da un acquirente Fortune 500 sembra un audit tecnico esaustivo. Non lo è. Pone una domanda molto più semplice: se il nostro team di sicurezza deve difendere questo acquisto davanti al nostro CISO, può farlo?

Le domande non riguardano davvero le risposte. Riguardano se ci si è riflettuto sopra, se le risposte sono coerenti tra loro e se la postura rispecchia la serietà dei dati che si andrebbero a gestire. Un questionario con campi vuoti non passa. Uno con risposte sicure, specifiche e internamente coerenti passa, anche se alcune di quelle risposte sono "attualmente non facciamo questo e questa è la nostra roadmap per farlo."

Questo significa che il fondatore che tratta il questionario come un esame da superare sta mancando il punto. Il questionario è una conversazione. L'acquirente chiede se ci si può fidare di voi con i propri dati, e se il proprio team di sicurezza può difendere la decisione di farlo.

Le cinque cose che emergono sempre

Attraverso abbastanza deal enterprise, le stesse cinque cose compaiono in quasi ogni questionario, e sono le stesse cinque cose per cui i fondatori SaaS di solito non sono preparati.

SSO via SAML o OIDC, con provisioning SCIM. Il team IT dell'acquirente non vuole gestire account individuali nel vostro prodotto. Vuole fare il provisioning degli utenti dal proprio identity provider e far passare l'accesso attraverso di esso. Se non avete SSO, non avete un tier enterprise. SCIM — il deprovisioning automatico quando un dipendente lascia — è la richiesta successiva, ed è non negoziabile per qualsiasi acquirente con un organico significativo.

Audit log accessibili al cliente. Non "abbiamo audit log dalla nostra parte." Il cliente vuole i propri audit log, nel proprio SIEM, interrogabili dal proprio team. Di solito si concretizza come requisito di "inviare eventi al nostro strumento di sicurezza." Senza di esso, l'acquirente non può condurre indagini sugli incidenti a partire dal vostro prodotto, il che significa che non può usarvi per nulla di sensibile.

Una risposta difendibile sulla multi-tenancy. "I nostri dati sono isolati da quelli degli altri vostri clienti?" Le risposte oneste di solito sono "sì, logicamente, in un database condiviso con tenant scoping applicato a livello applicativo." Va bene, se lo si spiega con sicurezza e si dimostrano i controlli. La risposta che non passa è quella del fondatore che si fa prendere dal panico, gonfia l'isolamento e produce risposte incoerenti al follow-up. La fiducia in una postura moderata batte le vaghe promesse di una forte.

Residenza dei dati ed esportazione. Dove vivono i dati? Il cliente può estrarli? Alla risoluzione del contratto, cosa accade? Queste domande sono brevi nel questionario e grandi nella pratica. Molte architetture SaaS assumono che i dati vivano in una sola cloud region per sempre e che il cliente non se ne vada mai. Entrambe le assunzioni bloccano i deal enterprise.

Trasparenza sui subprocessori. Ogni fornitore che utilizzate e che tocca i dati del cliente va dichiarato. Stripe, Twilio, OpenAI, Datadog, ogni provider di IA. Il cliente leggerà questa lista e uno di essi sarà inaccettabile per ragioni specifiche di quel cliente. Bisogna essere pronti a discutere alternative, oppure avere una risposta credibile sul perché la dipendenza non può essere rimossa.

In quale ordine aggiungerli

Se siete pre-enterprise e volete prepararvi, l'ordine conta. Costruire tutti e cinque contemporaneamente non è realistico per la maggior parte dei team; costruirli nell'ordine sbagliato lascia una copertura parziale e scomoda.

L'ordine che ha funzionato nei nostri engagement SaaS:

Prima, gli audit log, perché sono facili da aggiungere a posteriori ma diventano impossibili da retrocompilare se si aspetta. Ogni azione nel sistema dovrebbe essere registrata con attore, destinatario, azione, timestamp e IP, dalla settimana uno. Ve ne feliciterete in seguito.

Secondo, SSO, perché è la domanda che emerge più spesso per prima in una conversazione enterprise ed è quella che richiede più tempo da aggiungere in modo pulito se è stata saltata. Costruirlo con sia SAML che OIDC. SCIM può aspettare fino ad avere due clienti enterprise che lo richiedono, ma la base SSO deve esserci.

Terzo, rigore nel modello dati multi-tenant, perché è il più difficile da cambiare in seguito. Se l'isolamento dei tenant è approssimativo, correggerlo ora. Se è pulito, documentarlo chiaramente in modo da poterlo difendere nel questionario.

Quarto, inventario dei subprocessori, perché è facile da assemblare ed è quasi sempre richiesto. Mantenerlo come documento vivo. Nuovo fornitore? Va nella lista e viene revisionato.

Quinto, residenza dei dati ed esportazione, perché è il più probabile a essere rimandato. Anche un processo manuale, supportato, di "esportazione dei tuoi dati su richiesta entro 30 giorni" è sufficiente per molti acquirenti, ed è di gran lunga meglio della risposta silenziosa "non abbiamo davvero un processo per questo."

La lezione più profonda

Il questionario non è l'ostacolo. L'ostacolo è che i clienti enterprise non comprano solo il vostro prodotto ma una decisione difendibile di utilizzarlo. Le funzionalità sopra elencate esistono per rendere quella decisione difendibile.

Un fondatore che interiorizza questo smette di temere il procurement enterprise e inizia a usarlo come vincolo progettuale che forma il prodotto in modo sano. SSO è la cosa giusta da costruire comunque. Gli audit log migliorano il vostro team di supporto. L'esportazione dei dati è la cosa giusta da fare per i clienti. Il gate del procurement, in un certo senso, vi sta facendo un favore forzando la domanda.

Raramente sembra un favore mentre si sta compilando il questionario.