SOC 2: co dokumentować przy zatrudnianiu i odbieraniu dostępu

Przygotowanie do SOC 2 obejmuje także procesy związane z ludźmi: ustalenie uprawnień nowej osoby, szkolenia, potwierdzenie zasad bezpieczeństwa i odebranie dostępu po zakończeniu współpracy. Nawet dobrze zabezpieczona infrastruktura nie rozwiąże problemu zapomnianego konta lub dostępu nadanego bez wymaganej zgody.

Najtrudniejsze bywa odtworzenie kolejności zdarzeń. Kto zatwierdził dostęp? Kiedy pracownik zapoznał się z polityką? Czy konto wyłączono w terminie określonym przez firmę? Odpowiedzi powinny wynikać z zapisów procesu, zamiast zależeć od pamięci menedżera.

Co sprawdza audytor

Raport SOC 2 Type II obejmuje ocenę działania kontroli w określonym okresie. Audytor dobiera procedury i próbę do badanej kontroli, populacji oraz ryzyka. Nie istnieje uniwersalna zasada, że z 40 zatrudnionych trzeba sprawdzić 25, a jedno odstępstwo automatycznie zwiększa próbę do 60.

Wykryte odstępstwo może prowadzić do dodatkowych procedur. Jego wpływ na ocenę i opinię zależy od okoliczności. Nie każdy brak podpisu automatycznie oznacza negatywną ocenę całego systemu kontroli.

Przygotuj pełną listę zatrudnień, zmian ról i zakończeń współpracy w badanym okresie. Dla wybranych zdarzeń może być potrzebna zgoda na dostęp, zapis jego nadania lub odebrania, potwierdzenie szkolenia i inne dowody wynikające z przyjętych kontroli.

Kompetencje i dostęp: dwa powiązane obszary

Kryterium CC1.4 dotyczy pozyskiwania, rozwijania i utrzymywania kompetentnych osób zgodnie z celami organizacji. Nie narzuca każdej firmie identycznego szkolenia w pierwszym tygodniu ani powszechnego sprawdzania karalności przed zatrudnieniem. Zakres kontroli powinien odpowiadać ryzyku stanowiska i właściwemu prawu.

Kryteria CC6.x dotyczą dostępu logicznego i fizycznego. W praktyce warto udokumentować:

• Kto zatwierdza utworzenie konta i nadanie uprawnień.
• Jak uprawnienia odpowiadają obowiązkom danej osoby.
• Kiedy zespół przegląda i aktualizuje dostęp.
• Jak firma odbiera dostęp po zmianie roli lub zakończeniu współpracy.
• Co dzieje się z urządzeniami, nośnikami i danymi przy ich wycofaniu.

Nie należy utożsamiać CC6.5 wyłącznie z wyłączaniem kont pracowników: dotyczy ono ograniczenia dostępu do zasobów przy ich usuwaniu, przekazywaniu lub wycofaniu. Dobór i mapowanie kontroli ustal na podstawie Trust Services Criteria AICPA oraz zakresu badania.

Zarządzanie podatnościami jest osobnym obszarem. Jeśli należy do waszego zakresu, zobacz poradnik uruchomienia programu ujawniania podatności.

Przykład luki przy wdrażaniu pracowników

Załóżmy, że firma zatrudnia 40 osób w pół roku. HR prowadzi listę w arkuszu, IT otrzymuje prośby o konta mailem, a potwierdzenia szkoleń pozostają w osobnym systemie. Każdy z tych elementów może działać poprawnie, lecz bez wspólnego identyfikatora trudno je połączyć.

Podczas przeglądu okazuje się, że kilka kont utworzono przed wymaganą zgodą, a dla dwóch osób brakuje dowodu szkolenia. Trzeba ustalić, czy szkolenie się nie odbyło, czy tylko nie zachowano zapisu. To różne problemy i mogą wymagać różnych działań naprawczych.

Arkusz sam w sobie nie przesądza o nieskuteczności kontroli. Problemem jest niejasna odpowiedzialność, brak wymaganych dowodów lub brak sprawdzenia, czy proces rzeczywiście wykonano.

Jak zaprojektować kolejność działań

Można wykorzystać reguły etapów podobne do tych znanych z procesów wdrażania oprogramowania. Poniższy przykład opisuje integrację kilku systemów, którą trzeba zaprojektować i przetestować; nie jest listą gotowych funkcji Kit.

1. Sprawdzenie warunków rozpoczęcia pracy. Zespół potwierdza uzgodnione dokumenty i weryfikacje. Każde badanie przeszłości musi mieć właściwy zakres i podstawę prawną.
2. Szkolenie i polityki. Pracownik otrzymuje materiały oraz dostęp potrzebny do ich ukończenia. Zapis potwierdza, z którą wersją polityki się zapoznał.
3. Zgoda na dostęp. Uprawniona osoba zatwierdza konkretną rolę i zakres uprawnień.
4. Nadanie i potwierdzenie. System tożsamości lub IT nadaje dostęp, a proces zapisuje wynik, także ewentualny błąd.

Przy zakończeniu współpracy trzeba ustalić termin odebrania dostępu, listę systemów i sposób potwierdzenia wykonania. Sam webhook o rozwiązaniu umowy nie dowodzi, że wszystkie konta i sesje zostały wyłączone. Integracja może nie działać, a część aplikacji może pozostawać poza nią.

Jakie dowody zachować

Zapisuj zdarzenie, datę, osobę lub system wykonujący działanie oraz jego wynik. Połącz dane kadrowe z zapisami systemu tożsamości, szkoleń i zarządzania urządzeniami. Ustal okres przechowywania tych informacji i dostęp do nich.

Historia w aplikacji lub repozytorium Git nie jest automatycznie niezmiennym archiwum. Sprawdź możliwości usunięcia danych, uprawnienia administratorów i zakres eksportu. Z audytorem uzgodnij, jakie dowody będą wystarczające.

Wersje polityk i potwierdzenia zapoznania się

Polityki mogą być przechowywane w repozytorium lub systemie dokumentów. Ważne, by znać obowiązującą wersję, osobę odpowiedzialną i historię zatwierdzenia. Osobno trzeba dokumentować zapoznanie się z polityką, jeśli wymaga tego kontrola.

Po zmianie dokumentu ustal, kogo trzeba powiadomić i czy potrzebne jest ponowne potwierdzenie. Nie zakładaj, że zatwierdzenie zmiany w Git automatycznie uruchamia takie działanie. Wymaga to konkretnej integracji albo wyznaczenia osoby, która wykona tę czynność.

Automatyczne ograniczanie dostępu za brak potwierdzenia wymaga ostrożnego projektu: wyjątków, uprawnień awaryjnych i kontroli skutków. Samo narzędzie nie gwarantuje zgodności organizacji.

Przykładowy plan na 12 tygodni

To plan porządkowania procesu, nie gwarancja uzyskania raportu w trzy miesiące. Okres badania Type II i gotowość kontroli uzgodnij z audytorem.

Jak ocenić koszt pracy

Policz czas poświęcany na obsługę zdarzeń i późniejsze zbieranie dowodów. Porównaj go z kosztem integracji, jej utrzymania i kontroli błędów. Automatyzacja może ograniczyć pracę ręczną, ale nadal wymaga osoby odpowiedzialnej za jej działanie.

Raport IBM Cost of a Data Breach 2024 podawał globalny średni koszt naruszenia na poziomie 4,88 mln dolarów. To wynik dla badanych organizacji, a nie prognoza kosztu incydentu w waszym startupie ani wyliczenie zwrotu z automatyzacji wdrażania pracowników.

Gdzie w tym procesie mieści się Kit

Kit pomaga organizować rekrutację: zadania programistyczne, rozmowy, oceny i kolejne etapy. Warunki przejścia zależą od konfiguracji i uprawnień. Uprawnienia mogą pozwalać na pominięcie etapu, więc kontrole SOC 2 wymagają osobnego sprawdzenia.

Szablony ról ułatwiają przygotowanie kolejnych rekrutacji na wspólnej podstawie. Zmiana szablonu nie aktualizuje automatycznie istniejących procesów. Zespół powinien sprawdzić, które rekrutacje wymagają aktualizacji.

Historia kandydata nie zastępuje zapisów z dostawcy tożsamości, systemu urządzeń czy zewnętrznej weryfikacji. Kit nie zapewnia opisanej wyżej, uniwersalnej blokady tworzenia kont ani globalnego odwoływania sesji we wszystkich aplikacjach. Podział obowiązków w zespole oceniającym również nie dowodzi sam w sobie spełnienia CC6.3.

Rozpocznij bezpłatny okres próbny, żeby sprawdzić etapy i historię rekrutacji. Zakres dowodów dla audytu ustal na podstawie rzeczywistych kontroli w całej organizacji.