Jak sprawdzić, czy dostawca systemu medycznego jest zgodny z NIS 2? Checklista

dostawca systemu medycznego zgodny z NIS 2
Dyrektywa NIS 2 a łańcuch dostaw IT – kluczowe wnioski:
  • Dostawca systemu medycznego zgodny z NIS 2 to taki, którego zobowiązania da się wyegzekwować z umowy, a nie taki, który deklaruje zgodność w ofercie.
  • Siedem punktów poniżej sprawdza się przed podpisaniem lub przedłużeniem umowy. Najlepiej wpisując je wprost do SWZ.
  • Odpowiedzialność za bezpieczeństwo łańcucha dostaw spoczywa na szpitalu, nie na dostawcy oprogramowania.
  • Najtańszy moment na wprowadzenie klauzul bezpieczeństwa to przedłużenie umowy, bo nie wymaga osobnego postępowania.

Spis treści

Co właściwie znaczy, że dostawca systemu medycznego jest zgodny z NIS 2?

Dostawca systemu medycznego zgodny z NIS 2 to podmiot, który zapewnia aktualizacje bezpieczeństwa przez cały okres umowy, kontroluje własny dostęp serwisowy, informuje o incydentach w ustalonym terminie i zgadza się na weryfikację stosowanych zabezpieczeń. Deklaracja zgodności złożona w ofercie nie ma wartości dowodowej, ponieważ dyrektywa NIS 2 nie przewiduje certyfikatu potwierdzającego taki status.
Typowa sytuacja wygląda tak: w odpowiedzi na zapytanie ofertowe przychodzi dokument z oświadczeniem o zgodności z wymogami NIS 2. Dział zamówień dołącza go do dokumentacji postępowania, bo o to prosił, i uznaje punkt za zamknięty. Decyzja wygląda na poprawną, oświadczenie jest podpisane i dotyczy właśnie tego, o co pytano.

Problem ujawnia się dopiero przy kontroli, kiedy pada pytanie nie o oświadczenie, lecz o to, co placówka sprawdziła. Oświadczenie potwierdza, że dostawca coś zadeklarował. Nie potwierdza, że placówka cokolwiek zweryfikowała, a obowiązek dotyczy drugiej z tych rzeczy.
To rozróżnienie jest kluczowe dla działu zamówień. Podmiot kluczowy musi wykazać, że zweryfikował kontrahentów, a nie że otrzymał od nich zapewnienia. Nie istnieje przy tym dokument, którym dostawca mógłby potwierdzić swoją zgodność w sposób ostateczny, ponieważ dyrektywa NIS 2 opisuje obowiązki podmiotu, a nie procedurę certyfikacji jego kontrahentów.
Weryfikacja polega więc na sprawdzeniu konkretnych zobowiązań i przeniesieniu ich do umowy, bo tylko zapis umowny da się później wyegzekwować. Oczekiwany zakres trzeba opisać samodzielnie, punkt po punkcie.

Dlaczego dostawca oprogramowania medycznego też podlega wymogom NIS 2?

Dyrektywa NIS 2 obejmuje bezpieczeństwo łańcucha dostaw jako osobny obszar obowiązków podmiotu, a nowelizacja ustawy o KSC przeniosła ten wymóg do prawa polskiego. Łańcuch dostaw obejmuje tu każdy podmiot, który dostarcza oprogramowanie, sprzęt lub usługę wpływającą na działanie systemów. Szpital odpowiada więc za poziom zabezpieczeń stosowanych przez swoich kontrahentów, nawet jeśli dany dostawca nie jest samodzielnie objęty ustawą. Mechanizm ten opisaliśmy szerzej we wpisie o tym, kogo dotyczy NIS 2.

Przykład, który dobrze to pokazuje. Serwisant producenta aparatury łączy się zdalnie, żeby usunąć awarię zgłoszoną w nocy. Robi dokładnie to, do czego został wezwany, i placówka jest z tej reakcji zadowolona. Połączenie zostaje jednak otwarte, bo nikt go nie zamyka ani po stronie serwisu, ani po stronie szpitala, gdzie nikt o nim nie wie.
Jeżeli tym kanałem wejdzie zdarzenie, konsekwencja jest niewygodna, ale jednoznaczna. Kara administracyjna trafia do szpitala, a nie do firmy, której serwisant połączenia nie zamknął. Trzeba pamiętać, że przepisy wiążą obowiązek z podmiotem korzystającym z usługi, nie z jej wykonawcą.

Dostawcy bywają przy tym najsłabszym ogniwem właśnie dlatego, że dysponują uprawnieniami szerszymi niż własny personel placówki. Firma obsługująca infrastrukturę sieciową ma zwykle dostęp do wszystkiego, choć jej umowa należy do najtańszych w całym zestawieniu.
Warto też zauważyć skalę zjawiska. Przeciętna placówka medyczna współpracuje z kilkunastoma podmiotami mającymi dostęp do systemów: dostawcą systemu dziedzinowego, dostawcami systemów laboratoryjnych i obrazowych, serwisem aparatury, firmą obsługującą infrastrukturę sieciową oraz dostawcami usług chmurowych. Każdy z nich to osobny punkt wejścia do sieci.
Sektor ochrony zdrowia wyróżnia się pod tym względem liczbą wyspecjalizowanych kontrahentów. Żadna inna branża nie kupuje tylu systemów od tylu producentów, a jednocześnie łączy w jednej sieci sprzęt medyczny, oprogramowanie kliniczne i systemy administracyjne.
Z tej struktury wynikają trzy utrudnienia praktyczne. Systemy rzadko pochodzą od jednego producenta, bo placówka kupuje je w różnych latach i na różnych warunkach. Pracy nie da się zatrzymać, więc każda zmiana dostawcy oznacza ryzyko przerwy w świadczeniu usług. A rozliczenia prowadzone z budżetu rocznego ograniczają elastyczność przy renegocjacji umów.

Czym ta weryfikacja różni się od wyboru firmy wdrażającej?

To dwie różne decyzje, podejmowane w innym momencie i przez inne osoby. Wybór firmy wdrażającej dotyczy partnera doradczego, który przeprowadzi placówkę przez cały proces. Kryteria takiego wyboru zebraliśmy w osobnym tekście o tym, jak wybrać firmę do wdrożenia NIS 2.
Niniejsza checklista dotyczy czegoś innego: oceny podmiotów dostarczających oprogramowanie i sprzęt, z którymi szpital już współpracuje albo właśnie podpisuje umowę. Decyzję podejmuje zwykle dział zamówień we współpracy z działem informatycznym, a nie zarząd.
Zakres jest przy tym szerszy, niż sugeruje nazwa. Obejmuje nie tylko producentów systemów medycznych, lecz także dostawców usług cyfrowych: hostingu, poczty i archiwizacji. Odmienny jest również rezultat. Nie wybór doradcy, lecz zestaw zapisów w specyfikacji warunków zamówienia, które podmiot kluczowy powinien mieć w każdej umowie dotyczącej systemów krytycznych.

analiza dostawców oprogramowania dla szpitala NIS 2

ZOBACZ RÓWNIEŻ:

Co sprawdzić przed podpisaniem lub przedłużeniem umowy? 7 punktów

Poniższa checklista pozwala ustalić, czy dostawca systemu medycznego zgodny z NIS 2 rzeczywiście stoi za deklaracją w ofercie. Pytania warto zadać każdemu dostawcy mającemu dostęp do systemów placówki. Odpowiedzi najlepiej uzyskać na piśmie, ponieważ w postępowaniu zakupowym mają wtedy wartość dowodową. Prośba o odpowiedź na piśmie nie wiąże się z żadnym dodatkowym kosztem, a znacząco zmienia wartość uzyskanej informacji.

1. Czy dostawca posiada certyfikat ISO 27001 lub równoważny?

Certyfikat nie jest wymogiem ustawowym, ale stanowi najprostszy sygnał, że system zarządzania bezpieczeństwem informacji funkcjonuje u dostawcy w sposób udokumentowany. Brak certyfikatu nie dyskwalifikuje. Wtedy jednak warto poprosić o opis stosowanych procedur i zapytać, kto po stronie kontrahenta odpowiada za bezpieczeństwo informacji. Zarządzanie bezpieczeństwem informacji u dostawcy powinno mieć przypisanego właściciela, a nie funkcjonować jako zadanie poboczne.

Wskazówka Coongi: Certyfikat bywa wystawiony na spółkę matkę albo obejmuje wyłącznie wybrany zakres działalności. Warto sprawdzić, czy obejmuje faktycznie tę usługę, którą placówka medyczna kupuje. Bezpieczeństwo informacji potwierdzone certyfikatem dla innego zakresu nie mówi nic o systemie dziedzinowym, a to on decyduje o bezpieczeństwie systemów klinicznych.

2. Czy umowa gwarantuje czas reakcji na incydent bezpieczeństwa?

Szpital ma sztywne terminy na zgłaszanie incydentów do właściwego zespołu CSIRT, liczone od momentu wykrycia. Jeżeli incydent powstał po stronie dostawcy, a placówka dowiaduje się o nim po tygodniu, dotrzymanie terminu jest niemożliwe.
Przepisy nie przewidują wydłużenia terminu z powodu opieszałości kontrahenta. Umowa powinna więc określać, w jakim czasie dostawca informuje o zdarzeniu dotyczącym jego infrastruktury lub dostarczanego oprogramowania. Bez tego obowiązek szpitala jest niewykonalny z przyczyn, na które szpital nie ma wpływu.

3. Czy aktualizacje bezpieczeństwa obejmują cały okres umowy?

Scenariusz spotykany w placówkach wygląda tak: umowa na system została zawarta kilka lat temu, obejmuje utrzymanie i jest regularnie opłacana. Dział informatyczny zgłasza potrzebę poprawki bezpieczeństwa i otrzymuje odpowiedź, że aktualizacje objęte były okresem gwarancji, który już się zakończył.
W takiej sytuacji nikt nikogo nie wprowadził w błąd. Umowa była czytana pod kątem dostępności systemu i kosztu utrzymania, a nie pod kątem tego, czy poprawki bezpieczeństwa mają osobny termin. To najczęstsza luka w umowach zawieranych przed wejściem nowych przepisów.

Przy aparaturze medycznej problem jest większy, bo cykl życia takich urządzeń sięga kilkunastu lat, czyli dwóch lub trzech zmian standardów bezpieczeństwa. Warto więc ustalić, do kiedy producent deklaruje wsparcie i co stanie się po tej dacie.
Odpowiedź ma bezpośrednie znaczenie dla kosztu. Urządzenia pozbawione poprawek wymagają wydzielenia w osobnym segmencie sieci, a to podnosi koszt utrzymania infrastruktury  i ten koszt warto uwzględnić już przy ocenie oferty, nie po zakupie.

4. Czy dostęp serwisowy jest szyfrowany i ograniczony czasowo?

Stałe, otwarte połączenie zdalne jest wygodne dla serwisu i kosztowne dla placówki. Standardem powinien być dostęp aktywowany na czas wykonania konkretnej czynności, prowadzony przez szyfrowany kanał, z uwierzytelnianiem wieloskładnikowym i zapisem w dzienniku zdarzeń. Dotyczy to zarówno dostawców ważnych systemów klinicznych, jak i firm obsługujących systemy IT obszaru wsparcia.

Wskazówka Coongi: Pytanie kontrolne brzmi: czy placówka jest w stanie odtworzyć, kto i kiedy łączył się z jej systemami w ostatnim kwartale. Jeśli odpowiedź brzmi „nie”, zarządzanie ryzykiem w tym obszarze nie istnieje. Bezpieczeństwo systemów zależy tu wprost od tego, czy dostęp jest rejestrowany.

5. Czy dostawca przekaże listę komponentów oprogramowania?

Wykaz komponentów zewnętrznych, znany jako SBOM, pozwala szybko ustalić, czy dostarczane oprogramowanie zawiera bibliotekę, w której właśnie wykryto podatność. Bez takiej listy każda informacja o nowej luce oznacza tygodnie ustalania, czy dotyczy systemów placówki. Dostawcy ważnych systemów powinni prowadzić taki wykaz na bieżąco, bo bez niego incydenty bezpieczeństwa danych wykrywa się z opóźnieniem.
Nie każdy dostawca będzie w stanie ją przekazać i nie zawsze jest to powód do odrzucenia oferty. Sposób odpowiedzi na to pytanie dużo jednak mówi o dojrzałości procesów wytwórczych kontrahenta. Dostawcy usług cyfrowych działający w modelu chmurowym radzą sobie z tym zwykle lepiej niż producenci oprogramowania instalowanego lokalnie.

6. Czy umowa daje prawo weryfikacji zabezpieczeń?

Klauzula pozwalająca szpitalowi lub wskazanemu przez niego podmiotowi sprawdzić stosowane środki bezpieczeństwa bywa pomijana, a bez niej weryfikacja opiera się wyłącznie na dobrej woli kontrahenta. Nie chodzi o przeprowadzanie audytu u każdego dostawcy, a jedynie o możliwość, z której placówka skorzysta wtedy, gdy pojawi się konkretna wątpliwość.
Samo istnienie takiego zapisu zmienia pozycję negocjacyjną, nawet jeśli nigdy nie zostanie wykorzystany. Bez niego szpital nie ma żadnego narzędzia nacisku poza wypowiedzeniem umowy, czyli środkiem, którego przy systemie dziedzinowym praktycznie nie da się użyć.
Warto przy tym rozważyć wystąpienie wspólne. Podmioty medyczne z jednego regionu, korzystające od tego samego dostawcy, mają zbieżny interes i uzyskują zwykle lepsze warunki niż każda placówka osobno, zwłaszcza gdy łączy je wspólny organ tworzący.

7. Czy opisana jest procedura wyjścia i zwrotu danych?

Zakończenie współpracy jest momentem najwyższego ryzyka dla ciągłości działania. Umowa powinna określać, w jakim formacie i w jakim terminie dostawca przekaże dane medyczne oraz jakie wsparcie zapewni przy migracji.
Stawka jest tu wymierna. Dane przekazane w formacie zamkniętym są w praktyce nieprzenośne, a ich ponowne wprowadzenie kosztuje więcej niż cała migracja. Bez takiego zapisu szpital jest związany z kontrahentem faktycznie, choć nie formalnie, a zarządzanie ryzykiem oznacza tutaj przewidzenie scenariusza zakończenia współpracy jeszcze przed jej rozpoczęciem.

Wskazówka Coongi: Jedno pismo do wszystkich kontrahentów zamiast siedmiu rozmów. Warto wysłać identyczne zapytanie do wszystkich podmiotów mających dostęp do systemów placówki, obejmujące powyższe siedem punktów. Przygotowanie zajmuje kilka godzin, a odpowiedzi dają gotową mapę ryzyka w łańcuchu dostaw. Brak odpowiedzi jest w tym przypadku informacją równie wartościową jak odpowiedź szczegółowa.

Jak zapisać wymagania NIS 2 w specyfikacji zamówienia?

Poniższe zapisy można wykorzystać jako punkt wyjścia przy przygotowaniu specyfikacji. Wymagają dostosowania do konkretnego postępowania, ale porządkują zakres cyberbezpieczeństwa oczekiwany od wykonawcy. Szersze omówienie zmian w dokumentacji zakupowej znajduje się we wpisie o NIS 2 w szpitalu po podpisie Prezydenta.

Obszar
Proponowany zapis
Aktualizacje
Wykonawca zapewni dostarczanie poprawek bezpieczeństwa dla oferowanego oprogramowania przez cały okres obowiązywania umowy, niezależnie od okresu gwarancji.
Zgłaszanie incydentów
Wykonawca poinformuje Zamawiającego o incydencie bezpieczeństwa dotyczącym oferowanego systemu lub infrastruktury Wykonawcy niezwłocznie, nie później niż w terminie 24 godzin od jego wykrycia.
Dostęp serwisowy
Dostęp zdalny realizowany będzie przez szyfrowane połączenie, z uwierzytelnianiem wieloskładnikowym, aktywowane wyłącznie na czas czynności serwisowej i rejestrowane w dzienniku zdarzeń.
Komponenty
Wykonawca przekaże wykaz komponentów zewnętrznych wykorzystanych w oferowanym oprogramowaniu wraz z wersjami oraz będzie go aktualizował przy każdej istotnej zmianie.
Prawo weryfikacji
Zamawiający zastrzega prawo weryfikacji środków bezpieczeństwa stosowanych przez Wykonawcę, samodzielnie lub przez wskazany podmiot, po uprzednim powiadomieniu.
Procedura wyjścia
Wykonawca przekaże dane w ustandaryzowanym, możliwym do odczytu formacie w terminie określonym w umowie oraz zapewni wsparcie przy migracji do innego rozwiązania.

Zapisy warto konsultować z radcą prawnym placówki, ponieważ ich brzmienie musi odpowiadać przepisom o zamówieniach publicznych. Podmioty publiczne mają tu mniej swobody niż placówki działające jako spółki. Sama treść merytoryczna pozostaje jednak taka sama niezależnie od trybu postępowania, bo wynika z tego, czego wymaga dyrektywa NIS 2, a nie z przepisów zakupowych.

Co zrobić, jeśli obecny dostawca nie spełnia warunków NIS 2?

W praktyce dzieje się tak: po przejściu powyższej checklisty okazuje się, że dostawca systemu dziedzinowego nie spełnia czterech albo pięciu z siedmiu punktów. Pierwszy odruch jest zrozumiały. Skoro nie spełnia wymogów, trzeba rozwiązać umowę i poszukać kogoś innego.
To zwykle najgorsze z dostępnych rozwiązań. Wypowiedzenie umowy z dostawcą systemu dziedzinowego oznacza migrację dokumentacji medycznej, przeszkolenie całego personelu i miesiące pracy. W efekcie koszt i ryzyko wyższe niż samo ryzyko, które miało zostać ograniczone. Przepisy zresztą tego nie wymagają: oczekują udokumentowanego zarządzania ryzykiem, nie zmiany kontrahenta.
Praktyczna sekwencja wygląda inaczej. Najpierw ustala się, którzy dostawcy mają dostęp do systemów krytycznych dla ciągłości leczenia, a którzy wyłącznie do obszarów wspierających. Kluczowe systemy wymagają ostrzejszych warunków niż systemy informatyczne obsługujące administrację. Następnie ryzyko związane z tymi pierwszymi ogranicza się środkami po stronie placówki: wydzieleniem połączeń serwisowych, rejestrowaniem sesji i ograniczeniem uprawnień do niezbędnego minimum. Dopiero na końcu wprowadza się zapisy umowne.
Podmiot kluczowy ma przy tym silniejszą pozycję niż podmiot ważny, bo obowiązki wobec organu nadzoru są szersze i łatwiej je przywołać w negocjacjach. Przedłużenie umowy jest przy tym momentem najtańszym: pozwala wprowadzić klauzule bezpieczeństwa bez uruchamiania osobnego postępowania, a pozycja negocjacyjna szpitala jest wtedy najmocniejsza, bo dostawca chce utrzymać kontrakt.

Jak rozłożyć weryfikację kilkunastu dostawców w czasie?

Sprawdzenie kilkunastu kontrahentów naraz jest niewykonalne przy typowej obsadzie działu zamówień w szpitalu. Kolejność wyznacza krytyczność systemu, a nie wielkość kontraktu. Bezpieczeństwo systemów klinicznych ma tu pierwszeństwo przed wygodą rozliczeń, ponieważ od nich zależy bezpośrednio praca oddziałów, a od systemów administracyjnych wyłącznie pośrednio.

  • Najpierw dostawcy systemów, których niedostępność zatrzymuje leczenie: system dziedzinowy oraz systemy laboratoryjne i obrazowe. Dla tej grupy placówka nie ma alternatywy w razie awarii, dlatego wymaga ona najostrzejszych warunków umownych.
  • Następnie podmioty z dostępem zdalnym do infrastruktury sieciowej, nawet jeśli ich umowy mają niewielką wartość.
  • Następnie dostawcy usług chmurowych przetwarzający dane poza infrastrukturą placówki. Tutaj ochrona danych pacjentów zależy wprost od warunków umowy powierzenia, ponieważ część odpowiedzialności przechodzi na kontrahenta. Ta grupa bywa pomijana w rejestrach, bo umowy zawiera się czasem poza działem zamówień.
  • Na końcu systemy informacyjne obszaru administracyjnego, o ile nie przetwarzają dokumentacji medycznej. Skutki incydentu są tam mniej dotkliwe, ale warto ująć je w rejestrze, bo zwykle łączą się z siecią kliniczną, a wszystkie systemy placówki tworzą jedną powierzchnię ataku.

Taki podział pozwala rozłożyć pracę na kilka kwartałów i powiązać ją z kalendarzem przedłużania umów, zamiast prowadzić jedną dużą akcję weryfikacyjną. Wdrożenie systemów kontroli dostępu po stronie placówki warto prowadzić równolegle, bo skraca listę spraw do wynegocjowania.

Kto w szpitalu odpowiada za weryfikację dostawców?

Ustalenie, czy dostawca systemu medycznego zgodny z NIS 2 spełnia deklarowane warunki, wymaga współpracy kilku komórek. Formalnie odpowiada kierownictwo podmiotu, ponieważ to na nim spoczywają obowiązki wynikające z przepisów. Praktycznie zadanie wymaga współpracy trzech stron: działu zamówień, który prowadzi postępowanie, działu informatycznego, który ocenia treść odpowiedzi, oraz radcy prawnego, który przekłada wymagania na zapisy umowne.
Przykład z praktyki. Zapytanie z 7 punktami zostało wysłane do wszystkich kontrahentów, odpowiedzi przyszły, dokumentacja postępowania jest kompletna. Dział zamówień odnotowuje, że wymagane dokumenty wpłynęły, i przechodzi do kolejnego etapu.
Nikt natomiast nie ocenił treści. Odpowiedź w rodzaju „stosujemy branżowe standardy bezpieczeństwa” formalnie odpowiada na pytanie o zabezpieczenia, a merytorycznie nie mówi nic i tej różnicy nie wychwyci osoba bez przygotowania technicznego.
Najczęstszy błąd polega więc na pozostawieniu tego zadania wyłącznie działowi zamówień. Nie wynika on z niedbalstwa, lecz z podziału kompetencji: dział zamówień odpowiada za kompletność postępowania, a nie za ocenę rozwiązań technicznych. Nowe obowiązki dotyczące cyberbezpieczeństwa wymagają tu współpracy, a nie podziału zadań.

Warto też ustalić, kto aktualizuje listę kontrahentów i jak często jest przeglądana. Rejestr sporządzony raz i niezmieniany przez rok przestaje odzwierciedlać stan faktyczny, a incydenty bezpieczeństwa danych zdarzają się najczęściej u kontrahentów, o których nikt już nie pamięta. Sposób powiązania tego zadania z pozostałymi etapami opisaliśmy na stronie poświęconej wdrożeniu NIS 2 w szpitalu.

Najczęściej zadawane pytania

Czy szpital może zerwać umowę z dostawcą niezgodnym z NIS 2?

Zależy od zapisów obowiązującej umowy. Samo powołanie się na przepisy zwykle nie wystarczy. Skuteczniejszym rozwiązaniem jest wdrożenie systemów kontroli po stronie placówki oraz wprowadzenie klauzul bezpieczeństwa przy najbliższym przedłużeniu współpracy. Środki bezpieczeństwa zastosowane lokalnie działają szybciej niż negocjacje.

Kto w szpitalu formalnie odpowiada za weryfikację dostawców?

Nie. Etapy następują po sobie, a trzeci z nich dzieli się na trzy równoległe ścieżki: procedury, technikę i szkolenia. Poszczególne obszary można wdrażać partiami, według ryzyka. Warunkiem jest osiągnięcie wymaganego stanu przed upływem terminu ustawowego.

Czy małe, lokalne firmy IT też muszą spełniać te wymogi?

Wymogi obciążają szpital jako podmiot kluczowy lub ważny, a nie kontrahenta, więc dotyczą każdej firmy z dostępem do systemów (niezależnie od jej wielkości). Mniejsze firmy często nie mają certyfikatów, ale bywają bardziej elastyczne przy wprowadzaniu zapisów umownych dotyczących dostępu serwisowego. W sektorze usług cyfrowych dla ochrony zdrowia działa wiele takich podmiotów.

Czy dostawca musi przedstawić certyfikat potwierdzający zgodność z NIS 2?

Nie. Obowiązki raportowe działają niezależnie od postępu prac: wczesne ostrzeżenie trafia do CSIRT w ciągu 24 godzin od wykrycia incydentu poważnego. Dlatego procedurę zgłoszenia ustala się na samym początku, a nie na końcu projektu.

Od czego zacząć, jeśli do terminu zostało kilka miesięcy?

Taki certyfikat nie istnieje, ponieważ przepisy nie przewidują certyfikacji podmiotów. Weryfikację prowadzi podmiot kluczowy we własnym zakresie, a system cyberbezpieczeństwa placówki musi tę weryfikację udokumentować. Weryfikacja polega na sprawdzeniu konkretnych zobowiązań: aktualizacji, zasad dostępu, terminów informowania o incydentach oraz gotowości do poddania się kontroli.

Relacje z dostawcami warto uporządkować przed kontrolą

Bezpłatny audyt zero obejmuje przegląd dostępów serwisowych i umów z kontrahentami. Trwa 1–2 godziny i kończy się listą priorytetów wskazującą, które relacje wymagają uporządkowania w pierwszej kolejności.

Bezpłatny audyt zero
Bezpłatny audyt zero