BAZA WIEDZY
Jak rozpoznawać i obsługiwać incydenty, przygotować się na awarie oraz zapewnić ciągłość działania jednostki.
Incydenty i ciągłość działania
Praktyczne wymagania dotyczące systemów, uprawnień, MFA, poczty, kopii zapasowych, chmury i zabezpieczeń
KSC w praktyce - systemy, dostęp i zabezpieczenia
Kogo obejmuje KSC, jakie obowiązki ma kierownik jednostki i od czego zacząć wdrożenie.
KSC w sektorze publicznym
KSC w sektorze publicznym
Kogo obejmuje KSC, jakie obowiązki ma kierownik jednostki i od czego zacząć wdrożenie.
Stan prawny: 14.09.2026 r.
1. Czy szkoły i inne jednostki sektora publicznego podlegają KSC?
Tak, jeżeli są podmiotem publicznym w rozumieniu KSC i wykorzystują system informacyjny do realizacji zadania publicznego. W praktyce dotyczy to wielu szkół i jednostek organizacyjnych JST korzystających z e-dzienników, poczty, systemów kadrowych, finansowych czy innych systemów wykorzystywanych przy realizacji zadań.
W praktyce: w przypadku typowych jednostek publicznych, takich jak szkoły, przedszkola, OPS-y, biblioteki czy instytucje kultury, trudno dziś wyobrazić sobie realizację zadań publicznych bez wykorzystania systemów informacyjnych. Dlatego punktem wyjścia powinno być raczej założenie, że KSC je obejmuje, a ewentualny brak zastosowania ustawy wymagałby szczególnego uzasadnienia.
Podstawa: art. 5 ust. 2 pkt 8 oraz art. 16d KSC
2. Czy jednostka publiczna musi sama zgłosić się do Wykazu KSC?
Co do zasady podmioty publiczne są wpisywane do Wykazu KSC z urzędu. Po wpisie jednostka otrzymuje zawiadomienie i może zostać wezwana do uzupełnienia danych. Termin na ich uzupełnienie wynosi 6 miesięcy od doręczenia wezwania.
W praktyce: warto w pierwszej kolejności sprawdzić skrzynkę e-Doręczeń jednostki – to obecnie podstawowy kanał komunikacji elektronicznej podmiotów publicznych z administracją. W zawiadomieniu o wpisie znajduje się wezwanie do uzupełnienia danych oraz kod umożliwiający dostęp do wpisu w Wykazie KSC.
Źródło: System S46
3. Do kiedy trzeba wdrożyć obowiązki KSC?
Dla podmiotów, które spełniały przesłanki objęcia KSC już 3 kwietnia 2026 r., okres dostosowawczy kończy się 3 kwietnia 2027 r. Jeżeli podmiot spełni przesłanki później, zasadniczo ma 12 miesięcy na realizację obowiązków.
W praktyce: 3 kwietnia 2027 r. to termin, do którego wdrożenie ma już działać, a nie data rozpoczęcia prac.
Źródło: Ministerstwo Cyfryzacji – Najważniejsze terminy KSC
4. Czy wystarczy przygotować Politykę lub dokumentację SZBI?
Nie. Podmiot publiczny musi opracować, wdrożyć, realizować, monitorować i utrzymywać SZBI. Sama polityka lub komplet procedur nie potwierdzają jeszcze spełnienia obowiązków. Potrzebne są również dowody ich rzeczywistego stosowania.
W praktyce: trzeba wykazać realne działania – np. prowadzone rejestry, wykonane testy i przeglądy, analizę logów czy przeprowadzone szkolenia.
Podstawa: art. 8 ust. 3, art. 10 ust. 4 oraz załącznik nr 4 część IV KSC
5. Kto odpowiada za KSC w jednostce – dyrektor czy informatyk?
Za wykonywanie obowiązków KSC odpowiada kierownik podmiotu. Może przydzielać zadania innym osobom, ale nie oznacza to przeniesienia jego ustawowej odpowiedzialności.
W praktyce: informatyk jest jednym z ogniw systemu bezpieczeństwa, ale KSC obejmuje także zarządzanie ryzykiem, organizację odpowiedzialności, zapewnienie zasobów, szkolenia, ciągłość działania i nadzór kierownictwa.
Podstawa: art. 8c ust. 1 i 3 oraz art. 8d KSC
6. Czy zewnętrzny informatyk lub firma IT może przejąć obowiązki KSC?
Może wykonywać określone zadania, ale nie przejmuje odpowiedzialności kierownika jednostki. Ustawa dopuszcza korzystanie z zewnętrznego dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa, jednak zakres takiej współpracy musi rzeczywiście odpowiadać powierzonym obowiązkom.
W praktyce: zewnętrzny informatyk lub firma IT najczęściej wspiera jednostkę w realizacji technicznych i organizacyjnych obowiązków KSC, ale nie „zapewnia zgodności” za jednostkę. Zakres wsparcia powinien być jasno określony w umowie.
Podstawa: art. 14 oraz art. 8c ust. 3 KSC
7. Czy jednostka publiczna musi wyznaczyć osobę do kontaktów KSC?
Tak. Podmiot ważny będący podmiotem publicznym wyznacza co najmniej jedną osobę odpowiedzialną za utrzymywanie kontaktów z innymi podmiotami KSC.
W praktyce: mimo że przepisy wymagają wyznaczenia co najmniej jednej osoby do kontaktów KSC, warto wskazać dwie osoby lub zapewnić formalne zastępstwo. Zmniejsza to ryzyko braku kontaktu podczas urlopu, choroby lub innej nieobecności i zapewnia ciągłość komunikacji.
Podstawa: art. 9 ust. 3 KSC
8. Czy IOD może być osobą do kontaktów KSC?
Tak, samo pełnienie funkcji IOD nie wyklucza wskazania tej osoby jako osoby do kontaktów KSC. Trzeba jednak odróżnić rolę kontaktową od faktycznego zarządzania cyberbezpieczeństwem.
Jeżeli IOD utrzymuje kontakt, przekazuje informacje i wspiera komunikację, co do zasady nie musi to prowadzić do konfliktu interesów. Problem może powstać wtedy, gdy powierzono by mu podejmowanie decyzji operacyjnych, ustalanie zabezpieczeń lub zarządzanie obszarem, który później miałby niezależnie oceniać jako IOD.
W praktyce: IOD może pełnić rolę osoby do kontaktów KSC, ale nie powinien jednocześnie odpowiadać za operacyjne zarządzanie cyberbezpieczeństwem jednostki.
Źródła: Ministerstwo Cyfryzacji – Pytania do ustawy o KSC; UODO – Łączenie funkcji IOD z innymi zadaniami lub funkcjami
9. Czy dyrektor lub kierownik musi co roku odbywać szkolenie z KSC?
Tak. Kierownik podmiotu oraz osoba, której powierzono obowiązki kierownika w zakresie cyberbezpieczeństwa, przechodzą szkolenie raz w roku kalendarzowym. Udział w szkoleniu powinien być udokumentowany.
W praktyce: KSC nie określa minimalnego czasu ani formy szkolenia. Powinno ono jednak realnie przygotować kierownika do wykonywania obowiązków wynikających z ustawy, a udział w nim musi być udokumentowany. Ze względu na szeroki zakres tych obowiązków warto zaplanować odpowiednie środki i wybrać szkolenie ukierunkowane na rolę kierownika, a nie ogólny webinar o cyberbezpieczeństwie.
Podstawa: art. 8e KSC
10. Czy pracowników trzeba szkolić z cyberbezpieczeństwa?
Tak. Załącznik nr 4 do KSC wprost wymaga szkolenia osób zaangażowanych w proces przetwarzania informacji. Szkolenie powinno obejmować w szczególności rodzaje cyberzagrożeń, podstawowe zasady cyberhigieny, reagowanie na incydenty oraz świadomość skutków naruszenia zasad bezpieczeństwa informacji.
W praktyce: KSC nie określa częstotliwości tych szkoleń. Jednostka powinna jednak móc wykazać, że wymagane szkolenie zostało przeprowadzone i obejmowało wskazany w ustawie zakres.
Podstawa: załącznik nr 4 część I pkt 17 KSC
11. Czy gmina może realizować obowiązki KSC wspólnie dla swoich jednostek?
Tak. Ustawa przewiduje możliwość zorganizowania przez JST wspólnej realizacji określonych obowiązków. Trzeba wskazać jednostkę realizującą zadania, jednostki objęte obsługą oraz zakres powierzonych obowiązków.
W praktyce: wspólna obsługa nie oznacza, że dyrektor szkoły czy kierownik jednostki przestaje mieć jakiekolwiek zadania. Musi być jasno ustalone, kto odpowiada za poszczególne działania.
Podstawa: art. 16e ust. 5 oraz art. 16f–16h KSC
KSC w praktyce - systemy, dostęp i zabezpieczenia
Praktyczne wymagania dotyczące systemów, uprawnień, MFA, poczty, kopii zapasowych, chmury i zabezpieczeń.
Stan prawny: 14.09.2026 r.
1. Czy jednostka musi prowadzić inwentaryzację systemów, usług i produktów ICT?
Tak. KSC wymaga inwentaryzacji produktów ICT, usług ICT i procesów ICT służących do przetwarzania informacji oraz kontrolowania podstawowych wersji używanych produktów i usług ICT.
W praktyce: typowa księga inwentarzowa sprzętu najczęściej nie wystarczy. Może być punktem wyjścia, ale ewidencja powinna obejmować również wykorzystywane oprogramowanie i usługi ICT oraz informacje pozwalające kontrolować ich wersje. Nie trzeba prowadzić wszystkiego w jednym rejestrze – ważne, aby łącznie jednostka miała aktualny obraz wykorzystywanych zasobów ICT.
Podstawa: załącznik nr 4 część I pkt 1–2 KSC
2. Czy trzeba rozdzielić konto administratora od konta używanego do codziennej pracy?
KSC nie nakazuje wprost posiadania dwóch oddzielnych kont, ale wymaga stosowania zasady minimalnych uprawnień i ograniczenia dostępu do funkcji administracyjnych do osób, które rzeczywiście go potrzebują. Rozdzielenie konta administracyjnego od konta używanego do poczty, Internetu i zwykłej pracy jest podstawową praktyką bezpieczeństwa.
Korzystanie na co dzień z konta administratora zwiększa skutki przejęcia konta, uruchomienia złośliwego oprogramowania lub błędu użytkownika. Konto z podwyższonymi uprawnieniami pozwala m.in. instalować oprogramowanie, zmieniać konfigurację systemu i wykonywać operacje niedostępne dla zwykłego użytkownika. Microsoft wprost zaleca ograniczenie liczby administratorów i korzystanie ze standardowych kont do codziennej pracy.
W praktyce: zwykły użytkownik nie powinien mieć stałych uprawnień lokalnego administratora. Instalacja oprogramowania i zmiany wymagające podwyższonych uprawnień powinny być kontrolowane przez administratora lub IT. Osoba administrująca systemem powinna natomiast korzystać na co dzień ze zwykłego konta, a odrębnego konta administracyjnego używać tylko do czynności wymagających takich uprawnień
Podstawa: załącznik nr 4 część I pkt 4–5 KSC
3. Kiedy trzeba przeglądać i zmieniać uprawnienia użytkowników?
KSC nie określa jednej częstotliwości okresowego przeglądu uprawnień. Wymaga jednak bezzwłocznego cofnięcia uprawnień, gdy ustaje podstawa dostępu, ich zawieszenia przy niewykonywaniu obowiązków przez co najmniej miesiąc oraz odpowiedniej zmiany zakresu dostępu przy zmianie zadań.
W praktyce: przegląd uprawnień powinien obejmować nie tylko zatrudnienie, odejście lub zmianę stanowiska. Dłuższa nieobecność pracownika także ma znaczenie – przy niewykonywaniu obowiązków przez co najmniej miesiąc dostęp powinien zostać zawieszony. Niezależnie od tego warto prowadzić cykliczne przeglądy kont i uprawnień oraz pozostawiać dowód ich wykonania.
Podstawa: załącznik nr 4 część I pkt 4–7 KSC
4. Czy MFA jest obowiązkowe?
KSC nie wprowadza ogólnego obowiązku stosowania MFA do każdego systemu w jednostce publicznej. Wymaga jednak zabezpieczenia systemów przed nieautoryzowanym dostępem oraz stosowania minimalnych uprawnień. W przypadku poczty elektronicznej dostawca obsługujący podmiot publiczny ma obowiązek oferować pocztę umożliwiającą stosowanie uwierzytelniania wieloskładnikowego.
W praktyce: brak MFA oznacza, że bezpieczeństwo konta w większym stopniu opiera się na samym haśle. W takiej sytuacji analiza ryzyka może wskazywać na potrzebę zastosowania dodatkowych środków kompensacyjnych, np. bardziej rygorystycznych zasad haseł, blokowania prób logowania czy monitorowania dostępu. Wdrożenie MFA często pozwala znacząco ograniczyć ryzyko przejęcia konta i jest jednym z najskuteczniejszych sposobów wzmocnienia uwierzytelniania.
Podstawa: załącznik nr 4 część I pkt 4–5 KSC; art. 24 ust. 6 ustawy o zwalczaniu nadużyć w komunikacji elektronicznej
5. Czy jednostka musi testować możliwość odtworzenia kopii zapasowych?
Tak. KSC wymaga wykonywania kopii zapasowych odseparowanych logicznie i fizycznie od danych wykorzystywanych do realizacji zadania publicznego oraz testowania ich pod kątem kompletności i możliwości odtworzenia danych. Ustawa nie określa jednej częstotliwości takich testów.
W praktyce: informacja „backup wykonuje się codziennie” nie wystarcza. Trzeba również sprawdzić, czy dane rzeczywiście można z kopii odzyskać, a wynik takiego testu warto udokumentować.
Podstawa: załącznik nr 4 część I pkt 10–11 KSC
6. Czy jednostka musi mieć zasady pracy zdalnej i mobilnej?
Tak. Minimalne wymagania SZBI obejmują ustanowienie podstawowych zasad gwarantujących bezpieczną pracę przy przetwarzaniu mobilnym i pracy na odległość.
W praktyce: należy określić m.in. zasady dostępu spoza siedziby, korzystania z urządzeń mobilnych, ochrony informacji oraz dopuszczonych sposobów zdalnego łączenia z systemami. Jeżeli jednostka nie dopuszcza pracy zdalnej, również warto to jednoznacznie określić.
Podstawa: załącznik nr 4 część I pkt 8 KSC
7. Jakie zabezpieczenia powinna mieć poczta elektroniczna jednostki publicznej?
Podmiot publiczny musi korzystać z poczty wykorzystującej mechanizmy SPF, DMARC i DKIM. Wymóg wynika zarówno z regulacji dotyczących poczty podmiotów publicznych, jak i z załącznika nr 4 do KSC.
W praktyce: warto poprosić informatyka lub dostawcę poczty o potwierdzenie konfiguracji SPF, DKIM i DMARC dla domeny jednostki. Sama informacja, że „poczta jest zabezpieczona”, nie potwierdza spełnienia tego wymagania.
Podstawa: załącznik nr 4 część I pkt 9 KSC oraz art. 24 ust. 1–2 ustawy o zwalczaniu nadużyć w komunikacji elektroniczne
8. Czy program antywirusowy wystarczy do spełnienia wymagań KSC?
Nie. KSC wprost wymaga stosowania oprogramowania antywirusowego, ale równocześnie nakazuje monitorowanie wersji i cyklu życia produktów ICT oraz korzystanie ze stabilnych wersji, dla których nie występują krytyczne podatności albo których stosowanie nie powoduje istotnego negatywnego wpływu na bezpieczeństwo.
W praktyce: antywirus jest tylko jednym z zabezpieczeń. Trzeba również pilnować aktualizacji, wsparcia producenta, wersji wykorzystywanego oprogramowania i informacji o krytycznych podatnościach.
Podstawa: załącznik nr 4 część I pkt 13 oraz 15–16 KSC
9. Czy korzystanie z chmury lub systemu zewnętrznego dostawcy zwalnia jednostkę z obowiązków KSC?
Nie. W przypadku korzystania z usług dostawcy chmury obliczeniowej lub centrum przetwarzania danych KSC wymaga udokumentowania mechanizmów zapewniających ochronę przetwarzanych informacji przed kradzieżą, nieuprawnionym dostępem, uszkodzeniem lub zakłóceniem.
W praktyce: korzystanie z systemu chmurowego często wiąże się również z powierzeniem przetwarzania danych osobowych. Nie zwalnia to administratora z odpowiedzialności za wybór dostawcy i ocenę, czy zapewnia on odpowiednie zabezpieczenia. Trzeba więc patrzeć równolegle na wymagania KSC i RODO, a nie zakładać, że „skoro system jest u dostawcy, to bezpieczeństwo jest jego problemem”.
Podstawa: załącznik nr 4 część I pkt 3 lit. c KSC
10. Jak często trzeba przeglądać SZBI?
Co najmniej raz w roku. Dodatkowy, niezwłoczny przegląd jest wymagany również w przypadku odpowiedniej rekomendacji Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa albo wystąpienia okoliczności mogących wpłynąć na ryzyko incydentu poważnego i wymagających ponownego wykonania działań lub zmian w SZBI.
W praktyce: coroczny przegląd warto udokumentować nawet wtedy, gdy kończy się wnioskiem, że nie ma potrzeby wprowadzania zmian. Powinien pozostać dowód, że SZBI zostało faktycznie zweryfikowane.
Podstawa: załącznik nr 4 część III KSC
Incydenty i ciągłość działania
Jak rozpoznawać i obsługiwać incydenty, przygotować się na awarie oraz zapewnić ciągłość działania jednostki.
Stan prawny: 14.09.2026 r.
1. Czy każdy incydent cyberbezpieczeństwa trzeba zgłaszać?
Nie. Każdy incydent powinien zostać wykryty, zarejestrowany, przeanalizowany, sklasyfikowany i odpowiednio obsłużony, ale obowiązek zgłoszenia do właściwego CSIRT dotyczy incydentu poważnego. W przypadku podmiotu ważnego będącego podmiotem publicznym zgłoszenie należy przekazać niezwłocznie, nie później niż w ciągu 72 godzin od wykrycia.
Dla tej grupy podmiotów nie obowiązuje 24-godzinne wczesne ostrzeżenie ani późniejsze sprawozdania okresowe i końcowe przewidziane dla pozostałych PK/PW.
W praktyce: nie chodzi więc o zgłaszanie każdego podejrzanego e-maila do CSIRT. Jednostka musi mieć jednak sposób, aby takie zdarzenie trafiło do właściwej osoby, zostało ocenione i – jeśli spełnia kryteria incydentu poważnego – zgłoszone w terminie.
Podstawa: art. 11 ust. 1 pkt 1–4a w zw. z art. 12c KSC
2. Czy zwykła awaria systemu może być incydentem cyberbezpieczeństwa?
Tak. Incydent nie musi być skutkiem ataku hakera. KSC definiuje incydent jako zdarzenie, które ma lub może mieć niekorzystny wpływ na bezpieczeństwo systemów informacyjnych. Po nowelizacji incydent poważny może dotyczyć m.in. poważnego obniżenia jakości albo przerwania ciągłości świadczenia usługi.
W praktyce: awaria serwera, uszkodzenie urządzenia, błąd konfiguracji czy niedostępność usługi mogą wymagać obsługi jako incydent, jeżeli wpływają na bezpieczeństwo lub dostępność systemu. Nie należy ograniczać procedury incydentowej wyłącznie do włamań, phishingu czy ransomware.
Podstawa: art. 2 pkt 5 i 7 KSC
3. Czy jednostka musi zapewnić możliwość zgłaszania incydentów, cyberzagrożeń i podatności?
Tak. KSC wymaga zapewnienia użytkownikom możliwości zgłoszenia cyberzagrożenia, incydentu lub podatności.
W praktyce: pracownik powinien wiedzieć, gdzie i komu zgłosić podejrzany e-mail, nietypowe zachowanie komputera, utratę urządzenia czy zauważoną podatność. Może to być np. wskazany adres e-mail, telefon lub inny prosty kanał – najważniejsze, żeby był znany i rzeczywiście obsługiwany.
Podstawa: art. 9 ust. 1 pkt 3 KSC
4. Czy jednostka musi prowadzić rejestr incydentów?
Tak. Obsługa incydentu obejmuje m.in. jego wykrywanie, rejestrowanie, analizowanie, klasyfikowanie i reagowanie. Rejestrowanie zdarzeń pozwala również wykazać, jak jednostka oceniła incydent i jakie podjęła działania.
W praktyce: rejestr nie musi być skomplikowany. Powinien jednak pozwalać ustalić m.in. kiedy zdarzenie wystąpiło i zostało wykryte, czego dotyczyło, jak je sklasyfikowano, jakie działania podjęto i kiedy zakończono jego obsługę.
Podstawa: art. 11 ust. 1 pkt 1–3 oraz art. 10 ust. 4 KSC
5. Czy jednostka musi mieć procedurę reagowania na incydenty?
Tak. W przypadku podmiotu ważnego będącego podmiotem publicznym SZBI musi obejmować procedury i zasady działania na wypadek cyberzagrożenia lub incydentu.
W praktyce: procedura powinna odpowiadać na proste pytania: kto przyjmuje zgłoszenie, kto ocenia zdarzenie, kogo należy powiadomić, kto podejmuje decyzje, kiedy angażowany jest informatyk lub dostawca oraz kto odpowiada za ewentualne zgłoszenie do CSIRT.
Podstawa: załącznik nr 4 część I pkt 18 KSC
6. Czy procedury na wypadek awarii lub incydentu trzeba testować?
Tak. KSC wprost wymaga nie tylko przygotowania, lecz również testowania procedury na wypadek awarii lub incydentu. Ustawa nie określa jednej obowiązkowej częstotliwości takich testów.
W praktyce: sama procedura w segregatorze nie wystarczy. Warto przeprowadzić prosty test lub ćwiczenie scenariuszowe, np. „nie działa e-dziennik”, „brak dostępu do serwera”, „zaszyfrowano komputer sekretariatu”, i sprawdzić, czy pracownicy wiedzą, co robić. Wynik testu powinien pozostać udokumentowany.
Podstawa: załącznik nr 4 część I pkt 12 KSC
7. Co zrobić, gdy przestaje działać kluczowy system, Internet lub poczta?
Jednostka powinna mieć wcześniej przygotowany sposób postępowania na wypadek takiej awarii. Obowiązek przygotowania i testowania procedur awaryjnych oznacza, że nie wystarczy dopiero po wystąpieniu problemu zadzwonić do informatyka i czekać na usunięcie usterki.
W praktyce: trzeba ustalić, kto zgłasza awarię, kto koordynuje działania, jak komunikować się podczas niedostępności systemów i – tam, gdzie jest to możliwe i potrzebne – w jaki sposób czasowo kontynuować najważniejsze zadania do czasu przywrócenia systemu.
Podstawa: załącznik nr 4 część I pkt 12 i 18 KSC
8. Czy po incydencie trzeba przeglądać lub aktualizować SZBI?
Nie po każdym incydencie automatycznie. Dodatkowy przegląd SZBI trzeba przeprowadzić niezwłocznie, jeżeli wystąpią okoliczności mogące wpłynąć na ryzyko incydentu poważnego i wymagające ponownego wykonania działań SZBI albo zmiany samego systemu zarządzania.
W praktyce: po poważniejszym zdarzeniu warto ustalić nie tylko „jak usunięto awarię”, ale także dlaczego do niej doszło, czy zastosowane zabezpieczenia zadziałały i czy trzeba zmienić procedurę, konfigurację, odpowiedzialności lub sposób działania.
Podstawa: załącznik nr 4 część III KSC
9. Czy jednostka musi informować użytkowników o cyberzagrożeniu lub incydencie?
W określonych sytuacjach – tak. W przypadku poważnego cyberzagrożenia należy poinformować użytkowników, na których może ono mieć wpływ, o możliwych środkach zapobiegawczych. Jednostka ma także obowiązek poinformowania użytkowników o incydencie poważnym mającym wpływ na świadczenie usług.
W praktyce: komunikacja jest częścią obsługi incydentu. Procedura powinna wskazywać nie tylko, kto kontaktuje się z informatykiem czy CSIRT, ale również kto i w jaki sposób przekazuje potrzebne informacje pracownikom, rodzicom, klientom lub innym użytkownikom – jeżeli sytuacja tego wymaga.
Podstawa: art. 11 ust. 2a–2b KSC
10. Czy zgłoszenie incydentu do CSIRT zastępuje zgłoszenie naruszenia ochrony danych osobowych?
Nie. KSC i RODO ustanawiają odrębne obowiązki. Ten sam incydent może jednocześnie być incydentem cyberbezpieczeństwa oraz naruszeniem ochrony danych osobowych. W takim przypadku trzeba niezależnie ocenić obowiązki wynikające z obu regulacji.
W praktyce: np. ransomware, przejęcie skrzynki pocztowej czy nieuprawniony dostęp do systemu mogą wymagać zarówno obsługi w ramach KSC, jak i oceny naruszenia ochrony danych osobowych. Zgłoszenie do CSIRT nie zastępuje ewentualnego zgłoszenia do Prezesa UODO – i odwrotnie.
Podstawa: art. 11–12c KSC oraz art. 33–34 RODO
To jest element tekstowy. Kliknij ten element dwukrotnie, aby edytować tekst. Możesz też dowolnie zmieniać rozmiar i położenie tego elementu oraz wszelkie parametry wliczając w to tło, obramowanie i wiele innych. Elementom tekstowych możesz też ustawić animację, dzięki czemu, gdy użytkownik strony wyświetli je na ekranie, pokażą się one z wybranym efektem.
© 2026 ART Piotr Armatowski (consulting & training), ul. Słoneczna 4, 84-353 Lubowidz, NIP 841 158 31 54