Wdrożenie EZD RP w jednostce publicznej: etapy, wymagania i bezpieczeństwo

Wdrożenie EZD RP w jednostce publicznej to projekt organizacyjny, nie tylko informatyczny. Obejmuje decyzję kierownika jednostki, analizę procesów kancelaryjnych i wybór modelu (chmura NASK albo własna infrastruktura), a dalej integracje, migrację, konfigurację uprawnień i szkolenia. Równolegle jednostka musi spełnić wymagania bezpieczeństwa z Krajowych Ram Interoperacyjności (KRI), ustawy o krajowym systemie cyberbezpieczeństwa (KSC) i RODO. Po starcie system EZD staje się bowiem głównym repozytorium dokumentów urzędu.

Stan prawny na dzień 2 września 2026 r.

Czym jest EZD RP i kto może z niego korzystać?

EZD RP to system elektronicznego zarządzania dokumentacją. Rozwija go Naukowa i Akademicka Sieć Komputerowa – Państwowy Instytut Badawczy (NASK-PIB) na zlecenie administracji rządowej. NASK-PIB udostępnia go podmiotom publicznym: urzędom administracji rządowej i samorządowej, ich jednostkom organizacyjnym oraz innym podmiotom realizującym zadania publiczne. Informacje o programie, warunkach udostępnienia i dokumentację publikuje NASK na stronie gov.pl/web/ezd-rp.

System EZD w rozumieniu przepisów kancelaryjnych służy do wykonywania czynności kancelaryjnych, dokumentowania przebiegu załatwiania spraw oraz gromadzenia dokumentacji w postaci elektronicznej. Rozporządzenie Prezesa Rady Ministrów z 18 stycznia 2011 r. dotyczy instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych. Określa ono ramy dla organów gminy, powiatu, samorządu województwa i zespolonej administracji rządowej w województwie. Pozostałe jednostki stosują własne instrukcje kancelaryjne, uzgodnione z archiwami państwowymi na podstawie ustawy z 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach. Wybór systemu nie zmienia tych obowiązków: instrukcja kancelaryjna nadal decyduje, które klasy spraw prowadzi się elektronicznie.

Jednostka wpisana do wykazu podmiotów kluczowych i ważnych powinna połączyć projekt EZD z porządkowaniem obowiązków, które opisujemy we wpisie co dalej po wpisie do wykazu KSC. Nowy system i tak trafi do rejestru aktywów i analizy ryzyka.

Jakie są etapy wdrożenia EZD RP?

Wdrożenie EZD RP przebiega w ośmiu etapach. Opóźnienia najczęściej zaczynają się w dwóch pierwszych etapach: gdy brakuje decyzji kierownika popartej zespołem i gdy jednostka próbuje wdrożyć system bez przeglądu własnych procesów kancelaryjnych.

1. Decyzja kierownika i powołanie zespołu. Kierownik jednostki wyznacza koordynatora, administratora merytorycznego (procesy, JRWA), administratora technicznego (infrastruktura, integracje) i przedstawiciela archiwum zakładowego. Bez formalnego umocowania zespół nie przeforsuje zmian w komórkach organizacyjnych.
2. Analiza procesów i JRWA. Zespół przegląda instrukcję kancelaryjną, jednolity rzeczowy wykaz akt (JRWA) i faktyczny obieg korespondencji: kto dekretuje, kto rejestruje, które przesyłki nie podlegają otwarciu ani skanowaniu. Tu zapada decyzja, które klasy JRWA przechodzą na EZD od razu, a które jako wyjątki pozostają papierowe.
3. Wybór modelu: chmura NASK czy własna infrastruktura. Decyzja zależy od kompetencji zespołu IT, wymagań formalnych i możliwości utrzymania środowiska (porównanie w kolejnej sekcji).
4. Integracje. Podstawą są ePUAP i e-Doręczenia (ustawa z 18 listopada 2020 r. o doręczeniach elektronicznych), dalej systemy dziedzinowe: finansowo-księgowe, kadrowe, ewidencje, BIP. Każda integracja to konto techniczne, interfejs i zakres danych, które trzeba opisać i zabezpieczyć.
5. Migracja danych. Dane z poprzedniego systemu lub rejestrów w arkuszach trzeba zmapować na strukturę EZD RP, oczyścić i zweryfikować po przeniesieniu. To dobry moment na usunięcie danych osobowych, których okres przechowywania minął.
6. Konfiguracja struktury i uprawnień. Odwzorowanie struktury organizacyjnej i ról (kancelaria, dekretujący, referent, archiwista, administrator) według zasady najmniejszych uprawnień. W audytach, które prowadzimy, role skonfigurowane „na szybko” wracają w uwagach najczęściej.
7. Szkolenia. Osobne ścieżki dla kierownictwa (dekretacja, akceptacja, podpis), pracowników merytorycznych, kancelarii i administratorów, najlepiej w małych grupach i w środowisku testowym.
8. Start produkcyjny i okres przejściowy. Uruchomienie zwykle zbiega się z początkiem roku lub kwartału, aby nowe sprawy zakładać już w EZD. W okresie przejściowym jednostka kończy sprawy papierowe rozpoczęte przed startem i monitoruje wyjątki od elektronicznego obiegu.

Chmura czy własna infrastruktura?

Dla mniejszych jednostek bez własnego zespołu administratorów rozsądniejszym wyborem jest zwykle usługa chmurowa NASK. Przenosi ona utrzymanie infrastruktury, aktualizacje i kopie systemowe na dostawcę publicznego. Własna instalacja ma sens tam, gdzie jednostka ma zespół IT, wymagania formalne co do lokalizacji danych albo rozbudowane integracje. W obu modelach za dane, uprawnienia oraz zgodność z KRI i RODO odpowiada jednostka.

Kryterium	Model SaaS / chmura NASK	On-premise
Utrzymanie serwerów, aktualizacje, kopie systemowe	Po stronie NASK, na warunkach udostępnienia	Po stronie jednostki: administratorzy, harmonogram łatek, testy odtwarzania kopii
Kompetencje IT w jednostce	Administrator merytoryczny i osoba od integracji	Dodatkowo administrator systemów (serwery, baza danych, sieć)
Kontrola nad konfiguracją i lokalizacją danych	Ograniczona do parametrów udostępnianych przez dostawcę	Pełna, wraz z pełną odpowiedzialnością za zabezpieczenia
Integracje z systemami dziedzinowymi	Przez udostępnione interfejsy; wymaga bezpiecznego wystawienia systemów lokalnych	W sieci wewnętrznej, łatwiej ograniczyć ekspozycję interfejsów
Odpowiedzialność za KRI, KSC i RODO	W jednostce; dostawca jest podmiotem przetwarzającym i elementem łańcucha dostaw	W całości w jednostce, łącznie z bezpieczeństwem infrastruktury

Jakie wymagania bezpieczeństwa trzeba spełnić przy EZD?

System EZD podlega tym samym trzem reżimom, co każdy inny system jednostki publicznej. Pierwszy to system zarządzania bezpieczeństwem informacji (SZBI) z rozporządzenia w sprawie Krajowych Ram Interoperacyjności. Drugi to środki z art. 8 ust. 1 ustawy o krajowym systemie cyberbezpieczeństwa. Trzeci to obowiązek zabezpieczenia danych osobowych z art. 32 RODO. Różnica polega na wadze. W EZD trafia niemal cała korespondencja urzędu, w tym dane osobowe mieszkańców, więc luka w uprawnieniach ma większe skutki niż w systemie pomocniczym.

Rozporządzenie KRI nakazuje podmiotowi realizującemu zadania publiczne opracować, wdrożyć i doskonalić SZBI. System ten obejmuje między innymi inwentaryzację aktywów, analizę ryzyka, zarządzanie uprawnieniami, kopie zapasowe i rozliczalność działań użytkowników. Dochodzi do tego okresowy audyt wewnętrzny bezpieczeństwa informacji, nie rzadziej niż raz w roku. Zakres wymagań opisuje strona usługi audytu KRI, a punkty do samodzielnego sprawdzenia lista kontrolna audytu KRI.

Ustawa o KSC po nowelizacji ustawą z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252) obejmuje podmioty publiczne jako podmioty kluczowe lub ważne. Art. 8 ust. 1 wymaga, aby jednostka systematycznie szacowała ryzyko i utrzymywała polityki bezpieczeństwa. Nakazuje też zadbać o bezpieczeństwo łańcucha dostaw, plany ciągłości działania, kryptografię, kontrolę dostępu, zarządzanie incydentami i zbieranie informacji o podatnościach. Podmioty publiczne mogą stosować uproszczone wymogi z załącznika nr 4 (art. 8 ust. 3), co upraszcza dokumentację, ale nie zwalnia z ochrony samego systemu. Kierownik jednostki odpowiada za wykonywanie tych obowiązków (art. 8c–8d).

Obszar	Wymóg	Dowód dla audytora
Polityka i dokumentacja	SZBI z rozporządzenia KRI; polityki z art. 8 ust. 1 ustawy o KSC	Zatwierdzona polityka bezpieczeństwa informacji z zapisami o EZD, wpis systemu w rejestrze aktywów, analiza ryzyka dla EZD
Uprawnienia i dostęp	Zarządzanie uprawnieniami w KRI; kontrola dostępu w ustawie o KSC	Macierz ról EZD, procedura nadawania i odbierania uprawnień, protokoły przeglądu, uwierzytelnianie wieloskładnikowe dla administratorów
Kopie zapasowe i ciągłość	Kopie zapasowe w KRI; plany ciągłości działania w ustawie o KSC	Harmonogram kopii (lub zapis umowy z NASK), protokół testu odtworzenia, obieg awaryjny przy niedostępności EZD
Rozliczalność i logi	Rozliczalność działań użytkowników w KRI; zarządzanie incydentami w ustawie o KSC	Włączone dzienniki zdarzeń EZD i integracji, okres retencji, osoba odpowiedzialna za przegląd, procedura zgłaszania incydentów do CSIRT
Dane osobowe	Art. 32 RODO: środki odpowiednie do ryzyka	Wpis EZD w rejestrze czynności przetwarzania, analiza ryzyka lub DPIA tam, gdzie wymagana, umowa powierzenia z dostawcą chmury
Weryfikacja	Coroczny audyt wewnętrzny z KRI; audyt z art. 15 ustawy o KSC dla podmiotów kluczowych	Sprawozdanie z audytu KRI, raport z testu penetracyjnego EZD i integracji, plan działań naprawczych z terminami

Jednostki bez polityki bezpieczeństwa obejmującej EZD mogą zacząć od wzoru polityki bezpieczeństwa informacji i dopisać rozdziały o rolach w EZD, integracjach i obiegu awaryjnym.

Najczęstsze ryzyka wdrożeń EZD

Najczęstsze ryzyka wdrożeń EZD nie wynikają z samego oprogramowania. Rodzą je decyzje podejmowane pod presją terminu startu: uprawnienia nadawane „na wszelki wypadek”, integracje na współdzielonych kontach technicznych i brak testu bezpieczeństwa po podłączeniu systemów dziedzinowych. Poniższe obserwacje pochodzą z audytów KRI i testów penetracyjnych, które prowadzimy w jednostkach publicznych; mają charakter jakościowy.

• Nadmiarowe uprawnienia. Koordynatorzy dostają na czas wdrożenia role administracyjne i nikt ich później nie odbiera. Po roku wszystkie sprawy, w tym kadrowe i skargowe, widzi znacznie szersze grono niż zakładano. Rozwiązanie: przegląd uprawnień po starcie i cyklicznie, z podpisem kierowników komórek.
• Brak uwierzytelniania wieloskładnikowego. Konta administratorów i kancelarii chronione wyłącznie hasłem, w modelu chmurowym często dostępne wprost z internetu. Jedno hasło z wycieku otwiera całą korespondencję jednostki.
• Integracje na kontach technicznych z pełnymi prawami. Konto łączące EZD z systemem finansowo-księgowym lub BIP dostaje uprawnienia administratora, a jego hasło trafia do plików konfiguracyjnych dostępnych dla wykonawców zewnętrznych. Rozwiązanie: uprawnienia ograniczone do potrzebnych operacji, rotacja sekretów, właściciel konta wskazany z imienia.
• Brak testów po integracji. Aplikację sprawdza producent, ale interfejsy między EZD a systemami dziedzinowymi, moduły wystawione do internetu i konfiguracja serwera pośredniczącego to praca integratora lub własnego IT. Tych elementów nikt nie testuje, dopóki nie zrobi tego audytor albo intruz.

Jak sprawdzić bezpieczeństwo EZD po wdrożeniu?

Bezpieczeństwo EZD po wdrożeniu sprawdzają trzy uzupełniające się metody: przegląd uprawnień, test penetracyjny aplikacji i integracji oraz audyt KRI. Jedna metoda nie wystarczy. Audyt dokumentacji nie wykryje podatności w interfejsie API, a test penetracyjny nie sprawdzi, czy istnieje procedura odbierania uprawnień.

Przegląd uprawnień porównuje faktyczne role w EZD z macierzą ról zatwierdzoną na etapie konfiguracji. Wynikiem jest lista kont do usunięcia lub ograniczenia oraz lista wyjątków zaakceptowanych przez kierownika. Pierwszy przegląd warto zrobić w kilka tygodni po starcie, kolejne w rytmie z polityki bezpieczeństwa.

Test penetracyjny EZD obejmuje aplikację webową (logowanie, sesje, uprawnienia między rolami, obsługę załączników), interfejsy do systemów dziedzinowych i elementy infrastruktury wystawione do internetu. W modelu chmurowym zakres trzeba uzgodnić z NASK, bo część komponentów jest współdzielona; w modelu on-premise jednostka decyduje samodzielnie. Zasady zamawiania opisuje strona usługi testów penetracyjnych.

Audyt KRI weryfikuje, czy SZBI obejmuje EZD w praktyce. Audytor sprawdza, czy system figuruje w rejestrze aktywów, czy analiza ryzyka uwzględnia integracje, czy ktoś testuje kopie i przegląda logi. Sprawozdanie jest zarazem dowodem corocznego audytu wewnętrznego i punktem wyjścia do SZBI wymaganego ustawą o KSC. Zakres tego SZBI dla podmiotów publicznych omawia strona usługi wdrożenia NIS2 i KSC.

Najczęstsze pytania o wdrożenie EZD RP

Czy każda jednostka publiczna musi wdrożyć EZD RP?

Nie. Przepisy kancelaryjne i archiwalne wymagają prowadzenia dokumentacji zgodnie z instrukcją kancelaryjną i wykazem akt, ale nie narzucają konkretnego systemu. EZD RP jest jednym z systemów klasy EZD udostępnianych podmiotom publicznym przez NASK-PIB. Wybór systemu i termin przejścia na elektroniczny obieg pozostają decyzją kierownika jednostki, chyba że odrębne przepisy stanowią inaczej.

Czy w modelu chmurowym NASK jednostka nadal odpowiada za bezpieczeństwo?

Tak. Dostawca utrzymuje infrastrukturę i aplikację, ale jednostka pozostaje administratorem danych osobowych w rozumieniu RODO i podmiotem realizującym zadania publiczne w rozumieniu rozporządzenia KRI. Uprawnienia, procedury, przegląd logów, umowa powierzenia i analiza ryzyka są obowiązkiem jednostki, a dostawca staje się elementem łańcucha dostaw objętego zarządzaniem ryzykiem według ustawy o KSC.

Jak wdrożenie EZD RP wpływa na coroczny audyt KRI?

Audyt KRI za dany rok powinien objąć wdrożenie EZD RP. Nowy system trafia do rejestru aktywów, analiza ryzyka obejmuje integracje i model wdrożenia, a audytor sprawdza uprawnienia, kopie i rozliczalność w samym EZD. Audyt wykonany według starej listy, bez EZD, nie odzwierciedla faktycznego stanu bezpieczeństwa jednostki i jest słabym dowodem w razie kontroli.

Kiedy wykonać test penetracyjny EZD: przed startem czy po?

Najlepiej tuż przed startem produkcyjnym, gdy konfiguracja, integracje i uprawnienia są już docelowe, a poprawki nie zakłócają jeszcze pracy urzędu. Jeśli system już działa, test wykonuje się w uzgodnionym oknie, z ograniczeniem operacji destrukcyjnych. Test należy powtarzać po istotnych zmianach: nowej integracji, aktualizacji głównej wersji lub zmianie modelu wdrożenia.

Czy uproszczone wymogi z załącznika nr 4 do ustawy o KSC obejmują EZD?

Uproszczone wymogi z załącznika nr 4 (art. 8 ust. 3 ustawy o KSC) dotyczą sposobu dokumentowania systemu zarządzania bezpieczeństwem informacji w podmiotach publicznych, a nie wyłączenia poszczególnych systemów. EZD jako system przetwarzający korespondencję i dane osobowe mieszkańców powinien być objęty szacowaniem ryzyka, kontrolą dostępu, kopiami i zarządzaniem incydentami niezależnie od wariantu.

Jak Pentestica może pomóc

Pentestica nie wdraża EZD RP jako integrator; pomagamy w tym, żeby wdrożenie było bezpieczne i obronne wobec audytora. W jednostkach publicznych wykonujemy audyt KRI obejmujący system EZD i jego integracje. Testujemy też aplikację, API i infrastrukturę EZD (w chmurze w zakresie uzgodnionym z dostawcą) oraz przeglądamy uprawnienia i konfigurację po starcie. Z wyników powstaje plan działań naprawczych, który da się połączyć z wdrożeniem SZBI wymaganym ustawą o KSC. Zakres i termin można wstępnie określić w konfiguratorze zakresu.

Źródła

• EZD RP, strona programu prowadzona przez NASK-PIB: informacje o systemie, warunkach udostępnienia podmiotom publicznym i dokumentacja
• Rozporządzenie Prezesa Rady Ministrów z 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz.U. 2011 nr 14 poz. 67): zasady wykonywania czynności kancelaryjnych, w tym w systemie EZD
• Ustawa z 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (Dz.U. 1983 nr 38 poz. 173, z późn. zm.): obowiązki jednostek w zakresie instrukcji kancelaryjnych, wykazów akt i archiwów zakładowych
• Rozporządzenie Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. 2024 poz. 773): system zarządzania bezpieczeństwem informacji i coroczny audyt wewnętrzny
• Ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252): art. 8 ust. 1 i 3 (SZBI, załącznik nr 4), art. 8c–8d (odpowiedzialność kierownika), art. 15 (audyt)
• Ministerstwo Cyfryzacji, nowelizacja ustawy o KSC: najważniejsze terminy: kalendarz obowiązków po wejściu nowelizacji w życie
• Ustawa z 18 listopada 2020 r. o doręczeniach elektronicznych (Dz.U. 2020 poz. 2320): podstawa prawna e-Doręczeń, z którymi integruje się EZD
• Rozporządzenie (UE) 2016/679 (RODO): art. 32 (bezpieczeństwo przetwarzania), art. 28 (podmiot przetwarzający)