Zarządzanie ryzykiem dostawców i podmiotów trzecich w startupie
Zarządzanie ryzykiem dostawców to wiedza o tym, które podmioty trzecie mają dostęp do Twoich danych, decyzja o tym, ile zapewnienia potrzebuje każdy z nich, i utrzymywanie tej oceny w aktualności. ISO 27001 obejmuje ten obszar w A.5.19 do A.5.23 — relacje z dostawcami, bezpieczeństwo w umowach z dostawcami, łańcuch dostaw ICT, monitorowanie i zarządzanie zmianami oraz usługi chmurowe — a SOC 2 adresuje go w CC9. W startupie wykonalna wersja to jeden rejestr dostawców, trzy poziomy oparte na tym, do czego dostawca faktycznie ma dostęp, wymagania dowodowe proporcjonalne do poziomu i coroczna weryfikacja, która wyłapuje przeterminowane raporty i po cichu zmienionych podprocesorów.
Zarządzanie ryzykiem dostawców to praktyka polegająca na tym, że wiesz, które podmioty trzecie mają dostęp do Twoich danych, decydujesz, ile zapewnienia potrzebuje każdy z nich, i utrzymujesz tę ocenę w aktualności. Dziedziczysz poziom bezpieczeństwa swoich dostawców niezależnie od tego, czy go oceniasz — jedyną zmienną jest to, czy dowiesz się o nim w swoim terminie, czy w trakcie incydentu.
Dla startupu działającego na trzydziestu narzędziach SaaS i jednym dostawcy chmury brzmi to jak program, na który nie masz ludzi. Nie jest nim. Wykonalna wersja to jeden rejestr, trzy poziomy i coroczny przegląd.
Gdzie umieszczają to standardy
ISO 27001 rozrzuca wymagania dotyczące dostawców na pięć zabezpieczeń z Załącznika A — i dlatego temat wydaje się większy, niż jest w rzeczywistości:
- A.5.19 — Bezpieczeństwo informacji w relacjach z dostawcami. Zdefiniuj i stosuj procesy zarządzania ryzykiem wynikającym z korzystania z dostawców.
- A.5.20 — Uwzględnianie bezpieczeństwa informacji w umowach z dostawcami. Wymagania bezpieczeństwa trafiają do umowy, a nie tylko do oceny.
- A.5.21 — Zarządzanie bezpieczeństwem informacji w łańcuchu dostaw ICT. Twoi dostawcy mają swoich dostawców.
- A.5.22 — Monitorowanie, przegląd i zarządzanie zmianami usług dostawców. Zapewnienie nie jest zdarzeniem jednorazowym.
- A.5.23 — Bezpieczeństwo informacji przy korzystaniu z usług chmurowych. Nowe w rewizji z 2022 roku i najbardziej istotne dla startupu wyrosłego w chmurze — zobacz mapowanie zabezpieczeń z 2013 na 2022, żeby sprawdzić, jak zmieniła się struktura Załącznika A.
SOC 2 obejmuje ten sam obszar w Kryterium Wspólnym CC9, które dotyczy ograniczania ryzyka, w tym ryzyka dostawców i partnerów biznesowych. W praktyce jeden proces spełnia oba wymagania. Operacyjnie zarządzanie dostawcami jest częścią rozdziału 8 dotyczącego działania — to proces, który prowadzisz, a nie dokument, który odkładasz do segregatora.
Krok 1: zbuduj rejestr z faktur, nie z pamięci
Rejestr dostawców jest fundamentem, a najszybszym uczciwym sposobem na jego zbudowanie jest wyeksportowanie z księgowości dwunastu miesięcy transakcji kartowych i faktur. Pamięć daje listę narzędzi, które lubisz; rozliczenia dają listę narzędzi, które faktycznie masz — łącznie z tymi, które jeden zespół wdrożył, nikomu o tym nie mówiąc.
Zestaw to z listą aplikacji w Twoim SSO oraz z subskrypcjami w marketplace Twojego dostawcy chmury. Wszystko, co pojawia się w rozliczeniach, ale nie w rejestrze, to albo shadow IT do objęcia kontrolą, albo subskrypcja do anulowania — oba wyniki są przydatne.
Minimalne pola dla każdego dostawcy: nazwa, świadczona usługa, właściciel po Twojej stronie, jakich danych dotyczy, czy przetwarza dane osobowe, poziom, posiadany dowód zapewnienia wraz z datą, data odnowienia umowy i data ostatniego przeglądu.
Krok 2: przypisz poziomy według tego, do czego naprawdę mają dostęp
Klasyfikowanie według wydatków to typowy błąd. Narzędzie za $30 miesięcznie z dostępem do produkcyjnej bazy danych to większe ryzyko niż platforma rekrutacyjna za $50,000. Klasyfikuj według dostępu:
| Poziom | Definicja | Oczekiwane zapewnienie |
|---|---|---|
| Poziom 1 — krytyczny | Przechowuje, przetwarza lub może uzyskać dostęp do danych klientów albo systemów produkcyjnych. Hosting chmurowy, platformy bazodanowe, narzędzia wsparcia, wszystko z kluczem API do produkcji. | Aktualny raport SOC 2 Type II lub certyfikat ISO 27001; umowa powierzenia, gdy w grę wchodzą dane osobowe; lista podprocesorów; udokumentowana analiza samego raportu. |
| Poziom 2 — ważny | Przechowuje dane firmowe lub pracownicze, ale nie dane klientów — HR, finanse, komunikacja wewnętrzna. | Raport atestacyjny lub certyfikat, jeśli jest dostępny; przegląd strony o bezpieczeństwie; umowa powierzenia tam, gdzie ma zastosowanie; lżejsza, ale udokumentowana weryfikacja. |
| Poziom 3 — niski | Brak dostępu do danych wrażliwych. Narzędzia projektowe, jednoosobowe utility, strony marketingowe. | Wpis w rejestrze i właściciel. Bez formalnej oceny. |
Trzy poziomy wystarczą. Modele pięciopoziomowe wyglądają rygorystycznie, a w dziesięcioosobowej firmie generują głównie spory o to, czy coś jest trójką, czy czwórką.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
Krok 3: proś o dowody, które coś znaczą
W przypadku dostawców z Poziomu 1 prośba jest prosta: najnowszy raport SOC 2 Type II albo certyfikat ISO 27001 wraz z Deklaracją Stosowania, a do tego umowa powierzenia i lista podprocesorów, jeśli w grę wchodzą dane osobowe.
Liczy się to, co zrobisz dalej. Zebranie raportu i wrzucenie go nieprzeczytanego do folderu to zabezpieczenie istniejące wyłącznie na papierze — i dokładnie w to celują audytorzy, pytając, jak oceniłeś dostawcę. Kiedy raport dotrze, sprawdź przynajmniej, czy okres objęty raportem pokrywa czas, w którym faktycznie polegałeś na tym dostawcy, czy zakres obejmuje usługę, z której korzystasz, a nie inną linię produktową, czy opinia jest bez zastrzeżeń i czy odnotowane wyjątki są takie, z którymi możesz żyć. Potem przeczytaj uzupełniające zabezpieczenia po stronie użytkownika — to rzeczy, które Ty musisz zrobić, żeby zabezpieczenia dostawcy w ogóle działały. Tę sekcję klienci pomijają najczęściej. Nasz przewodnik po czytaniu raportu SOC 2 dostawcy przechodzi przez cały dokument.
Zapisz krótki wniosek dla każdego dostawcy z Poziomu 1: co przejrzałeś, co znalazłeś, co zaakceptowałeś. Dwa zdania wystarczą. Bez tego masz szafę z dokumentami, a nie ocenę.
Krok 4: wpisz wymagania do umowy
A.5.20 istnieje dlatego, że ocena bez oparcia w umowie nie daje Ci niczego, co możesz wyegzekwować. U dostawców z Poziomu 1 warto mieć na piśmie: powiadomienie o naruszeniu w określonym terminie, prawo do otrzymywania aktualnych raportów, powiadomienie o zmianie podprocesorów, zwrot i usunięcie danych po zakończeniu współpracy oraz zobowiązania do poufności.
Realnie pięcioosobowy startup nie wynegocjuje indywidualnych warunków z hiperskalerem — akceptujesz standardową umowę powierzenia i odnotowujesz tę akceptację w rejestrze. To uprawniony wynik, a udokumentowanie decyzji jest właśnie tym, co odróżnia ryzyko zaakceptowane od przeoczonego.
Krok 5: pilnuj łańcucha podprocesorów
Twoi dostawcy mają swoich dostawców, a ich zmiany stają się Twoimi zmianami. Dokładnie o tym jest A.5.21. Praktyczna wersja dla małego zespołu: zapisz się na powiadomienia o zmianach podprocesorów, które oferują Twoi dostawcy z Poziomu 1, i odnotuj w rejestrze, gdzie krytyczne zależności dostawcy pokrywają się z Twoimi.
To pokrycie zasługuje na osobne spojrzenie. Jeśli Twój hosting, Twój monitoring i Twoja wysyłka poczty ostatecznie opierają się na tym samym dostawcy chmury w tym samym regionie, masz ryzyko koncentracji, którego nie ujawni żadna pojedyncza ocena — i jego miejsce jest we wpisie w Twoim rejestrze ryzyka, a nie tylko na liście dostawców.
Krok 6: weryfikuj co roku i przy każdej zmianie
A.5.22 wymaga monitorowania i przeglądu w czasie, bo zapewnienie się starzeje. Raporty SOC 2 obejmują ustalony okres i tracą aktualność; certyfikaty wygasają; dostawcy są przejmowani; produkty zmieniają architekturę.
Coroczny przegląd dostawców z Poziomu 1 i Poziomu 2 to rozsądna podstawa, uzupełniona o przeglądy wywołane zdarzeniami: gdy dostawca zostaje przejęty, gdy dochodzi u niego do publicznie ujawnionego naruszenia, gdy istotnie zmienia podprocesorów albo gdy Twoje własne wykorzystanie rozszerza się na bardziej wrażliwe dane. Wpisz ten przegląd w ten sam kalendarz, co pozostałe cykliczne kontrole — zobacz całoroczną listę kontrolną monitorowania.
Zakończenie współpracy zasługuje na tę samą dyscyplinę co jej rozpoczęcie: gdy przestajesz korzystać z dostawcy, potwierdź usunięcie danych, unieważnij klucze API i integracje oraz zamknij wpis w rejestrze z datą. Uśpione integracje z żywymi poświadczeniami to powracające ustalenie audytowe i realne ryzyko.
Podsumowanie
Zbuduj rejestr z rozliczeń, żeby był uczciwy, klasyfikuj według dostępu, a nie według wydatków, poproś dostawców z Poziomu 1 o prawdziwe zapewnienie i naprawdę je przeczytaj, wpisz klauzule bezpieczeństwa do umowy i weryfikuj raz w roku. To program ryzyka dostawców, który mały zespół jest w stanie realnie prowadzić — i który spełnia zarówno A.5.19–A.5.23, jak i CC9 bez zatrudniania osobnej osoby.
Dalej: jak czytać raport SOC 2 dostawcy, kiedy Twój własny SOC 2 zaczyna się opłacać — teraz, gdy jesteś po drugiej stronie tych ankiet — albo zobacz, jak ocena dostawców w AuditBadger trzyma rejestr, dowody i terminy przeglądów w jednym miejscu.
