SOC 2 dla firm SaaS: praktyczny przewodnik po audycie, kosztach i przygotowaniach

SOC 2 to raport z niezależnego badania kontroli bezpieczeństwa systemu. Nie certyfikat, nie wymóg prawny, ale de facto przepustka do sprzedaży B2B enterprise, zwłaszcza do klientów z USA lub organizacji objętych reżimami NIS2 i DORA. Kluczowy wybór:

Type I (projekt kontroli na dany dzień) vs Type II (skuteczność działania kontroli w czasie, potwierdzona przez audytora po 3–12 miesiącach obserwacji). Rynek enterprise preferuje Type II. Całkowity koszt to projekt kwartalny, ale zaniechanie go w momencie, gdy klient pyta o SOC 2 na etapie RFP, kosztuje znacznie więcej.

SOC 2 to raport z niezależnego badania kontroli bezpieczeństwa systemu. Nie certyfikat, nie wymóg prawny, ale de facto przepustka do sprzedaży B2B enterprise, zwłaszcza do klientów z USA lub organizacji objętych reżimami NIS2 i DORA. Kluczowy wybór: Type I (projekt kontroli na dany dzień) vs Type II (skuteczność działania kontroli w czasie, potwierdzona przez audytora po 3–12 miesiącach obserwacji). Rynek enterprise preferuje Type II. Całkowity koszt to projekt kwartalny, ale zaniechanie go w momencie, gdy klient pyta o SOC 2 na etapie RFP, kosztuje znacznie więcej.

Czym jest SOC 2 i kto go wydaje

SOC 2 to raport z niezależnego badania (examination) opisujący i oceniający kontrole związane z bezpieczeństwem, dostępnością, integralnością przetwarzania, poufnością i prywatnością systemu, w którym firma świadczy usługę. Standardy i kryteria oceny (Trust Services Criteria, TSC) tworzy AICPA. Raport wystawia niezależny audytor (CPA), który przeprowadza badanie i wydaje opinię. AICPA nie wydaje raportów bezpośrednio.

Trzy rzeczy, którymi SOC 2 NIE jest

• Nie jest certyfikatem ISO. ISO 27001 to odrębny standard ISMS; certyfikat wydaje zewnętrzna jednostka certyfikująca, nie AICPA.
• Nie jest dokumentem publicznym. Raport trafia do określonych interesariuszy z odpowiednią wiedzą o systemie. Stąd częste wymaganie NDA przy udostępnieniu. Chcesz czegoś publicznie widocznego? Rozważ SOC 3 (general use).
• Nie jest dowodem pełnej zgodności z GDPR. SOC 2 wspiera obszar bezpieczeństwa (art. 32 RODO) i może być elementem należytej staranności doboru procesorów (art. 28), ale GDPR to znacznie szerszy reżim: legalność przetwarzania, prawa osób, transfery do państw trzecich.

Na czym opiera się SOC 2?

Trust Services Criteria (TSC) obejmują pięć kategorii: security, availability, processing integrity, confidentiality, privacy. Bezpieczeństwo (security) stanowi rdzeń wspólny, tzw. Common Criteria, i jest zawsze obowiązkowe. Pozostałe kategorie dobierasz w zależności od obietnic w umowach SLA i specyfiki usługi.

Type I vs Type II: jaka jest różnica i co wybrać

To najważniejszy wybór przy starcie projektu SOC 2. Różnica jest konstrukcyjna, nie kosmetyczna, i ma bezpośrednie przełożenie na to, co klient enterprise zobaczy w raporcie.

Element	SOC 2 Type I	SOC 2 Type II
Co potwierdza	Projekt (design) kontroli na określoną datę	Projekt + skuteczność działania kontroli w czasie (operating effectiveness)
Metafora	Zdjęcie: kontrola była włączona w dniu badania	Nagranie wideo: kontrola działała konsekwentnie przez 3–12 miesięcy
Wymagania dowodowe	Dokumentacja projektu kontroli	Dokumentacja + dowody działania: logi, tickety, wyniki przeglądów, próbki
Jak odbierany przez enterprise	Czasem akceptowany jako „krok po drodze”	Najczęściej preferowany, pokazuje działanie w czasie
Typowy czas realizacji	Kilka miesięcy (przygotowania + fieldwork)	6–18 miesięcy: readiness + okres obserwacji (3–12 mies.) + fieldwork

Praktyczna zasada: Jeśli klient to enterprise z USA lub organizacja objęta DORA/NIS2, pytaj wprost: „Czy akceptujecie Type I?” Jeśli nie, planuj od razu z 6–12-miesięcznym oknem obserwacji. Robienie Type I tylko po to, żeby „szybko coś pokazać”, opóźnia decyzję, nie rozwiązuje problemu.

Czy musisz mieć Type I przed Type II? Nie. Przepisy AICPA nie wymagają Type I jako warunku. Kluczowe jest to, że Type II wymaga okresu, w którym kontrole działają konsekwentnie, zwykle 3 do 12 miesięcy przed fieldwork audytora.

Kiedy SOC 2 ma sens: rynek, regulacje, inwestorzy

Sytuacja 1: Sprzedaż B2B enterprise, zwłaszcza do USA

Zamiast każdorazowego wypełniania 30-stronicowych ankiet bezpieczeństwa (security questionnaires) dajesz klientowi raport oparty o wspólne kryteria i testy. AICPA wskazuje wprost, że odbiorcy raportu mogą używać go jako części procesu wyboru dostawcy lub do spełnienia wymagań akceptacji dostawcy wynikających z regulacji. W praktyce: SOC 2 Type II skraca security review z kilku tygodni do jednego spotkania.

Sytuacja 2: Regulacje pośrednie (GDPR, NIS2, DORA)

SOC 2 nie jest europejskim wymogiem ustawowym sam w sobie. Często jednak jest „dowodem pomocniczym” przy spełnianiu obowiązków prawnych:

• GDPR art. 28 nakłada na administratora obowiązek wyboru podmiotów przetwarzających, które dają wystarczające gwarancje wdrożenia odpowiednich środków. SOC 2 jest często używany jako element „pakietu dowodowego”, choć nie zastępuje pełnej analizy zgodności z RODO.
• NIS2 (dyrektywa 2022/2555, stosowana w Polsce od 18 października 2024 r.) wzmacnia obowiązki zarządzania ryzykiem w łańcuchu dostaw. Klienci objęci NIS2 coraz częściej wymagają od dostawców IT formalnego dowodu kontroli bezpieczeństwa.
• DORA (rozporządzenie 2022/2554, stosowane od 17 stycznia 2025 r.) dotyczy odporności cyfrowej sektora finansowego. Dla dostawców technologii sprzedających do banków i firm ubezpieczeniowych SOC 2 Type II może spinać dowodowo obszary: kontrola zmian, zarządzanie dostępem, monitorowanie incydentów, BCP/DR, bez zastępowania formalnych wymagań DORA.

Sytuacja 3: Due diligence inwestorskie i procesy M&A

Inwestorzy VC i PE coraz częściej traktują brak SOC 2 jako sygnał dojrzałości organizacyjnej poniżej progu, szczególnie gdy portfolio obejmuje firmy SaaS sprzedające do enterprise. W procesach IT due diligence M&A (buy-side) brak SOC 2 przy sprzedaży do sektora regulowanego wprost obniża wycenę lub wydłuża process.

SOC 2 vs ISO 27001 vs GDPR vs PCI DSS

Zanim wybierzesz „kolejny znaczek” na stronę security, warto zrozumieć, że każda z tych ram odpowiada na inne pytanie biznesowe i operacyjne.

Rama	Pytanie, na które odpowiada	Forma potwierdzenia	Typowe zastosowanie	Kluczowa różnica od SOC 2
SOC 2	Czy masz i utrzymujesz kontrole spełniające TSC i czy niezależny audytor to potwierdza?	Raport atestacyjny z opinią audytora (CPA)	B2B SaaS, cloud, MSP/MSSP, dostawcy IT	punkt odniesienia
ISO 27001	Czy masz wdrożony system zarządzania bezpieczeństwem informacji (ISMS)?	Certyfikat od zewnętrznej jednostki certyfikującej (ISO samo nie certyfikuje)	Szeroko: IT, przemysł, usługi publiczne	Certyfikat systemu zarządzania, nie raportu o kontrolach konkretnego systemu usługowego
GDPR / RODO	Czy przetwarzasz dane osobowe zgodnie z prawem i potrafisz to wykazać (accountability)?	Brak „certyfikatu GDPR”; istnieją mechanizmy certyfikacji art. 42	Każda organizacja przetwarzająca dane osób w UE/EOG	Prawo powszechnie obowiązujące, nie dobrowolny standard bezpieczeństwa
PCI DSS	Czy środowisko danych kartowych spełnia wymagania techniczne i operacyjne?	SAQ (samoocena) lub ROC (audyt), zależnie od poziomu transakcji	E-commerce, fintech, merchant/service provider w płatnościach kartowych	Standard branżowy narzucony przez organizacje kartowe, dotyczy wyłącznie środowiska danych kartowych (CDE)
NIST CSF 2.0	Czy zarządzacie ryzykiem cyber jako zestawem mierzalnych wyników (outcomes)?	Framework, brak certyfikacji ani raportu	Szeroko, zwłaszcza USA; często jako mapa odniesienia	Nie narzuca, jak osiągnąć wyniki, wskazuje co mierzyć, nie jak wdrożyć

Wniosek praktyczny: SOC 2 nie zastępuje ISO 27001 ani PCI DSS. Firmy łączą te ramy, np. SOC 2 Type II + ISO 27001 to coraz częstszy standard dla europejskich SaaS-ów sprzedających do enterprise. Planuj zestaw standardów pod konkretne rynki i klientów, nie pod „checklistę na stronie security”.

Korzyści i ograniczenia SOC 2

Korzyści: co realnie kupujesz

• Przyspieszenie due diligence. Zamiast każdorazowej odpowiedzi na „custom” ankiety dajesz raport oparty o wspólne kryteria i testy. W praktyce skraca security review z kilku tygodni do jednego spotkania, szczególnie przy klientach ze standardami wewnętrznymi (np. bankach, firmach ubezpieczeniowych).
• Lepsza pozycja w sprzedaży enterprise. Brak SOC 2 eliminuje firmę z przetargów już na etapie RFP, zanim w ogóle pojawi się rozmowa o produkcie. SOC 2 Type II to standard, nie wyróżnik.
• Porządek w kontrolach operacyjnych. TSC wymuszają zbudowanie ownership kontroli, cykliczności przeglądów i gromadzenia dowodów. Przygotowanie do SOC 2 przekłada się na realne podniesienie dojrzałości operacyjnej, nie tylko „papier do szuflady”.
• Gotowość na audyty klientów. NIS2 i DORA zwiększają nacisk na zarządzanie ryzykiem w łańcuchu dostaw. Klienci regulowani wymagają od dostawców IT formalnego dowodu kontroli. SOC 2 Type II jest tym dowodem i oznacza, że audyt klienta trwa godziny, nie tygodnie.

Ograniczenia: czego SOC 2 nie rozwiąże za Ciebie

• SOC 2 to raport dla określonych odbiorców, nie materiał marketingowy. Dystrybucja raportu wymaga zwykle NDA. Chcesz czegoś publicznie widocznego? SOC 3 (general use), ale ma mniejszy poziom szczegółowości.
• Type I nie dowodzi działania w czasie. Klienci enterprise zazwyczaj wiedzą o tej różnicy. Jeśli masz Type I, a klient oczekuje Type II, unikniesz problemu tylko opóźniając rozmowę.
• Raport jest zawsze „o zakresie” systemu. SOC 2 mówi prawdę o tym, co było w zakresie (system boundaries), w jakim okresie i jakie były wyjątki. Zbyt wąski zakres może rodzić pytania klienta; zbyt szeroki podnosi koszty i ryzyko wyjątków.
• „Aktualność” raportu w praktyce rynkowej. Raport nie ma formalnej daty wygaśnięcia, ale rynkowo opinia jest zazwyczaj akceptowana przez ok. 12 miesięcy. Klienci oczekują corocznego odnowienia.
• SOC 2 nie zastępuje GDPR. SOC 2 może wspierać art. 32 RODO (bezpieczeństwo przetwarzania) i art. 28 (dobór procesorów), ale pełna zgodność z RODO (podstawy prawne, prawa osób, transfery do państw trzecich) musi być adresowana osobno.

Proces przygotowania: kroki, role, harmonogram

Krok 1: Najpierw logika: zakres, typ, kryteria

1. Wybierz Type I vs Type II na podstawie wymagań klientów. Jeśli klient pyta o Type II, planuj od razu z odpowiednim oknem obserwacji, nie trać czasu na Type I jako „rozgrzewkę”.
2. Zdefiniuj Trust Services Criteria. Security zawsze. Pozostałe kategorie (availability, processing integrity, confidentiality, privacy) dobierasz do specyfiki usługi. Nie musisz brać wszystkich pięciu na start, zacznij od tego, o co klienci pytają najczęściej.
3. Ustal granice systemu (system boundaries). Co wchodzi do zakresu: aplikacja, infrastruktura, pipeline CI/CD, procesy supportu, role uprzywilejowane w HR (onboarding/offboarding). Co zostaje poza zakresem. To fundament, SOC 2 jest raportem o systemie i jego kontrolach, nie o całej firmie.

Typowe role w firmie SaaS

Rola	Odpowiedzialność w projekcie SOC 2
CEO/CTO (executive sponsor)	Decyzje o zakresie, priorytety biznesowe, akceptacja ryzyk
Security / Compliance lead	Właściciel projektu, kontakt z audytorem, koordynacja dowodów
DevOps / Platform	IAM, centralne logowanie, backup/DR, hardening, monitoring i alerting
Engineering	SDLC: code review, zarządzanie zmianami, zarządzanie podatnościami
IT / People Ops	Onboarding/offboarding (JML), polityki urządzeń, szkolenia security awareness
Legal / Privacy	Umowy, DPA, vendor risk, prywatność, szczególnie gdy TSC obejmuje „privacy”

Harmonogram: jak to wygląda w praktyce

Poniżej typowy przebieg projektu SOC 2 Type II (najczęstszy scenariusz):

1. Decyzja biznesowa: po co SOC 2 i dla którego klienta/rynku?
2. Wybór: Type I czy Type II? Który TSC?
3. Zdefiniowanie granic systemu (system boundaries)
4. Gap assessment / readiness: co już mamy, czego brakuje, jakie są luki
5. Remediacja: polityki + kontrole techniczne + automatyzacja zbierania dowodów
6. Okres obserwacji 3–12 miesięcy (tylko Type II): kontrole muszą działać konsekwentnie, zbierasz dowody
7. Fieldwork: testy audytora, próbkowanie dowodów, wyjaśnienia
8. Raport: opinia audytora, ewentualne wyjątki, rekomendacje
9. Utrzymanie: cykliczne przeglądy, monitoring, coroczne odnowienie

Najczęstszy błąd w harmonogramie: Firmy zaczynają zbierać dowody dopiero po ogłoszeniu, że „mają SOC 2”. W Type II audytor ocenia działanie kontroli w całym okresie obserwacji, nie tylko w tygodniu przed fieldwork. Polityki pisane „pod audyt”, których firma realnie nie stosuje, wychodzą na jaw podczas testów próbek.

Checklista przygotowania do audytu SOC 2

Poniższa tabela obejmuje najważniejsze obszary. Do pracy operacyjnej dodaj kolumny „Status” i „Link do dowodu”.

Obszar	Co przygotować	Minimalny dowód (przykłady)	Typowy owner	Kiedy
Zakres i TSC	Zakres systemu + wybrane kategorie TSC	Dokument „system boundaries”, lista usług i komponentów w zakresie	Security / CTO	Start projektu
Governance	Odpowiedzialności i akceptacja ryzyk	Decyzje zarządu, rejestr ryzyk, ścieżka eskalacji	CEO / CTO	Przed readiness
Polityki bezpieczeństwa	Zestaw polityk adekwatny do firmy i zakresu TSC	Security policy, access control, incident response, change management, acceptable use	Security lead	Przed okresem obserwacji
IAM i dostęp	MFA/SSO, role, zasady nadawania/odbierania dostępów (JML)	Konfiguracje IdP (np. Okta, Entra ID), logi, procedura Joiner-Mover-Leaver	DevOps / IT	Wdrożone przed Type II
Monitoring i logowanie	Centralne logi + alerting + retencja	Konfiguracje SIEM/log platform (np. Wazuh, Datadog), reguły alertów, dashboardy	DevOps / SRE	Przed Type II
Zarządzanie zmianą	Kontrola wdrożeń i zmian produkcyjnych	PR reviews, pipeline CI/CD, approvals, release notes, tickety zmian	Engineering	Od początku okresu obserwacji
Zarządzanie podatnościami	Regularne skany i patching	Raporty skanów, backlog z ticketami, polityka SLA na patching	Sec / DevOps	Cyklicznie
Zarządzanie incydentami	IR plan, ćwiczenia, dokumentacja	Runbooki, raporty post-mortem, wyniki tabletop exercises	Security + Eng	Przed i w trakcie okresu
Vendor risk	Lista subdostawców + ocena ryzyka	Rejestr vendorów, umowy, dowody ocen (np. ich SOC 2, ankiety)	Legal / Procurement	Przed Type II
Backup / BCP / DR	Odporność i procedury odtwarzania	Raporty testów backup/restore, wyniki DR test, RTO/RPO	DevOps	Przed Type II
Szkolenia	Security awareness dla wszystkich pracowników	Potwierdzenia ukończenia szkoleń, onboarding checklist	People Ops	Na starcie i cyklicznie

Koszty i czas realizacji SOC 2

Poniższe dane traktuj jako widełki budżetowe do planowania, nie jako wycenę. Ceny zależą od zakresu TSC, złożoności stacku, liczby zespołów w zakresie, jakości istniejących dowodów i wybranego audytora.

Czas

• Type I: kilka miesięcy. Orientacyjnie: 1–3 miesiące przygotowań (gap assessment, remediacja, dokumentacja) + kilka tygodni fieldwork i raportowania.
• Type II: 6–18 miesięcy łącznie. Kilka miesięcy przygotowań + 3–12 miesięcy okresu obserwacji (kontrole muszą działać konsekwentnie i generować dowody) + kilka tygodni fieldwork.

Koszty: typowe składowe

Składowa kosztowa	Orientacyjne widełki (USD)	Uwaga
Audyt SOC 2 (sam fieldwork + raport)	5 000 – 60 000 USD	Szeroki przedział, zależy od liczby TSC, złożoności systemu i reputacji audytora
Readiness / gap assessment	2 000 – 15 000 USD	Często wyceniany osobno przez audytora lub consultanta
Narzędzia do automatyzacji dowodów (Vanta, Drata, Secureframe)	1 000 – 15 000 USD/rok	Alternatywa: praca manualna (niższy koszt narzędzi, wyższy koszt czasu)
Penetration testing / skany podatności	5 000 – 30 000 USD	Często wymagane przez audytora jako dowód w TSC Security
Czas pracy zespołu wewnętrznego	Zwykle największy ukryty koszt	Security lead: 30–60% etatu przez kilka miesięcy; DevOps/Eng: 10–20%

Gdzie można zaoszczędzić: automatyzując zbieranie dowodów i zaczynając od minimalnego, realnego zakresu systemu.

Gdzie nie warto oszczędzać: na wyborze audytora (tanio = wolno lub płytko) i na remediacji. Polityki, których firma realnie nie stosuje, wychodzą na jaw w Type II i generują wyjątki w raporcie.

Mini case studies: cztery scenariusze zastosowań

Scenariusz A: startup SaaS sprzedaje do enterprise w USA

Firma z Europy przegrywała deale z klientami z USA, bo security review trwało kilka tygodni i wymagało odpowiedzi na setki pytań w ankiecie. Po uzyskaniu SOC 2 Type II (zakres: Security + Availability, platforma AWS, 12-miesięczny okres obserwacji) czas security review skrócił się do jednej rozmowy. Raport zastąpił ankietę. Koszt całości: ok. 80 000 USD łącznie z readiness, narzędziami i audytem. Decyzja zamknięcia pierwszego kontraktu enterprise pokryła całość w jednej transakcji.

Scenariusz B: europejski SaaS obsługuje klientów z sektora finansowego (DORA)

Klienci z sektora bankowego (DORA od 17 stycznia 2025 r.) pytają o kontrolę ryzyka ICT i dostawców. SOC 2 Type II nie jest „certyfikatem DORA”, ale spinał dowodowo praktyki operacyjne wymagane podczas vendor risk assessment: zarządzanie zmianami (change management), zarządzanie dostępem uprzywilejowanym, monitorowanie incydentów, BCP/DR. Klienci zaakceptowali raport SOC 2 jako część „pakietu dowodowego” obok DPA i ankiety bezpieczeństwa.

Scenariusz C: SaaS jako procesor danych osobowych (GDPR art. 28)

Administratorzy danych pytają o gwarancje bezpieczeństwa (GDPR art. 28) i wdrożone środki techniczne i organizacyjne (art. 32). SOC 2 wypełnia część „pakietu dowodowego” dotyczącego bezpieczeństwa i kontroli dostępu. Pełna zgodność GDPR (podstawy prawne przetwarzania, prawa osób, transfery do państw trzecich) musi być adresowana osobno, np. przez DPA i ocenę TIA. SOC 2 nie zastępuje analizy prawnej.

Scenariusz D: firma e-commerce i płatności (SOC 2 vs PCI DSS)

Tutaj SOC 2 nie zastąpi PCI DSS. PCI DSS dotyczy środowiska danych kartowych (Cardholder Data Environment, CDE) i jest wymagany przez organizacje kartowe (Visa, Mastercard) dla podmiotów, które przetwarzają, przechowują lub przesyłają dane kartowe. SOC 2 i PCI DSS można posiadać równolegle, obejmują różne zakresy i odpowiadają na różne pytania klientów i regulatorów.

Najczęstsze błędy przy SOC 2 i jak ich uniknąć

• Błąd 1: Zbyt szeroki zakres na start. Próba objęcia audytem całej firmy, wielu produktów, wielu środowisk, zwiększa liczbę kontroli do udokumentowania, liczbę możliwych wyjątków i koszt fieldwork. Zacznij od jednego produktu, jednej platformy chmurowej, najważniejszych przepływów danych. Rozszerzaj zakres przy kolejnych odnowieniach.
• Błąd 2: Mylenie Type I z Type II. Klientów enterprise interesuje Type II, pokazuje działanie kontroli w czasie, nie tylko ich projekt. Informowanie klientów o Type I tam, gdzie oczekują Type II, opóźnia deal.
• Błąd 3: Polityki bez operacyjnych śladów. „Mamy politykę” to za mało. W Type II audytor próbkuje dowody działania kontroli z całego okresu obserwacji: logi, tickety, wyniki przeglądów. Polityki pisane „pod audyt”, których firma realnie nie stosuje, generują wyjątki (exceptions) w raporcie.
• Błąd 4: Brak kontroli dostawców (vendor risk). NIS2 i DORA akcentują ryzyko łańcucha dostaw. Klienci regulowani pytają nie tylko o Twoje kontrole, ale też o to, jak zarządzasz kluczowymi subdostawcami, dostawcami chmury, SaaS-ami w zakresie systemu. Brak rejestru vendorów to klasyczny wyjątek w TSC.
• Błąd 5: Traktowanie SOC 2 jako „zgodności ze wszystkim”. SOC 2 to narzędzie do jednego konkretnego celu: zapewnienia o kontrolach dotyczących TSC w systemie usługowym. Nie zastępuje GDPR, PCI DSS ani ISO 27001. Firmy, które to mylą, generują fałszywe poczucie bezpieczeństwa u klientów, co może skutkować problemami prawnymi i reputacyjnymi.

FAQ

Czy SOC 2 jest obowiązkowy prawnie?

Zwykle nie „wprost”. SOC 2 to najczęściej wymaganie rynkowe lub kontraktowe: oczekiwanie klientów enterprise, element procurement, warunek przejścia security review. Pośrednio regulacje (GDPR, NIS2, DORA) powodują, że klienci objęci tymi reżimami pytają o SOC 2 jako dowód kontroli bezpieczeństwa.

Czy muszę mieć Type I przed Type II?

Nie. Kluczowe jest to, że Type II wymaga okresu, w którym kontrole działają konsekwentnie, zwykle 3 do 12 miesięcy przed fieldwork. Możesz od razu planować Type II, bez robienia Type I jako kroku pośredniego.

Czy SOC 2 można opublikować na stronie internetowej?

Z zasady SOC 2 jest raportem dla określonych odbiorców mających odpowiednią wiedzę o systemie, stąd standardowe ograniczenia dystrybucji i wymaganie NDA. Jeśli chcesz czegoś publicznie widocznego, rozważ SOC 3 (general use), który obejmuje podobne obszary, ale ma mniejszy poziom szczegółowości.

Jak długo jest „ważny” raport SOC 2?

Technicznie raport nie ma daty wygaśnięcia. W praktyce rynkowej opinia jest zazwyczaj akceptowana przez ok. 12 miesięcy. Po tym czasie klienci enterprise oczekują świeższego raportu, stąd coroczne odnawianie jako standard.

Czy SOC 2 = ISO 27001?

Nie. ISO 27001 to standard systemu zarządzania bezpieczeństwem informacji (ISMS); certyfikat wydaje zewnętrzna jednostka certyfikująca (ISO samo nie certyfikuje). SOC 2 to raport atestacyjny o kontrolach dotyczących Trust Services Criteria w konkretnym systemie usługowym. Można posiadać oba, często się uzupełniają.

Ile kosztuje przygotowanie do SOC 2 dla firmy SaaS w Polsce?

Orientacyjnie: sam audyt to 5 000–60 000 USD (zależy od zakresu TSC i złożoności systemu). Do tego dochodzą koszty readiness, narzędzi, pentestów i czasu zespołu wewnętrznego. Łączny koszt „projektu SOC 2” to często kilkadziesiąt do ponad stu tysięcy złotych, ale decyzja o pierwszym enterprise kliencie pokrywa go zwykle jednorazowo.

Co to jest SOC 3 i kiedy go stosować?

SOC 3 obejmuje podobne obszary co SOC 2 (TSC), ale ma mniejszy poziom szczegółowości i jest przeznaczony do swobodnej, publicznej dystrybucji („general use”). Możesz go opublikować na stronie security bez NDA. Klienci enterprise wymagają SOC 2 (pełny raport), nie SOC 3, ale SOC 3 jest użyteczny jako „wizytówka” na stronie dla mniejszych klientów.