Zgodność z SOC 2: czym jest i dlaczego klienci o nią pytają

Jeśli sprzedajecie oprogramowanie firmom, w pewnym momencie ktoś z działu bezpieczeństwa potencjalnego klienta zapyta, czy macie SOC 2 – czasem jeszcze zanim zgodzi się umówić na właściwą rozmowę ewaluacyjną. Warto rozumieć, o co tak naprawdę pyta, bo „SOC 2” bywa traktowane jak jedna odznaka „zdane/niezdane”, a w rzeczywistości to coś bardziej konkretnego.

Czym właściwie jest SOC 2

SOC 2 to standard audytowy, a nie certyfikat, o który się po prostu wnioskuje i który się dostaje. Opiera się na pięciu kategoriach, tzw. Trust Services Criteria: bezpieczeństwie, dostępności, integralności przetwarzania, poufności i prywatności. Każdy audyt SOC 2 obejmuje bezpieczeństwo; pozostałe cztery kategorie są opcjonalne i dobiera się je w zależności od tego, co faktycznie ma znaczenie dla waszego biznesu.

Raport SOC 2 sporządza niezależny, licencjonowany audytor po zbadaniu waszych rzeczywistych mechanizmów kontrolnych – prawdziwych polityk, prawdziwych zabezpieczeń technicznych i prawdziwych dowodów na to, że jedno i drugie istnieje i jest konsekwentnie stosowane w praktyce. Efektem jest pełnoprawny raport pisemny, a nie prosta odznaka „zdane/niezdane”, którą można wystawić na stronie internetowej.

Typ I a typ II

Typ I ocenia, czy mechanizmy kontrolne są prawidłowo zaprojektowane w jednym konkretnym momencie – to migawka pokazująca, że na dany dzień wszystko, co trzeba, jest na swoim miejscu.
Typ II ocenia, czy te mechanizmy faktycznie działały skutecznie przez określony okres, zwykle od trzech do dwunastu miesięcy – to dowód, że kontrole nie istnieją tylko na papierze, ale są rzeczywiście stosowane na co dzień.

To typ II ma większą wagę i to o niego klienci korporacyjni pytają najczęściej – właśnie dlatego, że pokazuje utrwaloną praktykę, a nie jednorazową konfigurację przygotowaną wyłącznie pod audyt.

Dlaczego klienci korporacyjni pytają właśnie o to

Gdy firma daje waszemu oprogramowaniu dostęp do swoich danych, obdarza was sporym zaufaniem, a jej własny dział bezpieczeństwa lub prawny często musi przed podpisaniem umowy sprawdzić, czy to zaufanie jest uzasadnione. Raport SOC 2 daje mu niezależny dowód od strony trzeciej – a nie tylko wasze zapewnienia – że macie wdrożone prawdziwe praktyki bezpieczeństwa. Dla wielu klientów korporacyjnych, zwłaszcza w branżach regulowanych, to podstawowe wymaganie, a nie miły wyróżnik.

Co obejmuje przygotowanie do SOC 2

Sam audyt to tak naprawdę ostatni krok. Większość pracy wykonuje się wcześniej – tak, by wasze rzeczywiste praktyki przeszły weryfikację:

Kontrola dostępu. Jasne, egzekwowane zasady określające, kto ma dostęp do jakich systemów i danych, oraz realny proces odbierania dostępu, gdy ktoś odchodzi z firmy lub zmienia rolę.
Zarządzanie zmianami. Udokumentowany i faktycznie przestrzegany proces przeglądu i wdrażania zmian w kodzie, tak by zmiany nie były wprowadzane chaotycznie i bez nadzoru.
Monitoring i logowanie. Realny wgląd w to, co dzieje się w waszych systemach, i rzeczywista możliwość wykrywania nietypowej aktywności oraz reagowania na nią – a nie logi, które istnieją, ale nikt do nich nie zagląda.
Reagowanie na incydenty. Udokumentowany plan działania na wypadek incydentu bezpieczeństwa, a nie coś, co wymyśla się po raz pierwszy pod presją.
Zarządzanie dostawcami. Realny proces oceny poziomu bezpieczeństwa zewnętrznych narzędzi i usług, od których zależy wasz produkt.
Praktyki bezpieczeństwa pracowników. Prawdziwe szkolenia z bezpieczeństwa i jasne zasady, których pracownicy faktycznie przestrzegają – a nie dokument leżący gdzieś na dysku współdzielonym.

Uczciwie o czasie

Rzetelne przygotowanie do audytu SOC 2 rzadko idzie szybko, zwłaszcza w przypadku raportu typu II, który wymaga wykazania konsekwentnej praktyki przez cały okres obserwacji, a nie zrywu tuż przed datą audytu. Firmy, które zaczynają myśleć o zgodności dopiero wtedy, gdy duży kontrakt już utknął z tego powodu, mają zwykle znacznie trudniej niż te, które traktują ją jako stałą praktykę wpisaną w codzienne funkcjonowanie.

Rzetelne przygotowanie zespołu – prawdziwe polityki, prawdziwe mechanizmy techniczne i ślad dowodowy, który audytor faktycznie będzie chciał zobaczyć – to właśnie praca nad gotowością do audytu zgodności, którą wykonuje Burncode, obok przeglądów bezpieczeństwa aplikacji i utwardzania infrastruktury. Dzięki temu sam audyt staje się formalnością, a nie nerwową gonitwą.