Wyobraź sobie, że właśnie doszło do incydentu. Organ nadzorczy zadaje pytania: Kto i kiedy miał dostęp do danych? Które konto zostało użyte? Kiedy hasło było ostatnio zmieniane i przez kogo?
Większość organizacji odpowiada: nie wiemy. Nie dlatego, że coś ukrywają – po prostu nigdy tego nie rejestrowały.
To scenariusz, który w kontekście rosnących wymagań regulacyjnych (RODO, NIS2) i zaostrzonych uprawnień organów kontrolnych staje się coraz bardziej kosztowny. Nie chodzi tu o formalny brak dokumentacji, tylko o lukę między deklarowanym poziomem bezpieczeństwa, a zdolnością do jego wykazania w momencie, gdy jest ona rzeczywiście weryfikowana.
Rozliczalność w cyberbezpieczeństwie nie jest wyłącznie wymogiem prawnym. To kwestia operacyjną – jej źródłem jest kontrola. Tam, gdzie kontroli nie ma, rozliczalność jest niemożliwa – niezależnie od liczby polityk bezpieczeństwa w szufladzie.
Regulacje wymagają twardych dowodów
RODO: administrator musi wykazać, nie tylko deklarować
Artykuł 5 ust. 2 RODO formułuje zasadę rozliczalności wprost: administrator jest odpowiedzialny za przestrzeganie przepisów i musi być w stanie wykazać ich przestrzeganie. Nie zadeklarować czy opisać w polityce. Wykazać, czyli przedstawić dowód.
W praktyce oznacza to, że samo wdrożenie środków bezpieczeństwa jest niewystarczające. Jak wskazuje analiza zasady rozliczalności, rozliczalność składa się z dwóch obowiązków: wdrożenia środków gwarantujących przestrzeganie przepisów oraz sporządzenia dokumentacji, która pozwala wykazać, jakie środki podjęto. Jeden bez drugiego nie spełnia wymogu.
Co istotne, RODO nie wskazuje jednej, narzuconej metody realizacji tej zasady. Daje elastyczność, ale działa ona w obie strony: organizacja sama musi dobrać adekwatne środki, a w razie kontroli uzasadnić ich wybór i skuteczność.
NIS2 i UoKSC: zarządzanie dostępem jako środek techniczny i organizacyjny
Nowelizacja Ustawy o Krajowym Systemie Cyberbezpieczeństwa, która weszła w życie 2 kwietnia 2026 roku, wdraża dyrektywę NIS2 do polskiego porządku prawnego. Podmioty kluczowe i ważne mają 12 miesięcy na dostosowanie systemów i procedur. Termin upływa 2 kwietnia 2027 roku.
Wśród wymaganych środków technicznych i organizacyjnych UoKSC wymienia wprost: zapewnienie odpowiedniej kontroli dostępu i uwierzytelniania dwuskładnikowego, monitorowanie systemów, zarządzanie incydentami oraz stosowanie narzędzi klasy SIEM i EDR. Podmioty kluczowe zobowiązane są do przeprowadzania audytu bezpieczeństwa nie rzadziej niż co 3 lata. W przypadku poważnego incydentu organ właściwy może nakazać audyt ad hoc również podmiotowi ważnemu.
Raportowanie incydentów jest ściśle określone czasowo. Wstępne zgłoszenie do właściwego CSIRT w ciągu 24 godzin od wykrycia, sprawozdanie końcowe w ciągu miesiąca od zakończenia obsługi. Aby dotrzymać tych terminów, organizacja musi mieć natychmiastowy dostęp do informacji o tym, co się wydarzyło. Nie ma tu czasu na ręczne rekonstruowanie zdarzeń z pamięci pracowników.
Luka między polityką bezpieczeństwa a rzeczywistością
Polityka bezpieczeństwa istnieje, a historii dotyczącej dostępów brak
Większość organizacji posiada „papierową” politykę bezpieczeństwa. Znacznie mniej posiada coś, co ma realną wartość w momencie incydentu: historię operacyjną. Rejestr tego, kto, kiedy i do czego miał dostęp, kiedy hasła były zmieniane, komu były przekazywane uprawnienia i kiedy je cofnięto.
Polityka bezpieczeństwa opisuje, jak powinno być. Historia operacyjna dokumentuje, jak było. W toku kontroli organ nadzorczy weryfikuje to drugie. Dokument opisujący zasady polityki haseł nie zastąpi logu potwierdzającego, że standard był utrzymywany.
Współdzielone konta i hasła przekazywane e-mailem uniemożliwiają rozliczalność
Dokumentacja uprawnień i dostępów pełni ważną rolę dowodową. W przypadku naruszenia pozwala szybko ustalić, kto miał dostęp do danych w danym czasie. To warunek skutecznego dochodzenia i reakcji na incydent.
Tymczasem praktyki takie jak współdzielone konta, hasła przekazywane przez e-mail lub komunikatory, dostępy zarządzane nieformalnie utrudniają tę możliwość. Gdy kilka osób loguje się na to samo konto z tym samym hasłem, ustalenie, kto wykonał konkretną operację w konkretnym momencie, jest niemożliwe.
„Kto się logował?” – pytanie bez odpowiedzi
Incydent bezpieczeństwa uruchamia sekwencję pytań, na które organizacja musi być w stanie odpowiedzieć szybko i precyzyjnie: które konto zostało użyte? Czy dane logowania były unikalne dla konkretnej osoby? Kiedy ostatnio zmieniano hasło do tego konta? Czy dostęp do systemu był ograniczony do osób uprawnionych? Czy po odejściu pracownika dostęp został cofnięty?
Każde z tych pytań wymaga danych operacyjnych – nie deklaracji. Organizacja, która nie potrafi na nie odpowiedzieć, nie tylko ma problem z wykazaniem rozliczalności, lecz także z ograniczeniem skutków incydentu, ponieważ nie wie, jaki był jego faktyczny zakres.
Kontrola nad dostępami jako fundament, a nie wymóg formalny
Kontrola nad dostępami i hasłami jest przede wszystkim elementem bezpieczeństwa operacyjnego i to właśnie z tego bezpieczeństwa wynika jej wartość regulacyjna, a nie odwrotnie. Organizacja, która wie, kto ma dostęp do czego, może szybko zareagować na incydent, ograniczyć jego zakres i udokumentować podjęte działania. Organizacja, która tej wiedzy nie ma, reaguje wolniej, rekonstruuje zdarzenia z pamięci uczestników i nie jest w stanie wiarygodnie wykazać, co faktycznie się wydarzyło.
Centralne zarządzanie tożsamością
Centralne repozytorium danych logowania, w którym każdy dostęp jest przypisany do konkretnego użytkownika, każde udostępnienie jest rejestrowane, a każde cofnięcie uprawnień jest natychmiastowe i udokumentowane, tworzy historię operacyjną, której nie da się odtworzyć w żaden inny sposób.
W kontekście rozliczalności kluczowe jest to, że ta historia powstaje jako naturalny efekt prawidłowego zarządzania dostępami – nie jako dodatkowy wysiłek dokumentacyjny. Organizacja, która centralnie zarządza dostępami z menedżerem haseł, w momencie kontroli może wskazać: kiedy konto zostało utworzone, kto miał do niego dostęp, kiedy dostęp był modyfikowany, kiedy hasło było zmieniane i przez kogo.
https://percpass.com/jak-menedzer-hasel-wpisuje-sie-w-wymagania-nis2/
Menedżer haseł w organizacji
Menedżer haseł perc.pass to narzędzie, które zmienia papierowe deklaracje w dowody operacyjne. Dokumentacja działań na dostępach tworzy się sama jako naturalny efekt codziennej pracy.
kontroli nad „wspólnym kontem”
Kiedy zespół loguje się na wspólną skrzynkę ([email protected]) tradycyjnymi metodami, hasło krąży bez nadzoru. Nigdy nie wiesz, kto faktycznie je zna (wliczając w to byłych pracowników). W perc.pass zamykasz to hasło w centralnym sejfie i precyzyjnie przypisujesz do niego konkretnych użytkowników. W razie incydentu administrator nie musi zgadywać – natychmiast generuje zamkniętą, imienną listę osób, które w danym czasie dysponowały poświadczeniami, oraz widzi pełną historię nadawania i odbierania tych uprawnień.
Automatyczny log audytowy
Kiedy padają pytania, nie musisz zgadywać. Każde utworzenie, edytowanie czy udostępnienie hasła w perc.pass zostawia trwały ślad. W razie kontroli generujesz raport, który staje się twardym dowodem wykazującym przestrzeganie procedur.
Wsparcie w raportowaniu incydentów
Obowiązek zgłoszenia poważnego incydentu (wymóg NIS2) wymaga natychmiastowej wiedzy o jego skali. Dzięki scentralizowanej bazie, administrator w kilka minut może sprawdzić, do jakich systemów miał dostęp skompromitowany użytkownik i natychmiast je zablokować. To skraca czas analizy z dni do minut.
Gotowość na audyty (Model On-Premise)
Zgodnie z wymogami UoKSC podmioty kluczowe muszą podlegać regularnym audytom. perc.pass oferuje wdrożenie bezpośrednio we własnej infrastrukturze klienta (On-Premise / Appliance). Oznacza to, że nie tylko same hasła, ale cała strategiczna historia operacyjna nigdy nie opuszcza serwerów organizacji.
https://percpass.com/menedzer-hasel-on-premise/
Jeśli chcesz sprawdzić, jak centralne zarządzanie dostępami wygląda w praktyce – przetestuj perc.pass w bezpłatnym okresie trial. Historia operacji na dostępach zaczyna powstawać od pierwszego dnia użytkowania.