Przygotowanie do SOC 2: plan krok po kroku dla firm w Polsce

Przygotowanie do SOC 2 zaczyna się od ustalenia, jakiego raportu oczekuje klient, a kończy na komplecie dowodów, które audytor może sprawdzić bez dopytywania. Pomiędzy tymi punktami trzeba wyznaczyć zakres systemu, wybrać kategorie kryteriów, zamknąć luki, spisać polityki i uruchomić kontrole tak, żeby działały na co dzień. W tym przewodniku opisujemy kolejne kroki, pokazujemy listę dowodów i wyjaśniamy, jak wykorzystać pracę wykonaną już przy ISO 27001 albo RODO.
Co potwierdza raport SOC 2
SOC 2 to rama atestacyjna opracowana przez amerykański instytut biegłych rewidentów AICPA. Audytor ocenia w niej kontrole dostawcy usług według kryteriów Trust Services Criteria. Kryteria są pogrupowane w pięć kategorii: bezpieczeństwo (Security), dostępność (Availability), integralność przetwarzania (Processing Integrity), poufność (Confidentiality) i prywatność (Privacy). Bezpieczeństwo wchodzi do każdego raportu, a pozostałe kategorie firma dobiera do swojej usługi. Ten podział i różnicę między raportami Type I i Type II dobrze opisuje przewodnik po wymaganiach SOC 2.
Wynikiem badania jest raport z opinią audytora i opisem systemu. Firma nie dostaje certyfikatu w takim znaczeniu, w jakim dostaje go przy ISO 27001. Raport trafia do klientów i partnerów, którzy chcą sprawdzić, jak dostawca chroni ich dane. Więcej o samym standardzie i o tym, kogo dotyczy, przeczytasz na naszej stronie SOC 2: czym jest i kogo obejmuje.
Wiele osób wpisuje w wyszukiwarkę po prostu „raport SOC 2”, bo o taki dokument prosi klient w ankiecie bezpieczeństwa. Warto wtedy od razu zapytać, o który typ raportu chodzi. Od tej odpowiedzi zależy cały harmonogram przygotowań.
| Cecha | SOC 2 Type I | SOC 2 Type II |
|---|---|---|
| Co bada audytor | Czy kontrole są dobrze zaprojektowane na wybrany dzień | Czy kontrole są dobrze zaprojektowane i działają skutecznie przez cały okres obserwacji |
| Jakie dowody są potrzebne | Polityki, opis systemu, konfiguracje i pojedyncze przykłady działania kontroli | Dowody z całego okresu, z których audytor wybiera próbki |
| Kiedy ma sens | Gdy firma potrzebuje pierwszego potwierdzenia dla klienta i dopiero uruchomiła kontrole | Gdy klient oczekuje dowodu, że bezpieczeństwo działa w praktyce |
| Co oznacza dla przygotowań | Kontrole muszą być gotowe i opisane przed dniem badania | Kontrole muszą działać konsekwentnie od początku okresu obserwacji |
Kiedy firma w Polsce potrzebuje raportu SOC 2
O raport SOC 2 najczęściej proszą klienci z rynku amerykańskiego oraz duże firmy, które kupują usługi chmurowe, oprogramowanie lub obsługę IT. Dotyczy to zwłaszcza dostawców SaaS, software house’ów, centrów usług wspólnych i firm przetwarzających dane klientów na ich zlecenie. Dla polskiej firmy SOC 2 jest zwykle warunkiem handlowym zapisanym w zapytaniu ofertowym albo w umowie.
SOC 2 nie zastępuje obowiązków wynikających z prawa polskiego i unijnego. Jeśli przetwarzasz dane osobowe, nadal obowiązuje Cię RODO. Jeśli Twoja firma jest objęta NIS2 lub ustawą o krajowym systemie cyberbezpieczeństwa, czyli ustawą o KSC, te wymagania też musisz spełnić. Dobra wiadomość jest taka, że wiele kontroli i dowodów jest wspólnych. Sprawdzisz to w naszych tekstach o obowiązkach NIS2 w Polsce i o audycie RODO w firmie.
Plan przygotowań w ośmiu krokach
Poniższa kolejność sprawdza się w firmach od kilkunastu do kilkuset osób. Kroki od pierwszego do trzeciego ustalają, co będzie badane. Kroki od czwartego do siódmego budują kontrole i dowody. Krok ósmy to przegląd przed audytem.

1. Ustal, czego oczekuje klient
Zanim zaczniesz pisać polityki, zbierz wymagania od klientów, którzy proszą o raport. Zapytaj, czy wystarczy Type I, czy potrzebny jest Type II, jakie kategorie kryteriów ich interesują i do kiedy potrzebują dokumentu. Sprawdź też zapisy umów, SLA i dokumentacji produktu. Jeśli obiecujesz w umowie dostępność usługi lub poufność danych, te obietnice wyznaczają kategorie, które warto objąć raportem.
2. Wyznacz zakres systemu
Zakres to usługa, którą opisze raport, oraz wszystko, co jest potrzebne do jej świadczenia. Spisz aplikacje, infrastrukturę chmurową, bazy danych, repozytoria kodu, narzędzia do obsługi zgłoszeń i ludzi, którzy mają do nich dostęp. Zaznacz, gdzie są przechowywane dane klientów i którzy dostawcy zewnętrzni biorą udział w przetwarzaniu. Węższy zakres oznacza mniej kontroli do udowodnienia. Zakres musi jednak obejmować to, co klient faktycznie kupuje.
3. Wybierz kategorie kryteriów
Bezpieczeństwo jest obowiązkowe. Dostępność dodaj, jeśli klienci polegają na ciągłości Twojej usługi i masz zobowiązania SLA. Poufność ma sens, gdy przetwarzasz informacje objęte tajemnicą handlową klienta. Integralność przetwarzania dotyczy usług, w których liczy się poprawność i kompletność obliczeń lub transakcji. Prywatność obejmuje dane osobowe i warto ją rozważyć razem z wymaganiami RODO. Każda dodatkowa kategoria to dodatkowe kontrole i dowody, więc wybieraj je na podstawie oczekiwań klientów i ryzyka.
4. Zrób analizę luk i ocenę ryzyka
Porównaj to, co działa w firmie dziś, z kryteriami wybranymi do raportu. Dla każdego kryterium zapisz, czy kontrola istnieje, czy jest opisana i czy da się pokazać dowód jej działania. Równolegle przeprowadź ocenę ryzyka dla systemów w zakresie. Ocena ryzyka sama jest jednym z wymagań SOC 2, a jej wyniki pokazują, które luki zamknąć najpierw. Typowe braki dotyczą przeglądów uprawnień, formalnego zarządzania zmianą, testów odtwarzania kopii zapasowych i oceny dostawców.
5. Spisz i zatwierdź polityki
Audytor oczekuje polityk zatwierdzonych przez kierownictwo i przekazanych pracownikom. Zestaw podstawowy obejmuje politykę bezpieczeństwa informacji, kontrolę dostępu, reagowanie na incydenty, klasyfikację danych, zarządzanie dostawcami, zarządzanie zmianą, zarządzanie podatnościami, ciągłość działania oraz procedury przyjęcia i odejścia pracownika. Przechowuj dokumenty w repozytorium z kontrolą wersji, żeby było widać, kto i kiedy zatwierdził każdą zmianę. Polityka powinna opisywać to, co firma robi naprawdę. Rozbieżność między dokumentem a praktyką audytor wykryje przy pierwszej próbce.
6. Wdróż kontrole i wyznacz właścicieli
Każda kontrola potrzebuje właściciela, który odpowiada za jej działanie i za dowody. Przykłady to włączone uwierzytelnianie wieloskładnikowe, kwartalny przegląd uprawnień, zatwierdzanie zmian w kodzie przez drugą osobę, regularne skanowanie podatności czy szkolenie z bezpieczeństwa dla nowych pracowników. Zapisz, jak często kontrola działa i gdzie powstaje jej ślad. Poinformuj kierownictwo i właścicieli kontroli o planowanym audycie, żeby wiedzieli, o co audytor może ich zapytać.
7. Zbieraj dowody od pierwszego dnia
Przy raporcie Type II audytor wybiera próbki zdarzeń z całego okresu obserwacji. Jeśli przegląd uprawnień z jednego kwartału się nie odbył albo nie został zapisany, nie uzupełnisz go później. Najlepsze dowody powstają automatycznie: raporty systemowe, logi, których nie da się edytować, zgłoszenia z historią zmian i rejestry zatwierdzeń. Zrzut ekranu bez daty i nazwy systemu często nie wystarczy.
8. Wybierz audytora i zrób próbę generalną
Raport SOC 2 wydaje niezależna firma audytorska uprawniona do takich badań. Ustal z nią zakres, typ raportu, termin rozpoczęcia okresu obserwacji i listę dowodów, o które poprosi. Przed właściwym badaniem przejdź przez najważniejsze kontrole tak, jak zrobiłby to audytor. Wybierz kilka próbek z każdego obszaru i sprawdź, czy dowód jest kompletny, opisany i łatwy do znalezienia. Taki przegląd wewnętrzny wychwytuje braki wtedy, gdy jeszcze da się je naprawić.
Jakie dowody przygotować do raportu SOC 2
Lista dowodów zależy od zakresu i wybranych kategorii. Poniższa tabela pokazuje obszary, o które audytorzy pytają w niemal każdym badaniu kategorii bezpieczeństwa.
| Obszar | Przykładowa kontrola | Dowód, który przekonuje audytora |
|---|---|---|
| Zarządzanie dostępem | Uwierzytelnianie wieloskładnikowe i okresowe przeglądy uprawnień | Raport z systemu tożsamości, lista użytkowników, zapis przeglądu z datą i decyzjami |
| Przyjęcie i odejście pracownika | Nadanie i odebranie dostępów w ustalonym czasie | Zgłoszenia z datami, potwierdzenie usunięcia kont |
| Zarządzanie zmianą | Przegląd kodu i zatwierdzenie przed wdrożeniem | Historia zgłoszeń zmian, logi procesu wdrożeniowego, zatwierdzenia w repozytorium |
| Podatności | Regularne skanowanie i usuwanie podatności w ustalonym terminie | Raporty skanów, zgłoszenia naprawcze, wyniki testów penetracyjnych |
| Ciągłość działania | Kopie zapasowe i testy odtwarzania | Historia kopii, protokół testu odtwarzania |
| Incydenty | Rejestrowanie i analiza incydentów | Rejestr incydentów, raporty z analizy po incydencie |
| Szkolenia | Szkolenie z bezpieczeństwa dla wszystkich pracowników | Lista ukończonych szkoleń z datami |
| Dostawcy | Ocena dostawców przed współpracą i okresowo | Oceny dostawców, umowy, raporty z ich kontroli |
| Polityki | Zatwierdzenie i komunikacja polityk | Wersje dokumentów z datą zatwierdzenia, potwierdzenia zapoznania się |
Jeden brak potrafi wygenerować odstępstwo w raporcie. Wystarczy pracownik, który nie ukończył szkolenia, albo konto osoby, która odeszła, usunięte z opóźnieniem. Dlatego przy każdej kontroli warto mieć przypomnienia i jedno miejsce, w którym widać, czego jeszcze brakuje.
Jak wykorzystać ISO 27001 i RODO przy SOC 2
Wymagania SOC 2 i ISO 27001 w dużej części dotyczą tych samych obszarów. Oba podejścia wymagają oceny ryzyka, polityk, kontroli dostępu, zarządzania zmianą, reagowania na incydenty i nadzoru nad dostawcami. Jeśli Twoja firma ma już system zarządzania bezpieczeństwem informacji zgodny z ISO 27001, nie zaczynasz od zera. Trzeba przypisać istniejące kontrole do kryteriów SOC 2, uzupełnić brakujące elementy i dopilnować, żeby dowody pokrywały cały okres obserwacji. Jeśli dopiero planujesz obie normy, zacznij od naszego przewodnika wdrożenie ISO 27001 krok po kroku albo sprawdź poziom gotowości w bezpłatnym teście gotowości ISO 27001.
Podobnie jest z RODO. Rejestr czynności przetwarzania, umowy powierzenia, oceny skutków i procedury obsługi naruszeń przydają się przy kategorii prywatności i poufności. Firmy, które prowadzą kilka standardów naraz, zyskują najwięcej, gdy łączą je w jeden zintegrowany system zarządzania. Wtedy jedna polityka i jeden dowód odpowiadają na wymagania kilku norm jednocześnie.
Guardiso w przygotowaniu do SOC 2
Guardiso to platforma do zarządzania bezpieczeństwem informacji i zgodnością, która obsługuje SOC 2 razem z ISO 27001, RODO, NIS2, ustawą o KSC i DORA. Mapujemy wymagania między standardami, więc jedna dokumentacja i te same dowody służą wielu normom. Guardiso sam zbiera dowody z Microsoft 365, GitHub, AWS i innych narzędzi, daje gotowe polityki po polsku i po angielsku oraz pokazuje stan zgodności, ryzyka i zadania do wykonania. Przed audytem przygotowuje komplet dowodów dla audytora, a stan zgodności możesz udostępnić klientom w portalu bezpieczeństwa. Dane przechowujemy w Unii Europejskiej.

Plan Starter kosztuje 849 zł miesięcznie, a plan Professional 2149 zł miesięcznie. Dla dużych organizacji przygotowujemy plan Enterprise z wyceną indywidualną. Konsultanci, którzy prowadzą zgodność u kilku klientów, płacą 429 zł miesięcznie za każdą kolejną firmę. Szczegóły znajdziesz w cenniku Guardiso. Jeśli potrzebujesz wsparcia eksperta, nasz vCISO poprowadzi przygotowania, a testy penetracyjne i audyty dostarczą dowodów dla obszaru podatności.
Co zrobić, gdy audytor znajdzie odstępstwo
Odstępstwo, nazywane w raportach wyjątkiem, oznacza, że kontrola nie zadziałała w którejś z próbek. Zdarza się także firmom z dojrzałym programem bezpieczeństwa. Według poradnika o wyjątkach w raportach SOC reakcja powinna przebiegać w trzech krokach. Najpierw sprawdź, czy audytor dobrze zrozumiał dane i czy wyjątek nie wynika z nieporozumienia. Potem ustal przyczynę źródłową. Na końcu przygotuj odpowiedź zarządu, która rzeczowo potwierdza wyjątek, opisuje przyczynę i wymienia konkretne działania naprawcze.
Odpowiedź zarządu trafia do części raportu z informacjami od organizacji. Audytor nie testuje jej niezależnie, ale czytają ją przyszli klienci i osoby oceniające bezpieczeństwo dostawców, na co zwraca uwagę przewodnik o wyjątkach w zarządzaniu podatnościami. Ten sam tekst radzi, żeby nie spierać się z próbką audytora. Jeśli kontrola nie działała w okresie obserwacji, przyjmij ustalenie, określ dokładnie jego wpływ i przejdź do naprawy. Dopisanie polityki w trakcie badania nie usuwa ustalenia.

Jak utrzymać gotowość po otrzymaniu raportu
Raport Type II dotyczy konkretnego okresu. Klienci, którzy potrzebują aktualnego potwierdzenia, poproszą więc o raport za kolejny okres. Najprościej utrzymać gotowość, jeśli kontrole i dowody działają w stałym rytmie przez cały rok. Zaplanuj w kalendarzu przeglądy uprawnień, testy odtwarzania, przeglądy dostawców i szkolenia. Raz na kwartał sprawdź, czy dowody z ostatnich miesięcy są kompletne. Po każdej istotnej zmianie w produkcie lub infrastrukturze zaktualizuj opis systemu i ocenę ryzyka.
Warto też prowadzić audyty wewnętrzne między badaniami. Pokazują one, które kontrole słabną, zanim zobaczy to audytor. Wnioski z poprzedniego raportu, w tym wszystkie wyjątki, zamień w zadania z właścicielem i terminem. Przy kolejnym badaniu audytor zapyta, co zrobiono z wcześniejszymi ustaleniami.
Najczęstsze pytania
Od którego raportu zacząć: Type I czy Type II?
Zacznij od tego, o co prosi klient. Raport Type I bywa dobrym pierwszym krokiem, gdy klient potrzebuje potwierdzenia szybko, a kontrole dopiero ruszyły. Jeśli klient od razu oczekuje Type II, możesz zacząć okres obserwacji, gdy tylko kontrole działają i zbierasz dowody.
Czy SOC 2 to certyfikat?
Wynikiem badania jest raport z opinią niezależnego audytora, opisem systemu i wynikami testów kontroli. Firma nie otrzymuje certyfikatu w takim znaczeniu jak przy ISO 27001. Klient czyta cały raport, łącznie z ewentualnymi wyjątkami i odpowiedzią zarządu.
Czy z ISO 27001 łatwiej przygotować się do SOC 2?
Tak, bo oba podejścia obejmują w dużej części te same obszary bezpieczeństwa. Istniejące polityki, ocena ryzyka i dowody można przypisać do kryteriów SOC 2. Do uzupełnienia zostają elementy specyficzne dla SOC 2, w tym opis systemu i dowody z całego okresu obserwacji.
Kto w firmie powinien prowadzić przygotowania?
Projekt potrzebuje jednej osoby odpowiedzialnej za całość, najczęściej z działu bezpieczeństwa, IT lub compliance. Każda kontrola powinna mieć swojego właściciela, który dba o jej działanie i dowody. Zarząd zatwierdza polityki i odpowiedź na ewentualne wyjątki.
Źródła
- SOC 2 Compliance Checklist: How to Pass the Audit
- Common SOC Exceptions: Remediation & Management Guide
- The Engineering Manager’s Guide to Surviving a SOC 2 Vulnerability Management Exception
