"Jak zdać SOC 2" to pytanie, które zadaje większość startupów po raz pierwszy, a szczera odpowiedź zaczyna się od sprostowania założenia. SOC 2 nie jest egzaminem z wynikiem zdania/niezdania i nie wydaje certyfikatu. Niezależna firma CPA audytuje Twoje kontrole względem kryteriów AICPA Trust Services Criteria i wydaje opinię – pisemny raport stwierdzający, czy kontrole zostały odpowiednio zaprojektowane, a w przypadku typu raportu, którego oczekuje większość klientów, czy działały skutecznie w okresie obserwacji. "Zdanie" oznacza, że opinia audytora jest bez zastrzeżeń: brak wyjątków na tyle poważnych, by je zakwalifikować. Wszystko poniżej to proces, który prowadzi startup do takiej bez zastrzeżeń opinii, i dotyczy głównie zakresu i dyscypliny, a nie listy zmian w kodzie.
Type I vs Type II i dlaczego Type II jest tym, który się liczy
Raport Type I sprawdza, czy Twoje kontrole są odpowiednio zaprojektowane na określony dzień. Odpowiada na pytanie: "jeśli te kontrole działałyby zgodnie z opisem, czy spełniałyby kryteria", ale nie mówi nic o tym, czy faktycznie sprawdziły się w praktyce. Raport Type II sprawdza te same kontrole pod kątem skuteczności działania w okresie obserwacji, zwykle trzech miesięcy dla pierwszego raportu i od sześciu do dwunastu miesięcy dla odnowienia. Odpowiada na pytanie, które naprawdę interesuje zespół ds. bezpieczeństwa klienta: czy kontrola dostępu, zarządzanie zmianami i monitorowanie utrzymywały się w czasie rzeczywistym, a nie tylko wyglądały poprawnie na papierze.
Większość startupów ostatecznie potrzebuje Type II, ponieważ to właśnie tego oczekują zakupy korporacyjne i kwestionariusze bezpieczeństwa dostawców. Type I wciąż ma swoje zastosowanie: jest szybszy do przygotowania (nie trzeba czekać na okres obserwacji) i niektóre startupy używają go jako pierwszego dokumentu, aby pokazać postęp w negocjacjach z dużym klientem, podczas gdy okres obserwacji dla Type II trwa równolegle. Żaden z raportów nie jest certyfikatem, ani nie ma punktacji numerycznej; dostarczany dokument to raport zawierający opis systemu i kontroli (przez zarząd), oświadczenie zarządu, testy i wyniki audytora dla Type II oraz opinię audytora.
Określ zakres, zanim zbudujesz choć jedną kontrolę: tylko Security jest obowiązkowe
SOC 2 jest zorganizowany wokół pięciu kategorii Trust Services: Security, Availability, Confidentiality, Processing Integrity i Privacy. Security, czyli Common Criteria (kryteria CC, od CC1 do CC9), jest jedyną obowiązkową kategorią; każdy raport SOC 2 ją zawiera. Pozostałe cztery są opcjonalne, a startup, który domyślnie obejmuje wszystkie pięć, zwykle buduje i dokumentuje kontrole, których nikt nie wymaga.
Okreslaj zakres na podstawie tego, czego naprawdę oczekują przeglądy bezpieczeństwa Twoich klientów, a nie na podstawie szablonu. Typowa firma B2B SaaS to zwykle Security plus Availability (obiecujesz czas dostępności) i Confidentiality (przetwarzasz dane biznesowe klientów na podstawie obowiązku poufności, np. NDA). Processing Integrity ma znaczenie głównie wtedy, gdy główna funkcja Twojego systemu polega na przetwarzaniu transakcji, gdzie kompletność i dokładność tego przetwarzania stanowią obietnicę produktu, np. płatności lub rozliczenia, a nie po prostu "mamy bazę danych". Privacy to kategoria AICPA dotycząca zobowiązań dotyczących przetwarzania danych osobowych we własnej polityce prywatności, co jest odrębne od RODO lub innych ustawowych przepisów o ochronie danych; większość startupów spełnia oczekiwania klientów dotyczące danych osobowych bez konieczności dodawania tej kategorii. Zapytaj swoich pierwszych potencjalnych klientów korporacyjnych, czego wymaga ich zespół ds. bezpieczeństwa dostawców, zanim zdecydujesz się na zakres; dodanie kategorii później jest znacznie tańsze niż dokumentowanie tej, której nikt nie potrzebował.
Realistyczny harmonogram
Najpierw przychodzi gotowość: analiza luk względem wybranych kryteriów, napisanie polityk wymaganych przez kryteria (kontrola dostępu, zarządzanie zmianami, reagowanie na incydenty i inne) oraz usunięcie luk w kontroli w rzeczywistych systemach (wymuszanie MFA, włączanie logowania audytu, formalizowanie kroku zatwierdzania zmian). Dla małego startupu korzystającego z platformy automatyzacji compliance do śledzenia dowodów i kontroli gotowość zwykle trwa od czterech do ośmiu tygodni; dłużej, jeśli kontrola musi zostać zbudowana, a nie tylko udokumentowana, np. wdrożenie scentralizowanego logowania, którego wcześniej nie było.
W przypadku raportu Type II następny krok to okres obserwacji, a jego długość nie może zostać skrócona przez dostawcę: kontrole muszą działać przez uzgodniony okres, zanim audytor będzie mógł je przetestować, więc trzymiesięczny okres obserwacji to trzy kalendarzowe miesiące, a nie zbiór dowodów zebranych po fakcie. Nie ma powszechnego ustawowego minimum; okres jest uzgadniany z firmą CPA i kształtowany przez oczekiwania odbiorców raportu. Pierwsze raporty zwykle obejmują od trzech do sześciu miesięcy, a odnowienia od sześciu do dwunastu. W trakcie okresu obserwacji kontrole w zakresie muszą działać spójnie: luka może stać się wyjątkiem próbkowanym w zależności od testów audytora, jego charakteru, częstotliwości i znaczenia, ale nie automatycznie.
Prace polowe audytu następują po okresie obserwacji: audytor przegląda dowody, pobiera próbki transakcji i zmian, przeprowadza wywiady z właścicielami kontroli i przygotowuje ustalenia, zwykle od dwóch do czterech tygodni, a następnie wydaje ostateczny raport. Łącznie pierwszy raport Type II dla startupu to realistycznie od pięciu do dziewięciu miesięcy od rozpoczęcia do otrzymania raportu, co jest typowym punktem odniesienia, a nie wymogiem AICPA. Traktuj obietnicę "SOC 2 w miesiąc" ostrożnie: zwykle oznacza prace nad gotowością, raport Type I lub wyjątkowo krótki okres raportowania zaakceptowany przez konkretnego audytora, a nie konwencjonalny wielomiesięczny Type II.
Co naprawdę psuje okres obserwacji
Okres obserwacji to miejsce, w którym większość startupów po raz pierwszy spotyka się z nieprzyjemnym zaskoczeniem, ponieważ jest na tyle długi, że normalne prace inżynierskie mogą cicho unieważnić kontrolę, którą faza gotowości dopiero co ustawiła. Jednolinijkowa prośba o pull request, która poszerza politykę IAM do symbolu wieloznacznego dla wygody, czyszczenie, które usuwa linię logów audytu dla uprawnionego działania, poprawka awaryjna, która pomija zwykły krok zatwierdzania zmian pod presją terminu: żadna z tych czynności nie wygląda jak praca związana z compliance w momencie ich wykonywania, a każda z nich jest dokładnie tego rodzaju, co może stać się wyjątkiem próbkowanym, jeśli trafi do okresu obserwacji, a testy audytora ją wykryją. Szczegóły na poziomie kontroli dotyczące tego, które kryteria pojawiają się w diffie, głównie rodzina CC6 (logiczny dostęp) oraz CC7.2 (monitorowanie) i CC8.1 (zarządzanie zmianami), znajdują się w pogłębionej analizie frameworka SOC 2 oraz w przewodniku towarzyszącym, co SOC 2 sprawdza w Twoim repozytorium.
To właśnie na tym poziomie sprawdzanie compliance na poziomie pull requestów dodaje warstwę podczas okresu obserwacji: odczytuje każdą zmianę względem kryteriów, które określiłeś, i identyfikuje te, których dotyczy, np. CC6.1 w przypadku poszerzonej polityki IAM, jako komentarz do przeglądu w momencie proponowania zmiany. Jeśli zostanie złapana na tym etapie, zespół może ją ocenić i naprawić, zanim zostanie wdrożona, zwykle znacznie taniej niż później. Jeśli zostanie pominięta, jest to zmiana, którą audytor mógłby próbkować jako wyjątek, który musiałbyś wyjaśnić, co może utrudnić uzyskanie opinii, nad którą pracowałeś przez miesiące.
Czego to nie zastępuje
Sprawdzanie pull requestów to jedna warstwa znacznie szerszego procesu, i warto precyzyjnie określić, co stanowi resztę tego procesu, ponieważ żadna z tych części nie jest zadaniem heygrc. Wybór audytora, określenie kategorii zaufania, napisanie polityk, przeprowadzenie analizy luk gotowości, zbieranie dowodów z całego stacka (dostawca tożsamości, konfiguracja chmury, HR – onboardingu i offboardingu, zarządzanie dostawcami) przez cały okres obserwacji oraz wydanie opinii: to wszystko stanowi program compliance, zwykle realizowany za pomocą platformy zaprojektowanej specjalnie do tego celu (przewodnik po narzędziach automatyzacji compliance mapuje tę warstwę) oraz Twojego audytora. heygrc zostało zaprojektowane, aby odczytywać pull requesty względem wybranych kryteriów i identyfikować kontrolę, której dotyczy zmiana. Nie przeprowadza audytu, nie zastępuje audytora i nie gwarantuje uzyskania opinii bez zastrzeżeń; zostało zaprojektowane, aby pomóc zespołowi wychwycić istotne dla kontroli zmiany w pull requestach na wczesnym etapie, podczas trwania programu, zanim mogłyby stać się wyjątkiem, który utrudniłby uzyskanie opinii.