# Aktualizacje oprogramowania w firmie: jak ustalić rytm, żeby nie odkładać poprawek

> Aktualizacje oprogramowania w firmie najczęściej przegrywają z bieżącą pracą, bo restart serwera czy laptopa zawsze wypada w złym momencie. Pokazujemy, jak zarząd i dział IT mogą raz ustalić zasady: podział systemów na grupy, stały termin instalacji poprawek, tryb pilny, postępowanie z systemami bez wsparcia i sposób mierzenia postępów. Z odesłaniem do NIST, ENISA, CERT Polska, ustawy o KSC i RODO.

**Źródło:** https://algorsec.pl/baza-wiedzy/aktualizacje-oprogramowania-w-firmie  
**Aktualizacja:** 2026-10-29  
**Język:** pl-PL  
**Wydawca:** AlgorSec (ALGORSEC sp. z o.o.)

---

- Kategoria: Operacje bezpieczeństwa
- Format: Poradnik
- Poziom: Podstawowy
- Czas czytania: 10 min
- Opublikowano: 2026-10-29

## Odpowiedź w skrócie

Aktualizacje oprogramowania w firmie przestają być odkładane, gdy zarząd zatwierdzi z góry stały rytm: listę systemów, ich podział na grupy o podobnych potrzebach, termin instalacji poprawek dla każdej grupy i osobny tryb pilny dla luk, które atakujący już wykorzystują. NIST zaleca, żeby te decyzje zapadały z wyprzedzeniem, a poprawki trafiały najpierw do małej grupy urządzeń, potem do pozostałych, z obowiązkową instalacją po okresie przejściowym. Systemy, których nie da się zaktualizować, tworzą osobną grupę z zabezpieczeniami zastępczymi i udokumentowaną decyzją. Podmioty kluczowe i ważne, które spełniały przesłanki w dniu wejścia nowelizacji w życie, mają czas do 3 kwietnia 2027 r., żeby wdrożyć regularne aktualizacje wymagane przez art. 8 ustawy o KSC, a dla pozostałych firm podstawą jest art. 32 RODO i wymagania klientów.

## Kluczowe fakty

- Ustawa o KSC co do zasady wymaga od podmiotów kluczowych i ważnych regularnych aktualizacji oprogramowania stosownie do zaleceń producenta, z analizą ich wpływu na bezpieczeństwo świadczonej usługi i poziomu krytyczności (art. 8 ust. 1 pkt 5 lit. b).
- Podmioty, które spełniały przesłanki w dniu wejścia nowelizacji w życie (3 kwietnia 2026 r.), realizują obowiązki z rozdziału 3 ustawy, w tym z art. 8, w terminie 12 miesięcy, czyli do 3 kwietnia 2027 r. (art. 33 ust. 1 ustawy nowelizującej).
- NIST SP 800-40 Rev. 4 opisuje aktualizacje jako konserwację zapobiegawczą i zaleca dzielenie systemów na grupy z osobnym planem dla trybu rutynowego, pilnego i dla systemów, których nie da się zaktualizować.
- Katalog Known Exploited Vulnerabilities agencji CISA zawiera luki wykorzystywane w atakach. Terminy usuwania luk z dyrektywy BOD 26-04 wiążą tylko amerykańskie federalne agencje cywilne, a CISA zaleca organizacjom używanie katalogu przy ustalaniu priorytetów.
- Rozporządzenie wykonawcze (UE) 2024/2690, omówione w wytycznych ENISA, dopuszcza rezygnację z poprawki, gdy jej wady przeważają nad korzyściami dla bezpieczeństwa, ale decyzję trzeba udokumentować i uzasadnić.

## Dlaczego aktualizacje oprogramowania w firmie są odkładane

Aktualizacja, nazywana też poprawką albo łatką, to udostępniona przez producenta zmiana w programie lub urządzeniu, która usuwa błąd, w tym lukę w zabezpieczeniach. Jej instalacja często wymaga restartu, krótkiej przerwy w pracy albo sprawdzenia, czy inne programy nadal działają. Dlatego bieżące obowiązki zwykle wygrywają z aktualizacją.

Amerykański Narodowy Instytut Standaryzacji i Technologii (NIST) w wytycznych SP 800-40 Rev. 4 opisuje ten mechanizm wprost: rutynowe poprawki, które nie mają statusu pilnych, są często odkładane i zaniedbywane. Każde opóźnienie wydłuża czas, w którym atakujący może wykorzystać znaną lukę. Utrudnia też późniejszą pilną aktualizację, bo najpierw trzeba doinstalować wszystkie wcześniejsze poprawki, od których zależy ta nowa.

NIST zwraca uwagę zarządom na jeszcze jedną rzecz. Przestój spowodowany aktualizacją firma w dużej mierze kontroluje: sama wybiera termin i usuwa ewentualne problemy według własnego harmonogramu. Przestoju po włamaniu albo zaszyfrowaniu danych przez program wymuszający okup w dużej mierze nie kontroluje, a brakującą poprawkę i tak trzeba będzie wtedy zainstalować. Wytyczne zalecają traktować aktualizacje jak przeglądy floty samochodowej, czyli jako zwykły koszt prowadzenia działalności.

Źródła: [NIST SP 800-40 Rev. 4, streszczenie dla kierownictwa (s. iv)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf#page=6) · [NIST SP 800-40 Rev. 4, rozdz. 3: przestoje z aktualizacji a przestoje z incydentów (s. 8)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf#page=15) · [NIST SP 800-40 Rev. 4, pkt 3.3: scenariusze reagowania (s. 11-12)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf#page=18)

## Zarządzanie aktualizacjami zaczyna się od listy systemów

Firma nie zaktualizuje programu, o którym nie wie. Pierwszym krokiem jest więc lista sprzętu i oprogramowania: komputery, serwery, telefony służbowe, routery i zapory sieciowe, drukarki, systemy w chmurze, aplikacje biznesowe i ich dodatki. NIST zaleca, żeby przy każdej pozycji zapisać nie tylko dane techniczne, ale też znaczenie dla firmy, na przykład czy system obsługuje klientów i czy może zostać wyłączony w godzinach pracy.

ENISA w wytycznych technicznych do unijnych wymogów bezpieczeństwa zaleca połączenie takiej listy ze stałym źródłem informacji o nowych poprawkach. W praktyce oznacza to, że dla każdego ważnego systemu ktoś odpowiada za śledzenie komunikatów producenta i ostrzeżeń CERT Polska, który publikuje komunikaty o krytycznych podatnościach i zalecanych aktualizacjach.

Lista od razu pokaże też programy i urządzenia, dla których producent zakończył wsparcie. Takie pozycje wymagają osobnej decyzji, opisanej w dalszej części tekstu.

Zobacz też: [Analiza ryzyka krok po kroku - od inwentaryzacji do rejestru](https://algorsec.pl/baza-wiedzy/analiza-ryzyka-krok-po-kroku-od-inwentaryzacji-do-rejestru)

Źródła: [NIST SP 800-40 Rev. 4, pkt 3.2: inwentaryzacja oprogramowania i zasobów (s. 10-11)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf#page=17) · [ENISA, wytyczne techniczne do rozporządzenia (UE) 2024/2690, pkt 6.6 (s. 91)](https://www.enisa.europa.eu/sites/default/files/2025-06/ENISA_Technical_implementation_guidance_on_cybersecurity_risk_management_measures_version_1.0.pdf#page=92) · [CERT Polska: komunikaty bezpieczeństwa (moje.cert.pl/komunikaty)](https://moje.cert.pl/komunikaty/)

## Jak często aktualizować oprogramowanie: grupy systemów i stały rytm

Ustalanie terminu dla każdej poprawki osobno nie działa, bo jest ich za dużo. NIST zaleca podzielić systemy na grupy o podobnych potrzebach i dla każdej grupy raz ustalić plan: kiedy poprawki są instalowane, czy wymagają testu, w jakich godzinach wolno wyłączyć system i jak poważne byłyby skutki jego przejęcia. Wytyczne podają przykłady takich grup: laptopy pracowników, które dobrze znoszą przerwy, serwery w firmowej serwerowni, które aktualizuje się tylko w uzgodnionych oknach serwisowych, oraz stare urządzenia produkcyjne bez wsparcia producenta.

Dla rutynowych poprawek NIST zaleca wdrażanie etapami. Najpierw aktualizację dostaje kilka urządzeń, najlepiej osób z działu IT, potem szersza grupa pracowników, a na końcu reszta firmy. Ten pierwszy etap pełni rolę testu. Użytkownik może przez pewien czas odłożyć instalację, ale po upływie okresu przejściowego system instaluje ją sam albo urządzenie traci dostęp do firmowej sieci.

Ustawa o KSC nie podaje jednej częstotliwości. Wymaga aktualizacji regularnych i zgodnych z zaleceniami producenta, z analizą ich wpływu na bezpieczeństwo usługi i poziomu krytyczności. Rytm każdej grupy dobierz więc do cyklu wydawania poprawek przez jej producentów i do tego, jak długo firma może bezpiecznie czekać.

Źródła: [NIST SP 800-40 Rev. 4, pkt 3.4: grupy utrzymaniowe (s. 12-14)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf#page=19) · [NIST SP 800-40 Rev. 4, pkt 3.5.1: wdrażanie etapami i okres przejściowy (s. 14-15)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf#page=21) · [Ustawa o KSC, art. 8 ust. 1 pkt 5 lit. b (Dz.U. 2026 poz. 252, s. 15)](https://dziennikustaw.gov.pl/D2026000025201.pdf#page=15)

## Tryb pilny: co zrobić, gdy luka jest już wykorzystywana w atakach

Obok rytmu rutynowego potrzebny jest tryb pilny na sytuacje, w których luka jest poważna albo atakujący już ją wykorzystują. NIST zaleca w nim to samo postępowanie co w trybie rutynowym, tylko w bardzo skróconym czasie: krótki test na kilku urządzeniach trwa od kilku minut do kilku godzin, a instalacja w całej firmie następuje w ciągu kolejnych godzin lub dni.

Źródłem informacji o lukach wykorzystywanych w atakach jest między innymi katalog Known Exploited Vulnerabilities, prowadzony przez amerykańską agencję CISA. Dyrektywa BOD 26-04 z 10 czerwca 2026 r., która wyznacza terminy usuwania luk, w tym tych z katalogu, wiąże wyłącznie amerykańskie federalne agencje cywilne. CISA zaleca jednak organizacjom używanie katalogu jako jednej z podstaw przy ustalaniu kolejności prac.

W Polsce takie ostrzeżenia publikuje CERT Polska. We wrześniu 2026 r. informował o aktywnie wykorzystywanych lukach w routerach MikroTik i zalecał niezwłoczną aktualizację, a do tego czasu wyłączenie narażonych usług albo zablokowanie dostępu do nich spoza zaufanych sieci. W październiku 2026 r., przy krytycznych lukach w produktach Fortinet, zalecał niezwłoczną instalację poprawek, w pierwszej kolejności na urządzeniach dostępnych z internetu. Gdy aktualizacja nie jest możliwa, wskazywał ograniczenie dostępu do paneli administracyjnych i wymuszenie uwierzytelniania wieloskładnikowego (MFA), czyli logowania wymagającego oprócz hasła drugiego potwierdzenia. Zaznaczał przy tym, że takie środki nie zastępują aktualizacji. NIST zaleca, żeby takie rozwiązania tymczasowe miały wyznaczony termin zastąpienia właściwą poprawką.

Źródła: [NIST SP 800-40 Rev. 4, pkt 3.5.2 i 3.5.3: tryb pilny i środki tymczasowe (s. 15)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf#page=22) · [CISA: Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) · [CISA: BOD 26-04 Prioritizing Security Updates Based on Risk (10.06.2026)](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk) · [CERT Polska: krytyczne podatności w produktach Fortinet (22.10.2026)](https://moje.cert.pl/komunikaty/2026/198/krytyczne-podatnosci-w-produktach-fortinet/) · [CERT Polska: aktywnie wykorzystywane podatności w MikroTik RouterOS (5.09.2026)](https://cert.pl/posts/2026/09/podatnosci-w-mikrotik-routeros-aktywnie-wykorzystywane/)

## Systemy, których nie da się zaktualizować

Część systemów nie przyjmie poprawki, bo producent zakończył wsparcie albo urządzenie musi pracować bez przerwy, jak sterownik linii produkcyjnej. NIST zaleca, żeby nie traktować ich jako wyjątków poza procesem, tylko utworzyć dla nich osobną grupę z zabezpieczeniami zastępczymi, na przykład odcięciem od reszty sieci i ograniczeniem dostępu.

Rozporządzenie wykonawcze (UE) 2024/2690, omówione w wytycznych technicznych ENISA, pozwala zrezygnować z poprawki, gdy jej wady przeważają nad korzyściami dla bezpieczeństwa, ale decyzję trzeba udokumentować i uzasadnić. Gdy poprawka nie jest dostępna albo nie zostaje zainstalowana, rozporządzenie wymaga dodatkowych zabezpieczeń i akceptacji ryzyka, które pozostaje. Rozporządzenie obowiązuje bezpośrednio między innymi dostawców chmury i usług zarządzanych, a pozostałym firmom daje gotowy wzór postępowania.

NIST zaleca też okresowo sprawdzać, czy taki system nadal jest opłacalny. Do kosztu jego utrzymania trzeba doliczyć zabezpieczenia zastępcze i ryzyko, które firma świadomie przyjmuje. Ten rachunek ułatwia zarządowi decyzję o wymianie.

Źródła: [NIST SP 800-40 Rev. 4, pkt 3.5.4 i 3.5.5: systemy bez poprawek i wyjątki (s. 15-16)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf#page=22) · [ENISA, wytyczne techniczne do rozporządzenia (UE) 2024/2690, pkt 6.6.1 lit. d i 6.6.2 (s. 91 i 93)](https://www.enisa.europa.eu/sites/default/files/2025-06/ENISA_Technical_implementation_guidance_on_cybersecurity_risk_management_measures_version_1.0.pdf#page=94) · [Ustawa o KSC, art. 8b ust. 1: podmioty stosujące rozporządzenie (UE) 2024/2690 (s. 16)](https://dziennikustaw.gov.pl/D2026000025201.pdf#page=16)

## Plan wdrożenia rytmu aktualizacji krok po kroku

Poniższy plan zbiera zalecenia NIST i ENISA w kolejności, w jakiej firma może je wdrożyć. Pierwsze kroki wymagają decyzji zarządu, kolejne pracy działu IT albo dostawcy, który obsługuje firmowe systemy.

- Wyznacz osobę odpowiedzialną za aktualizacje w całej firmie i właściciela biznesowego dla każdego ważnego systemu.
- Sporządź listę sprzętu i oprogramowania, także w chmurze, z informacją o znaczeniu każdego systemu dla firmy i o tym, czy producent nadal go wspiera.
- Podziel systemy na grupy, na przykład laptopy, serwery, urządzenia sieciowe, aplikacje dostępne dla klientów i systemy bez wsparcia.
- Dla każdej grupy zapisz termin instalacji rutynowych poprawek, dopuszczalne okna serwisowe i sposób testu.
- Opisz tryb pilny: kto decyduje o jego uruchomieniu, kto instaluje poprawkę poza harmonogramem i jakie środki tymczasowe stosuje się do czasu jej wydania.
- Wybierz źródła informacji o lukach: komunikaty producentów, komunikaty CERT Polska i katalog CISA, i przypisz osoby, które je śledzą.
- Włącz automatyczną instalację tam, gdzie to możliwe, a po wdrożeniu sprawdzaj, czy poprawka rzeczywiście jest zainstalowana.
- Prowadź rejestr wyjątków: dla każdego systemu bez aktualnej poprawki zapisz powód, zabezpieczenie zastępcze, osobę akceptującą ryzyko i datę przeglądu.
- Regularnie, na przykład raz na kwartał, przedstaw zarządowi mierniki opisane w następnej sekcji i zdecyduj o wymianie systemów, których utrzymanie przestało się opłacać.

Źródła: [NIST SP 800-40 Rev. 4, rozdz. 3: zalecenia dla planowania aktualizacji (s. 8-17)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf#page=15) · [ENISA, wytyczne techniczne do rozporządzenia (UE) 2024/2690, pkt 6.6: przykłady dowodów (s. 92)](https://www.enisa.europa.eu/sites/default/files/2025-06/ENISA_Technical_implementation_guidance_on_cybersecurity_risk_management_measures_version_1.0.pdf#page=93)

## Jak sprawdzić, że firma nie odkłada poprawek

Sam odsetek zainstalowanych poprawek niewiele mówi zarządowi. NIST podaje przykład: informacja, że 10% urządzeń nie jest aktualizowanych, nie wyjaśnia, czy chodzi o najważniejsze serwery, czy o mało istotny sprzęt. Wytyczne zalecają mierniki, które łączą znaczenie systemu z wagą luki.

Przykładowa tabela w wytycznych pokazuje dla każdej takiej pary odsetek systemów zaktualizowanych w terminie z planu oraz średni i medianowy czas od wydania poprawki do instalacji. Dzięki temu widać, czy krytyczne luki w najważniejszych systemach są usuwane najszybciej i gdzie proces się zatrzymuje.

Dane do mierników warto weryfikować niezależnie od deklaracji. ENISA zaleca stosowanie narzędzi, które wykrywają nieaktualne i źle skonfigurowane oprogramowanie, czyli regularne skanowanie podatności. Pokazuje ono, czy poprawki naprawdę trafiły na wszystkie urządzenia.

Zobacz też: [KPI w cyberbezpieczeństwie - co raportować zarządowi](https://algorsec.pl/baza-wiedzy/kpi-w-cyberbezpieczenstwie-co-raportowac-zarzadowi) · [Skanowanie podatności](https://algorsec.pl/uslugi/audyty-testy-podatnosci/skanowanie-podatnosci)

Źródła: [NIST SP 800-40 Rev. 4, pkt 3.6 i tabela 1: mierniki aktualizacji (s. 16-17)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-40r4.pdf#page=23) · [ENISA, wytyczne techniczne do rozporządzenia (UE) 2024/2690, pkt 6.6 (s. 91)](https://www.enisa.europa.eu/sites/default/files/2025-06/ENISA_Technical_implementation_guidance_on_cybersecurity_risk_management_measures_version_1.0.pdf#page=92)

## Zarządzanie aktualizacjami a ustawa o KSC i RODO

Podmioty kluczowe i ważne co do zasady muszą w ramach systemu zarządzania bezpieczeństwem informacji regularnie aktualizować oprogramowanie stosownie do zaleceń producenta, z analizą wpływu aktualizacji na bezpieczeństwo usługi i krytyczności poszczególnych poprawek. Art. 8 ustawy o KSC wymaga też zbierania informacji o podatnościach i niezwłocznego działania po ich dostrzeżeniu. Firmy, które spełniały przesłanki w dniu wejścia nowelizacji w życie, mają na wdrożenie tych obowiązków czas do 3 kwietnia 2027 r.

Firmę spoza ustawy obowiązuje art. 32 RODO, jeśli przetwarza dane osobowe. Przepis wymaga zabezpieczeń odpowiednich do ryzyka, z uwzględnieniem stanu wiedzy technicznej, oraz w stosownym przypadku regularnego testowania i oceniania ich skuteczności. Opisany rytm aktualizacji, rejestr wyjątków i mierniki są dowodem, że firma te środki stosuje i sprawdza. Tego rodzaju dowodów mogą też oczekiwać klienci w ankietach bezpieczeństwa wysyłanych do dostawców.

Zobacz też: [Czy moja firma podlega UKSC?](https://algorsec.pl/baza-wiedzy/czy-moja-firma-podlega-uksc)

Źródła: [Ustawa o KSC, art. 8 ust. 1 pkt 3 i pkt 5 lit. b i d (Dz.U. 2026 poz. 252, s. 15)](https://dziennikustaw.gov.pl/D2026000025201.pdf#page=15) · [Ustawa nowelizująca KSC, art. 33 ust. 1: termin 12 miesięcy (Dz.U. 2026 poz. 252, s. 79)](https://dziennikustaw.gov.pl/D2026000025201.pdf#page=79) · [RODO, art. 32 ust. 1: bezpieczeństwo przetwarzania (EUR-Lex)](https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32016R0679)

## Jak AlgorSec może pomóc

Pomagamy spisać procedurę zarządzania aktualizacjami i rejestr wyjątków, przeprowadzamy audyty konfiguracji i testy podatności z rekomendacjami uporządkowanymi według ryzyka oraz dobieramy i wdrażamy narzędzia do automatycznej instalacji poprawek. Samą instalację i bieżący nadzór nad systemami prowadzi dział IT firmy albo jej dostawca usług IT.

Zobacz też: [Audyt konfiguracji i hardening](https://algorsec.pl/uslugi/audyty-testy-podatnosci/audyt-konfiguracji)

## Najczęstsze pytania

**Jak często aktualizować oprogramowanie w firmie?**

Przepisy nie podają jednej częstotliwości. Ustawa o KSC wymaga aktualizacji regularnych i zgodnych z zaleceniami producenta, a NIST zaleca stały termin dla każdej grupy systemów oraz osobny tryb pilny, w którym poprawka jest instalowana w ciągu godzin lub dni. Rytm dobierz do cyklu wydawania poprawek przez producenta i do znaczenia systemu dla firmy.

**Czy aktualizacje trzeba testować przed instalacją?**

Rozporządzenie wykonawcze (UE) 2024/2690, opisane w wytycznych ENISA, wymaga od objętych nim podmiotów testowania poprawek przed instalacją w systemach produkcyjnych. NIST pokazuje prosty sposób: najpierw kilka urządzeń, potem większa grupa, na końcu cała firma. Pierwszy etap pełni rolę testu.

**Co zrobić z programem, który nie ma już wsparcia producenta?**

Taki system nie dostanie poprawek, więc trzeba go chronić inaczej, na przykład odciąć od reszty sieci i ograniczyć dostęp. NIST zaleca umieścić go w osobnej grupie z własnym planem i okresowo sprawdzać, czy jego utrzymanie wraz z zabezpieczeniami zastępczymi nadal się opłaca w porównaniu z wymianą.

**Czy można świadomie nie zainstalować poprawki?**

Tak, jeśli wady poprawki przeważają nad korzyściami dla bezpieczeństwa, na przykład zatrzymałaby kluczowy system. Rozporządzenie wykonawcze (UE) 2024/2690 wymaga wtedy od objętych nim firm udokumentowania i uzasadnienia decyzji, dodatkowych zabezpieczeń i akceptacji ryzyka, które pozostaje. Pozostałym firmom ten sposób postępowania daje gotowy wzór, a NIST zaleca regularny przegląd takich wyjątków.

**Czy automatyczne aktualizacje wystarczą?**

Automatyzacja jest według NIST niezbędna, bo bez niej firma nie nadąży z liczbą poprawek. Nie zastępuje jednak sprawdzenia, czy poprawka rzeczywiście się zainstalowała i nie została później cofnięta, ani decyzji o systemach, których automat nie obejmuje. Dlatego obok automatycznej instalacji potrzebne są skanowanie podatności i rejestr wyjątków.

**Od kiedy ustawa o KSC wymaga regularnych aktualizacji?**

Obowiązek wynika z art. 8 ustawy o KSC w brzmieniu obowiązującym od 3 kwietnia 2026 r. Podmioty kluczowe i ważne, które spełniały przesłanki w tym dniu, mają 12 miesięcy na wdrożenie obowiązków z rozdziału 3 ustawy, czyli czas do 3 kwietnia 2027 r.

## Tagi

aktualizacje oprogramowania, zarządzanie aktualizacjami, zarządzanie podatnościami, UKSC, RODO, cyberhigiena