Ocena ryzyka w systemach IT — jak analityk bez doświadczenia przeszedł przez pierwszy audyt

Kamil Baranowski pracuje jako analityk ryzyka w firmie tworzącej oprogramowanie dla sektora finansowego.

Jego pierwsze samodzielne zadanie to ocena ryzyka dla trzech kluczowych systemów wewnętrznych przed wdrożeniem ISO 27001. Ma do dyspozycji dwa miesiące, dostęp do dokumentacji technicznej i teoretyczne przygotowanie ze studiów. Nie ma dostępu do kodu ani uprawnień administratora — ocenia ryzyko jako obserwator zewnętrzny wobec zespołów developerskich.

Jak zaczął, gdy nie wiedział od czego zacząć

Kamil przyznaje, że przez pierwsze dni siedział z dokumentacją techniczną i czuł się przytłoczony ilością informacji bez jasnego kontekstu.

Przełom nastąpił, gdy zamiast czytać wszystko po kolei, wybrał podejście odwrócone: zaczął od listy aktywów informacyjnych i dla każdego z nich zadał jedno pytanie — co się stanie, jeśli ten zasób stanie się niedostępny, zostanie zmodyfikowany bez wiedzy firmy lub trafi do nieautoryzowanej osoby. Te trzy pytania zastąpiły mu teoretyczną ramę CIA — poufność, integralność, dostępność — i nadały pracy konkretny kierunek.

Co działało w jego podejściu

1. Odwrócona analiza od skutku do przyczyny pozwoliła szybciej zidentyfikować zagrożenia krytyczne.
2. Praca z dokumentacją techniczną była efektywna, bo Kamil mógł weryfikować dane bez presji czasowej rozmów grupowych.
3. Pisemne pytania wysyłane do deweloperów przed rozmową dawały czas obu stronom na przygotowanie.
4. Skupienie na trzech kluczowych systemach zamiast próby objęcia całej organizacji dało wiarygodne wyniki.

Co nie działało lub było trudne

1. Deweloperzy często opisywali ryzyko jako niskie, bo rozumieli jak system działa — nie rozumieli kontekstu biznesowego konsekwencji awarii.
2. Brak uprawnień do testowania systemów uniemożliwiał weryfikację deklarowanych zabezpieczeń.
3. Ocena ryzyka bez narzędzia do śledzenia była chaotyczna — arkusz Excel szybko stał się nieczytelny.

Rozmowy z programistami — najtrudniejszy element

Kamil opisuje spotkania z zespołem deweloperskim jako największe wyzwanie nie merytoryczne, ale komunikacyjne.

Programiści reagowali obronnie na pytania o luki, interpretując je jako krytykę swojej pracy. Kamil zmienił taktykę — zamiast pytać co jest niezabezpieczone, pytał o sytuacje, kiedy musieli improwizować rozwiązanie problemu technicznego na szybko. Te rozmowy ujawniły więcej realnych ryzyk niż bezpośrednie pytania o bezpieczeństwo.

Pytanie o problem często uruchamia mechanizmy obronne. Pytanie o historię zdarzenia uruchamia pamięć.

Wnioski po zakończeniu audytu

Raport końcowy zawierał dwadzieścia dwa zidentyfikowane ryzyka, z których siedem zostało ocenionych jako wymagające natychmiastowego działania.

Kamil przyznaje, że najtrudniejsze było prezentowanie wyników zarządowi — nie dlatego, że materiał był słaby, ale dlatego, że pytania padały nieuporządkowanie i trzeba było odpowiadać spontanicznie. Na kolejny audyt przygotował listę pytań, które spodziewał się usłyszeć, i wcześniej przemyślał odpowiedzi. To zmieniło dynamikę spotkania.