Czego założyciele B2B SaaS uczą się podczas pierwszego enterprise security review

Założyciel B2B SaaS zamyka swój pierwszy deal enterprise ustnie. Otwiera się szampan. Dwa tygodnie później przyjeżdża kwestionariusz bezpieczeństwa, trzy tygodnie po nim — przegląd prawny, a gdzieś około szóstego tygodnia deal, który był zamknięty w duchu, jest renegocjowany, odroczony lub cicho utracony. Założyciel spędza kolejny kwartał na gorączkowym dodawaniu rzeczy, które wyciągnął kwestionariusz.

Jest to tak przewidywalne, że stało się etapem w życiu każdej firmy SaaS. Założyciele, którzy go przeżywają, uczą się tych samych lekcji. Ci, którzy go nie przeżywają, uczą się ich i tak — tylko drożej.

O co naprawdę pyta kwestionariusz

Czterdziestostronicowy kwestionariusz bezpieczeństwa od kupującego z listy Fortune 500 wygląda jak wyczerpujący audyt techniczny. Nim nie jest. Pyta o jedną prostszą rzecz: jeśli nasz zespół bezpieczeństwa będzie musiał obronić ten zakup przed naszym CISO, czy będzie w stanie?

Pytania nie dotyczą tak naprawdę odpowiedzi. Dotyczą tego, czy myślałeś o odpowiedziach, czy są ze sobą spójne i czy Twoja postawa odpowiada powadze danych, które byś przechowywał. Kwestionariusz z pustymi polami odpada. Kwestionariusz z pewnymi, konkretnymi, wewnętrznie spójnymi odpowiedziami przechodzi — nawet jeśli niektóre brzą „aktualnie tego nie robimy i oto nasz plan wdrożenia."

To znaczy, że założyciel traktujący kwestionariusz jak test do zdania mija się z celem. Kwestionariusz to rozmowa. Kupujący pyta, czy może Ci zaufać ze swoimi danymi i czy jego zespół bezpieczeństwa będzie mógł obronić decyzję o zaufaniu Ci.

Pięć rzeczy, które zawsze się pojawiają

Przez wystarczającą liczbę deali enterprise te same pięć rzeczy pojawia się niemal w każdym kwestionariuszu i są to te same pięć rzeczy, na które założyciele SaaS zwykle nie są przygotowani.

SSO przez SAML lub OIDC z provisioningiem SCIM. Dział IT kupującego nie chce zarządzać indywidualnymi kontami w Twoim produkcie. Chce provisionować użytkowników ze swojego dostawcy tożsamości i mieć dostęp przepływający przez niego. Jeśli nie masz SSO, nie masz warstwy enterprise. SCIM — automatyczny deprovisioning, gdy pracownik odchodzi — to następne żądanie i jest niezbędne dla każdego kupującego z sensowną liczbą pracowników.

Logi audytowe, do których klient ma dostęp. Nie „mamy logi audytowe po naszej stronie." Klient chce swoich logów audytowych, w swoim SIEM, odpytywanych przez swój zespół. Zazwyczaj objawia się to jako wymaganie „wysyłaj zdarzenia do naszego narzędzia bezpieczeństwa." Bez tego kupujący nie może przeprowadzić własnego dochodzenia w przypadku incydentu w Twoim produkcie — co oznacza, że nie może Cię używać do niczego poufnego.

Obronialna odpowiedź na temat multi-tenancy. „Czy nasze dane są izolowane od danych Twoich innych klientów?" Uczciwe odpowiedzi to zazwyczaj „tak, logicznie, we wspólnej bazie danych z izolacją tenanta egzekwowaną na warstwie aplikacji." To jest w porządku, jeśli potrafisz to pewnie wyjaśnić i wykazać kontrole. Odpowiedź, która odpada, to założyciel, który panikuje, przesadnie opisuje izolację i daje niespójne odpowiedzi na pytania uzupełniające. Pewność w umiarkowanej postawie bije machanie rękami na temat mocnej.

Rezydencja danych i eksport. Gdzie żyją dane? Czy klient może je wyeksportować? Co się z nimi dzieje po rozwiązaniu umowy? Te pytania są krótkie w kwestionariuszu, a duże w praktyce. Wiele architektur SaaS zakłada, że dane mieszkają w jednym regionie chmury na zawsze i klient nigdy nie odchodzi. Oba założenia niszczą deale enterprise.

Przejrzystość sub-procesorów. Każdy vendor, którego używasz i który dotyka danych klientów, musi być ujawniony. Stripe, Twilio, OpenAI, Datadog, każdy dostawca AI. Klient przeczyta tę listę i jeden z nich będzie niedopuszczalny z powodów specyficznych dla tego klienta. Musisz być gotowy omówić alternatywy lub mieć wiarygodną odpowiedź, dlaczego zależność nie może zostać usunięta.

Kolejność ich dodawania

Jeśli jesteś przed etapem enterprise i próbujesz się przygotować, kolejność ma znaczenie. Budowanie wszystkich pięciu jednocześnie nie jest realistyczne dla większości zespołów; budowanie ich w złej kolejności zostawia niezgrabne, częściowe pokrycie.

Kolejność, która sprawdziła się w naszych projektach SaaS:

Pierwsza: logi audytowe, bo są łatwe do dodania później, ale niemożliwe do uzupełnienia wstecznie, jeśli czekasz. Każda akcja w systemie powinna być logowana z aktorem, celem, akcją, znacznikiem czasu i IP — od pierwszego tygodnia. Podziękujesz sobie później.

Druga: SSO, bo to pytanie, które najczęściej pojawia się jako pierwsze w rozmowie enterprise i które trwa najdłużej, jeśli chcesz je dołączyć w ostatniej chwili. Zbuduj z obsługą zarówno SAML, jak i OIDC. SCIM może poczekać, aż dwóch klientów enterprise o to poprosi, ale fundament SSO musi być na miejscu.

Trzecia: rygor modelu danych multi-tenant, bo to najtrudniejsze do zmiany później. Jeśli izolacja tenantów jest nieporządna, napraw to teraz. Jeśli jest czysta, udokumentuj ją wyraźnie, żebyś mógł ją obronić w kwestionariuszu.

Czwarta: inwentarz sub-procesorów, bo jest łatwy do zestawienia i prawie zawsze jest proszony. Prowadź go jako żywy dokument. Nowy vendor? Trafia na listę i jest przeglądany.

Piąta: rezydencja danych i eksport, bo to najbardziej prawdopodobne do odroczenia. Nawet ręczny, wspierany proces „wyeksportuj swoje dane na żądanie w ciągu 30 dni" wystarcza dla wielu kupujących i jest znacznie lepszy niż cicha odpowiedź „nie mamy właściwie procesu na to."

Głębsza lekcja

Kwestionariusz nie jest przeszkodą. Przeszkodą jest to, że klienci enterprise kupują nie tylko Twój produkt, ale obronialną decyzję o użyciu Twojego produktu. Opisane powyżej funkcje istnieją po to, by tę decyzję uczynić obronialną.

Założyciel, który to internalizuje, przestaje bać się zamówień enterprise i zaczyna używać ich jako ograniczenia projektowego, które kształtuje produkt w zdrowy sposób. SSO to i tak właściwa rzecz do zbudowania. Logi audytowe sprawiają, że Twój zespół wsparcia jest lepszy. Eksport danych to właściwa rzecz do zrobienia dla klientów. Brama zamówień w pewnym sensie wyświadcza Ci przysługę, zmuszając do postawienia pytania.

Po prostu rzadko wygląda jak przysługa podczas wypełniania kwestionariusza.