Rozmowa o polisie cyber często zaczyna się od ankiety, listy zabezpieczeń i pytań o procedury, których firma wcześniej nie musiała formalnie opisywać. Nagle trzeba wskazać, gdzie znajdują się dane, kto ma dostęp administracyjny, jak działa kopia zapasowa i czy istnieje plan reakcji na incydent. W takim momencie audyt systemów informatycznych przestaje być technicznym przeglądem, a staje się narzędziem uporządkowania odpowiedzialności.
Problem nie polega wyłącznie na tym, czy firma ma zaporę sieciową, antywirusa i backup. Ważniejsze jest to, czy potrafi udowodnić, że zabezpieczenia są aktualne, działają zgodnie z założeniami i obejmują właściwe obszary. Bez takiej wiedzy rozmowa o ryzyku cybernetycznym opiera się na deklaracjach, a nie na realnym obrazie środowiska IT.
Audyt systemów informatycznych zaczyna się od zakresu
Pierwszym krokiem nie jest skanowanie urządzeń ani tworzenie długiej listy technicznych zaleceń. Najpierw trzeba ustalić, co faktycznie ma zostać objęte oceną. W wielu firmach systemy są rozproszone pomiędzy biurem, chmurą, serwerownią, komputerami pracowników, aplikacjami branżowymi i usługami zewnętrznymi. Część z nich obsługuje sprzedaż, część księgowość, część produkcję, magazyn lub komunikację z klientami.
Jeżeli zakres nie zostanie ustalony na początku, łatwo pominąć usługę, która nie jest widoczna na co dzień, ale ma duże znaczenie dla ciągłości pracy. Może to być system do wymiany plików z klientami, konto administracyjne do domeny, panel hostingu, zdalny dostęp serwisowy albo aplikacja wykorzystywana tylko przez jeden dział.
- które systemy są krytyczne dla obsługi klientów, sprzedaży i rozliczeń,
- gdzie przechowywane są dane osobowe, finansowe i operacyjne,
- kto odpowiada za konfigurację usług lokalnych i chmurowych,
- które elementy infrastruktury są utrzymywane przez dostawców zewnętrznych,
- jakie procesy firmowe zatrzymają się po niedostępności danego systemu.
1. Dokumentacja nie pokazuje rzeczywistego stanu IT
Jednym z najczęstszych objawów jest rozbieżność między tym, co firma uważa za swoją infrastrukturę, a tym, co faktycznie działa. W dokumentach widnieją stare serwery, nieaktualne adresy, dawne konta administratorów albo usługi, które zostały przeniesione do chmury bez aktualizacji opisu. Czasami dokumentacji nie ma wcale, a wiedza o środowisku znajduje się u jednej osoby lub w wiadomościach e-mail sprzed kilku lat.
Skutek biznesowy jest prosty: w razie incydentu firma traci czas na ustalanie podstaw. Zamiast od razu ograniczać skutki problemu, trzeba szukać haseł, właścicieli systemów, kontaktów do dostawców i informacji o zależnościach. Dla ubezpieczyciela, audytora lub zarządu jest to sygnał, że kontrola nad środowiskiem ma charakter reaktywny.
2. Dostępy administracyjne są zbyt szerokie
Polisa cyber często wymusza pytania o konta uprzywilejowane, logowanie wieloskładnikowe i zasady nadawania uprawnień. W praktyce właśnie ten obszar ujawnia wiele zaniedbań. Administratorzy korzystają ze wspólnych kont, byli pracownicy nadal mają dostęp do paneli, a zewnętrzni dostawcy posiadają uprawnienia, które nie były weryfikowane po zakończeniu projektu.
Przyczyną bywa wygoda operacyjna. Konto z szerokimi uprawnieniami pozwala szybko rozwiązać problem, ale jednocześnie utrudnia ustalenie, kto wykonał zmianę i czy była ona uzasadniona. Audyt systemów informatycznych powinien sprawdzić nie tylko listę kont, lecz także proces ich tworzenia, odbierania i przeglądania.
- czy każde konto administracyjne jest przypisane do konkretnej osoby lub roli,
- czy dostęp zewnętrznych wykonawców jest ograniczony zakresem prac,
- czy logowanie do usług krytycznych wymaga dodatkowego potwierdzenia,
- czy odejście pracownika uruchamia zamknięcie dostępów,
- czy firma potrafi odtworzyć historię ważnych zmian konfiguracyjnych.
3. Backup istnieje, ale nie wiadomo, co można odtworzyć
W ankietach dotyczących ryzyka cybernetycznego pytanie o kopie zapasowe pojawia się niemal zawsze. Odpowiedź „backup jest wykonywany” nie wystarcza, jeżeli firma nie wie, jakie dane obejmuje, jak długo są przechowywane i ile potrwa ich przywrócenie. Różnica między kopią plików a możliwością odtworzenia całego procesu biznesowego bywa bardzo duża.
Objawem słabego przygotowania jest brak testów odtwarzania. System raportuje powodzenie zadań backupu, ale nikt nie sprawdza, czy z kopii można przywrócić konkretną bazę, skrzynkę pocztową, katalog projektu lub konfigurację aplikacji. W razie awarii może się okazać, że dane są niekompletne, wersje nieaktualne, a czas odtworzenia dłuższy niż firma zakładała.
4. Procedury incydentu są zbyt ogólne
Wiele firm posiada ogólne zapisy o zgłaszaniu awarii, ale nie ma praktycznej procedury na sytuację podejrzenia włamania, zaszyfrowania danych, przejęcia poczty lub utraty urządzenia. Brakuje informacji, kto podejmuje decyzję o odłączeniu systemu, kto kontaktuje się z dostawcą IT, kto informuje zarząd i kto ocenia wpływ zdarzenia na klientów oraz dane osobowe.
Taka luka organizacyjna wydłuża reakcję. Użytkownicy czekają na instrukcje, managerowie próbują ustalić odpowiedzialność, a zespół techniczny działa pod presją bez jasnego priorytetu. Procedura nie musi być rozbudowana, ale powinna odpowiadać na najważniejsze pytania operacyjne: co zatrzymać, kogo powiadomić, jakie dowody zachować i kiedy przywracać pracę.
5. Dostawcy IT są częścią ryzyka
W środowisku MŚP wiele elementów infrastruktury jest utrzymywanych przez zewnętrznych wykonawców. Dotyczy to hostingu, poczty, systemów biznesowych, serwerów, sieci, monitoringu, backupu i wsparcia użytkowników. To naturalny model pracy, ale wymaga kontroli zakresu odpowiedzialności. Firma powinna wiedzieć, kto za co odpowiada i jakie są zasady reakcji podczas incydentu.
Brak takiej kontroli powoduje, że podczas problemu kilka podmiotów wzajemnie odsyła zgłoszenie. Dostawca aplikacji wskazuje na sieć, administrator sieci na usługę chmurową, a hosting na konfigurację strony. Przed zawarciem polisy cyber warto sprawdzić umowy, kontakty serwisowe, poziomy dostępu oraz sposób zgłaszania incydentów. W tym zakresie pomocny może być przegląd realizowany w ramach audytu, consultingu i bezpieczeństwa IT.
Co powinno zostać po audycie
Dobry audyt nie kończy się wyłącznie listą błędów. Firma powinna otrzymać uporządkowany obraz środowiska, priorytety działań i wskazanie ryzyk, które mają największy wpływ na pracę organizacji. Ważne jest rozróżnienie między problemami krytycznymi, zaleceniami porządkowymi i zmianami, które można zaplanować w dłuższym czasie.
- mapa kluczowych systemów i zależności,
- lista kont administracyjnych i obszarów wymagających ograniczenia dostępu,
- ocena backupu oraz możliwości odtworzenia danych,
- wykaz braków w procedurach incydentów,
- rekomendacje dotyczące współpracy z dostawcami usług IT,
- plan działań podzielony według wpływu na bezpieczeństwo i ciągłość pracy.
Audyt systemów informatycznych przed rozmową o polisie cyber pozwala uniknąć deklaracji bez pokrycia. Ujawnia miejsca, w których technologia, procedury i odpowiedzialność nie tworzą jeszcze spójnego systemu. Dla firmy oznacza to lepsze przygotowanie do oceny ryzyka, ale przede wszystkim większą kontrolę nad własną infrastrukturą przed wystąpieniem incydentu.
